RexSystem1 voteeditedoriginally by @Chailotl on GitHub1 reply
Wow, just wow. Where do I even begin with this?
Rust is a programming language that is being funded by major big-tech companies such as Google, Microsoft and Mozilla
And? This is a nothingburger of a statement. Many of the languages used by Fluxer are sponsored by these companies too.
Typescript
Developed and maintained by Microsoft
JavaScript
Major code contributions from Google and Meta
Python
Sponsored by Google, Meta, Amazon, and Microsoft
which means it is under their control
This is patently false; as previously stated by electron271, the Rust Foundation does not decide what technical features or changes happen to the Rust language, and they have an RFC process for discussing Rust features, and the Rust team is "primarily composed of volunteers from the open-source community".
Rust is less compatible than C, meaning users (such as those running BSD, plan9, etc) may be unable to run it.
As previously stated by Speykious, Rust does in fact officially support FreeBSD, but this ends up being irrelevant as Fluxer is an Electron app which uses client-side Rust code on the WASM target. If your OS can run Chromium, it is supported by Fluxer.
Rust has a reputation for being an entry for bad programmers and AI programming
What? This isn't an argument, this is an ad hominen.
being "memory safe", you trade performance, reliability and user trust for real-time automatic memory management
This displays a fundamental misunderstanding of how Rust and its borrow checker work.
Rust is not slower than C. Safe Rust may be slower than C, but you can write unsafe Rust to achieve performance parity with C. The number of performance-critical situations where you need to write unsafe Rust is vanishingly rare, if you even need to write your own unsafe Rust in the first place as many open-source libraries have already handled all the common situations.
Rust does not trade away any reliability. If anything, memory safety grants you more reliability by making memory leaks impossible. It also nudges you to write better code in the first place, rather than letting your reference graph (how and where memory is allocated and stored) become a convoluted spaghetti mess.
I don't know what your point about "user trust" is supposed to mean here.
Rust's memory safety model is not "real-time". It is compiled.
whereas managing memory by yourself is almost always more performant and safer
It is never safer than Rust's borrow checker, which is based on formal mathematical principles to guarantee memory safety at compile time. In other words, it is mathematically proven to be memory safe. It is also never faster than Rust, which still lets you write unsafe Rust to achieve performance parity with C.
This is actually the one memory issue that Rust doesn't solve. In fact, leaking memory is completely safe! Not that any other programming language can really solve this though, since it requires solving the halting problem...
(But of course, stuff like use-after-tree, double-free, buffer overflow etc. are impossible in safe Rust.)
Thread
Comment by @Chailotl
- Typescript
- Developed and maintained by Microsoft
- JavaScript
- Major code contributions from Google and Meta
- Python
- Sponsored by Google, Meta, Amazon, and Microsoft
This is patently false; as previously stated by electron271, the Rust Foundation does not decide what technical features or changes happen to the Rust language, and they have an RFC process for discussing Rust features, and the Rust team is "primarily composed of volunteers from the open-source community". As previously stated by Speykious, Rust does in fact officially support FreeBSD, but this ends up being irrelevant as Fluxer is an Electron app which uses client-side Rust code on the WASM target. If your OS can run Chromium, it is supported by Fluxer. What? This isn't an argument, this is an ad hominen. This displays a fundamental misunderstanding of how Rust and its borrow checker work. Rust is not slower than C. Safe Rust may be slower than C, but you can write unsafe Rust to achieve performance parity with C. The number of performance-critical situations where you need to write unsafe Rust is vanishingly rare, if you even need to write your own unsafe Rust in the first place as many open-source libraries have already handled all the common situations. Rust does not trade away any reliability. If anything, memory safety grants you more reliability by making memory leaks impossible. It also nudges you to write better code in the first place, rather than letting your reference graph (how and where memory is allocated and stored) become a convoluted spaghetti mess. I don't know what your point about "user trust" is supposed to mean here. Rust's memory safety model is not "real-time". It is compiled. It is never safer than Rust's borrow checker, which is based on formal mathematical principles to guarantee memory safety at compile time. In other words, it is mathematically proven to be memory safe. It is also never faster than Rust, which still lets you write unsafe Rust to achieve performance parity with C.Comment by @Speykious