6 ms·

While I like the idea of Rust, having to (re)-learn all these subtleties seems daunting (just look at the table comparing dyn vs. box vs. arc vs. references etc

by beders 5y ago

While I like the idea of Rust, having to (re)-learn all these subtleties seems daunting (just look at the table comparing dyn vs. box vs. arc vs. references etc.) When I moved to Java 1.0, coming from C/C++, I hated the performance loss but happily traded that for a garbage collector. Typically, when the code compiled, it ran. Now with Rust I'm wondering how much time practitioners spend on analyzing compiler errors (which is a good deal better than analyzing heap dumps with gdb). And do you get to a place where your coding naturally avoids gotchas around borrowing?

wyager 5y ago
Personally, I find the overhead of dealing with rust memory management to be 100% worth it when writing embedded code with no dynamic allocation. It can really help to prevent bad memory management practices and, not so much catch, but rather structurally prevent, bugs. If you’re really experienced with embedded C you were probably doing things mostly the same way anyway. For writing code on an operating system, I’m in the same boat as you; I would rather have GC. Haskell and Rust are spiritually actually pretty similar with the former simplifying memory management and enriching the type system (at the cost of needing to worry about things like memory leaks), and I tend to go to Haskell for non-embedded applications most of the time.
burntsushi 5y ago
> Now with Rust I'm wondering how much time practitioners spend on analyzing compiler errors Almost zero. Seriously. Because the rules got internalized for me pretty quickly. If you asked me, "how much time did you spend when just starting Rust," then it would be a lot more than zero. Enough to noticeably slow me down. But it got down to near-zero pretty quickly. I'd maybe a month or so with ~daily programming.
- stouset 5y ago
  I'll caveat this by saying that to have this kind of experience, it's incredibly important to understand why you're getting these types of errors in the first place. Rust programs require you to consider some things upfront in your design that you don't have to think about in other languages. If you internalize these requirements, designing programs in Rust can quickly become just as easy and natural as developing in other languages. But it can feel arbitrary and impossible if you just try and force your way forward by `Box`ing and `clone()`ing everything endlessly because it seems to make the annoying compiler errors go away. If you're the type of engineer who learns a new language and just ends up writing programs in the style of your old language (but with different syntax), Rust is going to feel a lot harder and you may never "get" it. The difficulty curve of Rust is—I think—much steeper than other languages for this type of engineer. You can be productive writing C-style programs in golang. You can be productive writing Java-style programs in Ruby. But Rust is going to fight you much harder than other languages if you try to approach things this way. If you're the type of engineer who strives to build idiomatic software in whatever language you're using, you'll have a much faster ramp-up to proficiency.
zozbot234 5y ago
> While I like the idea of Rust, having to (re)-learn all these subtleties seems daunting It's not like Java is any simpler. Rust gives you the equivalent of a GC, except at compile time. And the compiler tells you when you're getting it wrong.
- Kranar 5y ago
  I've heard before the idea that Rust has a "compile time GC" or "static GC", and while I can sympathize with wanting to leverage that term, it already has a fairly well understood meaning and it's not what Rust provides. The only GC that comes built-in to Rust is reference counting via Rc and Arc. With an actual GC, there is no notion of getting it wrong; the whole point of a GC is that it automates the handling of memory. A useful metaphor for a GC is that it's a system that simulates an infinite amount of memory. With a GC, at least conceptually, you don't allocate and deallocate memory, rather you declare what object you want and it stays alive forever. The GC works behind the scenes to maintain this illusion, although since it's only a simulation there are certain imperfections. There are some languages that can do this at compile time, such as Mercury and I believe Rust took some inspiration from Mercury... but Rust does not have a compile-time GC the same way that Mercury does.
  - zozbot234 5y ago
    > With an actual GC, there is no notion of getting it wrong; the whole point of a GC is that it automates the handling of memory. Rust is memory safe, so Rust programs don't go "wrong" either, barring use of unsafe{} or bugs in the underlying implementation. You only need Rc<> or Arc<> for objects that may have more than a single "owner" controlling their extent. That's a comparatively uncommon case.
    - Kranar 5y ago
      You're switching context here and doing so in a way that's fairly pedantic and not really useful. You mentioned that Rust informs you when you're "getting it wrong" and most people who aren't being pedantic can understand the meaning of that; that there's something that would otherwise go wrong if not for a compile time check that prevents it. In most GC'd languages, there is no notion of something that would have otherwise gone wrong if not for a compile time check (with respect to memory safety). In most GC'd languages, that very concept doesn't exist. Another way to put it is that there's nothing for a Java compiler to tell a user about "getting it wrong" because there's nothing to get wrong in the first place (with respect to memory safety, since we're being overly pedantic now).

by beders 5y ago

wyager 5y ago

Personally, I find the overhead of dealing with rust memory management to be 100% worth it when writing embedded code with no dynamic allocation. It can really help to prevent bad memory management practices and, not so much catch, but rather structurally prevent, bugs. If you’re really experienced with embedded C you were probably doing things mostly the same way anyway. For writing code on an operating system, I’m in the same boat as you; I would rather have GC. Haskell and Rust are spiritually actually pretty similar with the former simplifying memory management and enriching the type system (at the cost of needing to worry about things like memory leaks), and I tend to go to Haskell for non-embedded applications most of the time.

burntsushi 5y ago

> Now with Rust I'm wondering how much time practitioners spend on analyzing compiler errors Almost zero. Seriously. Because the rules got internalized for me pretty quickly. If you asked me, "how much time did you spend when just starting Rust," then it would be a lot more than zero. Enough to noticeably slow me down. But it got down to near-zero pretty quickly. I'd maybe a month or so with ~daily programming.

stouset 5y ago
I'll caveat this by saying that to have this kind of experience, it's incredibly important to understand why you're getting these types of errors in the first place. Rust programs require you to consider some things upfront in your design that you don't have to think about in other languages. If you internalize these requirements, designing programs in Rust can quickly become just as easy and natural as developing in other languages. But it can feel arbitrary and impossible if you just try and force your way forward by `Box`ing and `clone()`ing everything endlessly because it seems to make the annoying compiler errors go away. If you're the type of engineer who learns a new language and just ends up writing programs in the style of your old language (but with different syntax), Rust is going to feel a lot harder and you may never "get" it. The difficulty curve of Rust is—I think—much steeper than other languages for this type of engineer. You can be productive writing C-style programs in golang. You can be productive writing Java-style programs in Ruby. But Rust is going to fight you much harder than other languages if you try to approach things this way. If you're the type of engineer who strives to build idiomatic software in whatever language you're using, you'll have a much faster ramp-up to proficiency.

zozbot234 5y ago

> While I like the idea of Rust, having to (re)-learn all these subtleties seems daunting It's not like Java is any simpler. Rust gives you the equivalent of a GC, except at compile time. And the compiler tells you when you're getting it wrong.

Kranar 5y ago
I've heard before the idea that Rust has a "compile time GC" or "static GC", and while I can sympathize with wanting to leverage that term, it already has a fairly well understood meaning and it's not what Rust provides. The only GC that comes built-in to Rust is reference counting via Rc and Arc. With an actual GC, there is no notion of getting it wrong; the whole point of a GC is that it automates the handling of memory. A useful metaphor for a GC is that it's a system that simulates an infinite amount of memory. With a GC, at least conceptually, you don't allocate and deallocate memory, rather you declare what object you want and it stays alive forever. The GC works behind the scenes to maintain this illusion, although since it's only a simulation there are certain imperfections. There are some languages that can do this at compile time, such as Mercury and I believe Rust took some inspiration from Mercury... but Rust does not have a compile-time GC the same way that Mercury does.
- zozbot234 5y ago
  > With an actual GC, there is no notion of getting it wrong; the whole point of a GC is that it automates the handling of memory. Rust is memory safe, so Rust programs don't go "wrong" either, barring use of unsafe{} or bugs in the underlying implementation. You only need Rc<> or Arc<> for objects that may have more than a single "owner" controlling their extent. That's a comparatively uncommon case.
  - Kranar 5y ago
    You're switching context here and doing so in a way that's fairly pedantic and not really useful. You mentioned that Rust informs you when you're "getting it wrong" and most people who aren't being pedantic can understand the meaning of that; that there's something that would otherwise go wrong if not for a compile time check that prevents it. In most GC'd languages, there is no notion of something that would have otherwise gone wrong if not for a compile time check (with respect to memory safety). In most GC'd languages, that very concept doesn't exist. Another way to put it is that there's nothing for a Java compiler to tell a user about "getting it wrong" because there's nothing to get wrong in the first place (with respect to memory safety, since we're being overly pedantic now).