3 ms·
My hopes is that Rust will result in more user-facing applications being written with the light weight, responsiveness, and performance of low-level-optimized c
by nyanpasu64 5y ago
My hopes is that Rust will result in more user-facing applications being written with the light weight, responsiveness, and performance of low-level-optimized code (no GC pauses, less allocation churn, easy safe parallelization, no segfaults unlike C++). Applications used to be written in C (and even RollerCoaster Tycoon in assembly), and GC'd languages are easier to develop in but slower to run on the user's computer. I'm not sure how successful Rust will be, since it discourages using multiple ownership or refcounting, and doesn't supply garbage collection, in situations where it is the easiest way to reason about code. IMO this raises the bar and discourages even working in these domains. (In my experience gtk-rs is more frustrating and confusing to use than unsafe Qt in C++.) And given Rust's tendency for dependency bloat, the applications don't come out as small on-disk as possible.
- zozbot234 5y agoWe will probably see some support for "pluggable", localized GC in Rust once it gains proper support for arenas/local allocators. This should make it easier to use Rust in domains where GC is pretty much a requirement, such as computing with general graphs. Executable bloat in Rust applications is generally due to a lack of "idiomatic" support for dynamic linking (.dll or .so objects). You're expected to pretty much write your own interface layers using the C ABI, and it's especially hard to make these "interface" layers play well with generic code, which is quite ubiquitous in Rust.