3 ms·

> At this point I can't see us going back to the way things were. I can't imagine any new systems programming languages gaining traction that aren't at least a

> At this point I can't see us going back to the way things were. I can't imagine any new systems programming languages gaining traction that aren't at least as safe as Rust. I see Rust being used in many context where it's safety features aren't really needed or even a hindrance like game dev. Honestly the safety is overstated in importance. The amazing tooling, decent package manager, great error messages, the inclusive community, the type system that took the low hanging fruits from the academic functional programming world, are much more relevant for its success. The problem with Rust is that it made using languages without automatic garbage collection acceptable again and I am not sure if this is good. The borrow checker is a neat solution and might be a good fit for certain niches but automatic garbage collection is just vastly more ergonomic to use. We had Lisp Machines, we need to go back to future.

the__alchemist 2y ago
I'm with you - I like Rust for the overall pros/con balance, in context of with its alternatives. Safety is one thing. The tooling, error messages, type system etc you mention is another. Having mutable references as function parameters is another big one, shared by surprisingly few alternatives.
- vlovich123 2y ago
  Safety and the hype reels you in and the qol hooks and keeps you.
  - lproven 2y ago
    Is that QOI or QOL, and what does it stand for?
    - vlovich123 2y ago
      Quality of life
zozbot234 2y ago
GC implementations are widely available in Rust. You don't have to use garbage collection in Rust, but it doesn't stop you either. You just have to import some custom crate and 'implement' tracing for your own data types.
- selfmodruntime 2y ago
  You will see their limitations when working with futures. That's really the number 1 pitfall in the language.
tuetuopay 2y ago
I've written Rust professionally for the past 6 years, and pretty much exclusively for stuff where memory safety is the least of my concerns (even speed!). I've made gRPC APIs, agents running on machines to setup configuration and such. The usual suspects for this work would usually be Python or Go. You've pretty much summed up why I'm standing behind Rust for non-memory-critical applications: tooling, error messages, and the type system. For business logic, you cannot beat all that, as a lot of business errors can be avoided using those (all praise the Rust enums!). Also, you've summarized my feeling about the functional world embraced by rust: it provides quite a bit, without requiring a Haskell PhD to write it. Seriously, iterators and the associated trait are a godsend (even though having to always write .iter()....collect() is sometimes clunky). As for the GC. I've yet to come to situations where the lack of GC was the real hindrance. It has more to do with futures adding not easy to grasp lifetime bounds to data, but one quickly learns to embrace it by moving data when needed. Combined with channels and Arc, there are many escape hatches making in my opinion the GC a non-issue. IMHO, making GC-less languages acceptable again is a good thing, because it keeps diversity in the ecosystem and gives options. It also shows that doing without GC does not relegates written code to manual memory management like C/C++. In fact, Swift does the same and is pretty good at being a GC-less language. Both Rust and Swift are languages where memory management is opinionated by embedding it in the language, and thus ergonomic. Frankly, I rarely think about "oh hey, I wished I had a GC".
selfmodruntime 2y ago
Exactly. I love Rust. If I could write Rust with just a GC enabled / No borrow checker, I would never choose another language.

the__alchemist 2y ago

I'm with you - I like Rust for the overall pros/con balance, in context of with its alternatives. Safety is one thing. The tooling, error messages, type system etc you mention is another. Having mutable references as function parameters is another big one, shared by surprisingly few alternatives.

vlovich123 2y ago
Safety and the hype reels you in and the qol hooks and keeps you.
- lproven 2y ago
  Is that QOI or QOL, and what does it stand for?
  - vlovich123 2y ago
    Quality of life

zozbot234 2y ago

GC implementations are widely available in Rust. You don't have to use garbage collection in Rust, but it doesn't stop you either. You just have to import some custom crate and 'implement' tracing for your own data types.

selfmodruntime 2y ago
You will see their limitations when working with futures. That's really the number 1 pitfall in the language.

tuetuopay 2y ago

I've written Rust professionally for the past 6 years, and pretty much exclusively for stuff where memory safety is the least of my concerns (even speed!). I've made gRPC APIs, agents running on machines to setup configuration and such. The usual suspects for this work would usually be Python or Go. You've pretty much summed up why I'm standing behind Rust for non-memory-critical applications: tooling, error messages, and the type system. For business logic, you cannot beat all that, as a lot of business errors can be avoided using those (all praise the Rust enums!). Also, you've summarized my feeling about the functional world embraced by rust: it provides quite a bit, without requiring a Haskell PhD to write it. Seriously, iterators and the associated trait are a godsend (even though having to always write .iter()....collect() is sometimes clunky). As for the GC. I've yet to come to situations where the lack of GC was the real hindrance. It has more to do with futures adding not easy to grasp lifetime bounds to data, but one quickly learns to embrace it by moving data when needed. Combined with channels and Arc, there are many escape hatches making in my opinion the GC a non-issue. IMHO, making GC-less languages acceptable again is a good thing, because it keeps diversity in the ecosystem and gives options. It also shows that doing without GC does not relegates written code to manual memory management like C/C++. In fact, Swift does the same and is pretty good at being a GC-less language. Both Rust and Swift are languages where memory management is opinionated by embedding it in the language, and thus ergonomic. Frankly, I rarely think about "oh hey, I wished I had a GC".

selfmodruntime 2y ago

Exactly. I love Rust. If I could write Rust with just a GC enabled / No borrow checker, I would never choose another language.