5 ms·

Yeah what a lot of people don't understand is that if there was a garbage collected version of Rust that kept the same guarantees around mutable data, with the

Yeah what a lot of people don't understand is that if there was a garbage collected version of Rust that kept the same guarantees around mutable data, with the same good type system, good ecosystem, and good tooling, I'd still write a lot of it. Those benefits are way more important to me than the borrow checker. Basically, Rust fulfills the dream of a functional language with pragmatic semantics, syntax, and developer experience. That's why I write it.

TylerE 4y ago
This I buy. I’ve never quite gotten why the rust crowd thinks manual memory management and zero cost abstractions are the only bullet points that matter. Many of us would happily switch to a language that didn’t have either, if it made our day to day work not feel like rocket science and the sharp edge of the “never write code as cleverly as you can, because you won’t be able to debug it” adage.
- steveklabnik 4y ago
  > why the rust crowd thinks manual memory management and zero cost abstractions are the only bullet points that matter. I don't think that's an accurate characterization of "the Rust crowd," but even if we do take it at face value, it would make sense: Rust was intended for the layer of the stack where these things do matter. Even though Rust has broken out of that initial layer, as the post demonstrates, culturally these things are likely to hold a bit more value than they may otherwise.
  - DeathArrow 4y ago
    > Rust was intended for the layer of the stack where these things do matter. Good point. If those things don't matter, then maybe you are better off using another language.
- smolder 4y ago
  Memory management/performance are just among the most obvious points of comparison when looking at Rust versus other languages. Ergonomics come up too, though less often, and with less agreement on how good they are, since it's a pretty subjective judgement on a mixed bag of features and syntax.
  - TylerE 4y ago
    If they frequently come up I think that says exactly how good they are.
    - TylerE 4y ago
      I would also argue that “performance” and “manual memory management” do not go hand in hand.
- arch-ninja 4y ago
  Guarantees about those things are impossible to add after a language/community abandons them, and you can Arc::<RWLock<T>> your way to writing Java pretty fast. I hold that keeping the strongest-possible abstractions is the best decision, even if that means your average developer needs to learn borrow checking. I've started a career writing Java, spent a year with Rust, and when I came back to Java my data structures were 5x as useful. I could spit out features _WITHOUT_NULLPOINTER_ISSUES_ in hours where previously it would have taken a week. Yes there is a skill gradient, but everyone who doesn't climb that hill is a fool and a weaker team member for it in my opinion.
- cmrdporcupine 4y ago
  Well, because as others have pointed out, languages like that have existed for at least a couple decades. Most of the 'nice parts' of Rust are really borrowings from the ML family of languages: Hindley-Milner type inference, algebraic data types, and pattern matching. OCaml or StandardML, (or Haskell if you want to get funky ... I don't), F#, Scala, etc. Hell, these days even Swift, or Kotlin, have these features. Which I'd call: modern static type systems. And I understand even Java is getting some of them. Even TypeScript is a reasonable-ish solution with a pretty nifty type system, if you don't mind the (non-existent) threading model. I like Rust, but its niche is: the above nice things and a clean syntax, but without the latency&pause costs of GC. And that's what I use it for, when I need that kind of thing, for systems programming. And for that, the killer feature is the borrow checker which makes using the above features relatively painless, despite having no GC. (Now one other advantage of the borrow checker is its application to concurrency -- making ownership of locks, and mutable state generally, easier to reason about. That's perhaps a killer feature that the other languages I mentioned don't really have)
- tdeck 4y ago
  It's often a good idea to focus on a narrower range of use cases when evaluating the tradeoffs involved in designing a system. In the case of Rust, it's designed for writing systems software in performance critical code paths where these bullet points matter.
cardanome 4y ago
The borrow checker is Rust's unique selling point, if you don't care much about it, there are many alternatives that do the things Rust does but better. (Well and the error messages: other than Elm there are really no other languages with such excellent messages as Rust has.) You might want to explore the space of statically typed functional programming languages a bit more. OCaml and F# are both very pragmatic functional programming language that will give you everything you want and even more.
- hardwaregeek 4y ago
  I would emphatically disagree here. The ergonomics of Rust blow any functional language out of the water. The combination of cargo, rust-analyzer, and rustfmt is far better than anything OCaml can offer. Likewise, the choice of modules instead of traits, while probably a "better" design from a language design aesthetic perspective (more compositional, less global), make simple things like printing or checking equality rather difficult. And that's not even getting into compiler errors, package ecosystem, or documentation. And really, you can see the priorities in how the people driving the language talk about it. In Rust there's a focus on ergonomics. How can we make this easier to use? How can we make the tooling nicer? In OCaml and other languages the focus is almost always on semantics. We have unboxed types like Rust. We have multicore with green threads. We have effects. This is missing the point. I don't care about the features of the language if the language itself is annoying to use. It's like wondering why Slack or Discord won versus IRC. Ergonomics is the answer.
  - pharmakom 4y ago
    Interesting you came to that conclusion. I liked Rust when I tried it, but it is definitely less productive and ergonomic than F#. Of course the memory overhead in Rust is much more predictable and generally lower, which might be an important factor for you.
  - momentoftop 4y ago
    OCaml has dune/opam, OCamlfmt and Merlin. I don't know how Rust can blow these out of the water, but would be interested in comparing killer features. I mean, OCaml's autoformatter just autoformats arbitrary Ocaml files. How do you blow that out of the water?
evntdrvn 4y ago
That’s called F# :D
DeathArrow 4y ago
> Yeah what a lot of people don't understand is that if there was a garbage collected version of Rust that kept the same guarantees around mutable data, with the same good type system, good ecosystem, and good tooling, I'd still write a lot of it. Those benefits are way more important to me than the borrow checker. Basically, Rust fulfills the dream of a functional language with pragmatic semantics, syntax, and developer experience. That's why I write it. You might want to take a look at F#.
DeathArrow 4y ago
>Yeah what a lot of people don't understand is that if there was a garbage collected version of Rust that kept the same guarantees around mutable data, with the same good type system, good ecosystem, and good tooling, I'd still write a lot of it. Those benefits are way more important to me than the borrow checker. https://fsharpforfunandprofit.com/ https://fsharpforfunandprofit.com/
pie_flavor 4y ago
If garbage collection helps, you no longer have ownership, because a single place where a value is dropped obviates the need for GC. If you no longer have ownership, you no longer have use-site mutability, because no single place controls the mutability anymore. If you no longer have use-site mutability, you no longer have the good type system. The borrow checker is what makes it work.
mikedelago 4y ago
I agree. There's a lot of sibling comments to mine saying "You're thinking of F#" or Ocaml or whatever, and from a purely semantic point I agree with them. The problem is, where the hell is the enthusiasm for those languages in a similar direction as rust? The only reason I don't use those languages is because people are overwhelmingly more enthusiastic about rust, which has the majority of features I want. This in turn makes rust have a better developer experience as more people use and contribute to that experience
pyjarrett 4y ago
F# is pretty close to "GC'd Rust with Python-esque indenting". In my head it feels like "Rust-lite". I ported a program from C#, to F#, and then to Rust. The F# -> Rust conversion was a lot of "add curly braces and parentheses" and "replace |> with ." It's almost kind of ridiculous how similar the code can be. I've been going back and forth between F# and Rust on hobby work and it's very, very easy to do. You get the equivalent of many crates of cross-platform stuff straight out of .NET Core: e.g serialize to/from JSON, network requests, tasking/async, etc. Either VS or Rider is great, the debugger also works out of the box. I also skip Python/Powershell/Bash and write any extra scripts I need in F# and run then with ``dotnet fsi``. This "Keep all the things in the same language" is very attractive to me. Using F# over Python for scripting is very enticing to me -- good implicit typing, enums, ``match``, etc. I'm not sure why this hasn't been pushed before. The docs are great and most things "just work", but I've been trying to hold back my enthusiasm because I just haven't been able to find folks using it, and http://forums.fsharp.org http://forums.fsharp.org seems empty. It is fun to write though :)

TylerE 4y ago

This I buy. I’ve never quite gotten why the rust crowd thinks manual memory management and zero cost abstractions are the only bullet points that matter. Many of us would happily switch to a language that didn’t have either, if it made our day to day work not feel like rocket science and the sharp edge of the “never write code as cleverly as you can, because you won’t be able to debug it” adage.

steveklabnik 4y ago
> why the rust crowd thinks manual memory management and zero cost abstractions are the only bullet points that matter. I don't think that's an accurate characterization of "the Rust crowd," but even if we do take it at face value, it would make sense: Rust was intended for the layer of the stack where these things do matter. Even though Rust has broken out of that initial layer, as the post demonstrates, culturally these things are likely to hold a bit more value than they may otherwise.
- DeathArrow 4y ago
  > Rust was intended for the layer of the stack where these things do matter. Good point. If those things don't matter, then maybe you are better off using another language.
smolder 4y ago
Memory management/performance are just among the most obvious points of comparison when looking at Rust versus other languages. Ergonomics come up too, though less often, and with less agreement on how good they are, since it's a pretty subjective judgement on a mixed bag of features and syntax.
- TylerE 4y ago
  If they frequently come up I think that says exactly how good they are.
  - TylerE 4y ago
    I would also argue that “performance” and “manual memory management” do not go hand in hand.
arch-ninja 4y ago
Guarantees about those things are impossible to add after a language/community abandons them, and you can Arc::<RWLock<T>> your way to writing Java pretty fast. I hold that keeping the strongest-possible abstractions is the best decision, even if that means your average developer needs to learn borrow checking. I've started a career writing Java, spent a year with Rust, and when I came back to Java my data structures were 5x as useful. I could spit out features _WITHOUT_NULLPOINTER_ISSUES_ in hours where previously it would have taken a week. Yes there is a skill gradient, but everyone who doesn't climb that hill is a fool and a weaker team member for it in my opinion.
cmrdporcupine 4y ago
Well, because as others have pointed out, languages like that have existed for at least a couple decades. Most of the 'nice parts' of Rust are really borrowings from the ML family of languages: Hindley-Milner type inference, algebraic data types, and pattern matching. OCaml or StandardML, (or Haskell if you want to get funky ... I don't), F#, Scala, etc. Hell, these days even Swift, or Kotlin, have these features. Which I'd call: modern static type systems. And I understand even Java is getting some of them. Even TypeScript is a reasonable-ish solution with a pretty nifty type system, if you don't mind the (non-existent) threading model. I like Rust, but its niche is: the above nice things and a clean syntax, but without the latency&pause costs of GC. And that's what I use it for, when I need that kind of thing, for systems programming. And for that, the killer feature is the borrow checker which makes using the above features relatively painless, despite having no GC. (Now one other advantage of the borrow checker is its application to concurrency -- making ownership of locks, and mutable state generally, easier to reason about. That's perhaps a killer feature that the other languages I mentioned don't really have)
tdeck 4y ago
It's often a good idea to focus on a narrower range of use cases when evaluating the tradeoffs involved in designing a system. In the case of Rust, it's designed for writing systems software in performance critical code paths where these bullet points matter.

cardanome 4y ago

The borrow checker is Rust's unique selling point, if you don't care much about it, there are many alternatives that do the things Rust does but better. (Well and the error messages: other than Elm there are really no other languages with such excellent messages as Rust has.) You might want to explore the space of statically typed functional programming languages a bit more. OCaml and F# are both very pragmatic functional programming language that will give you everything you want and even more.

hardwaregeek 4y ago
I would emphatically disagree here. The ergonomics of Rust blow any functional language out of the water. The combination of cargo, rust-analyzer, and rustfmt is far better than anything OCaml can offer. Likewise, the choice of modules instead of traits, while probably a "better" design from a language design aesthetic perspective (more compositional, less global), make simple things like printing or checking equality rather difficult. And that's not even getting into compiler errors, package ecosystem, or documentation. And really, you can see the priorities in how the people driving the language talk about it. In Rust there's a focus on ergonomics. How can we make this easier to use? How can we make the tooling nicer? In OCaml and other languages the focus is almost always on semantics. We have unboxed types like Rust. We have multicore with green threads. We have effects. This is missing the point. I don't care about the features of the language if the language itself is annoying to use. It's like wondering why Slack or Discord won versus IRC. Ergonomics is the answer.
- pharmakom 4y ago
  Interesting you came to that conclusion. I liked Rust when I tried it, but it is definitely less productive and ergonomic than F#. Of course the memory overhead in Rust is much more predictable and generally lower, which might be an important factor for you.
- momentoftop 4y ago
  OCaml has dune/opam, OCamlfmt and Merlin. I don't know how Rust can blow these out of the water, but would be interested in comparing killer features. I mean, OCaml's autoformatter just autoformats arbitrary Ocaml files. How do you blow that out of the water?

evntdrvn 4y ago

That’s called F# :D

DeathArrow 4y ago

> Yeah what a lot of people don't understand is that if there was a garbage collected version of Rust that kept the same guarantees around mutable data, with the same good type system, good ecosystem, and good tooling, I'd still write a lot of it. Those benefits are way more important to me than the borrow checker. Basically, Rust fulfills the dream of a functional language with pragmatic semantics, syntax, and developer experience. That's why I write it. You might want to take a look at F#.

DeathArrow 4y ago

>Yeah what a lot of people don't understand is that if there was a garbage collected version of Rust that kept the same guarantees around mutable data, with the same good type system, good ecosystem, and good tooling, I'd still write a lot of it. Those benefits are way more important to me than the borrow checker. https://fsharpforfunandprofit.com/ https://fsharpforfunandprofit.com/

pie_flavor 4y ago

If garbage collection helps, you no longer have ownership, because a single place where a value is dropped obviates the need for GC. If you no longer have ownership, you no longer have use-site mutability, because no single place controls the mutability anymore. If you no longer have use-site mutability, you no longer have the good type system. The borrow checker is what makes it work.

mikedelago 4y ago

I agree. There's a lot of sibling comments to mine saying "You're thinking of F#" or Ocaml or whatever, and from a purely semantic point I agree with them. The problem is, where the hell is the enthusiasm for those languages in a similar direction as rust? The only reason I don't use those languages is because people are overwhelmingly more enthusiastic about rust, which has the majority of features I want. This in turn makes rust have a better developer experience as more people use and contribute to that experience

pyjarrett 4y ago

F# is pretty close to "GC'd Rust with Python-esque indenting". In my head it feels like "Rust-lite". I ported a program from C#, to F#, and then to Rust. The F# -> Rust conversion was a lot of "add curly braces and parentheses" and "replace |> with ." It's almost kind of ridiculous how similar the code can be. I've been going back and forth between F# and Rust on hobby work and it's very, very easy to do. You get the equivalent of many crates of cross-platform stuff straight out of .NET Core: e.g serialize to/from JSON, network requests, tasking/async, etc. Either VS or Rider is great, the debugger also works out of the box. I also skip Python/Powershell/Bash and write any extra scripts I need in F# and run then with ``dotnet fsi``. This "Keep all the things in the same language" is very attractive to me. Using F# over Python for scripting is very enticing to me -- good implicit typing, enums, ``match``, etc. I'm not sure why this hasn't been pushed before. The docs are great and most things "just work", but I've been trying to hold back my enthusiasm because I just haven't been able to find folks using it, and http://forums.fsharp.org http://forums.fsharp.org seems empty. It is fun to write though :)