6 ms·

It also protects against data races which is fairly novel. A lot of functional languages offer this by avoiding mutable data, but that's high cost and not reall

by eloff 7y ago

It also protects against data races which is fairly novel. A lot of functional languages offer this by avoiding mutable data, but that's high cost and not really equal with what rust does. I find rust quite elegant but also quite complex. There's a scale for computer languages between a compiler that doesn't do enough checking (JavaScript, Python), and ones that do too much where you spend a lot of energy trying to satisfy the compiler. I think rust falls a bit too far to this latter side for my taste. I like the language but I feel more productive with Go even although Go isn't as elegant in my mind and has some flaws (nil, no generics). I think rust is nicer for where you would previously use C or C++ but I don't work in that domain.

throwaway894345 7y ago
I agree with everything you posted (and I also really like Rust!), but I especially took note of this: > A lot of functional languages offer this by avoiding mutable data, but that's high cost This is true, but the inverse is that Rust's ownership model itself poses its own high cost in terms of a significant cognitive burden (and while I have no doubt that the burden decreases with time, I'm very skeptical that it ever gets to the point of a GC language). This is roughly what you're saying in the second paragraph, but I wanted to be a bit more explicit that the ownership model itself comes with a cost.
- steveklabnik 7y ago
  I think how low it gets really depends on the person. For me, it's basically zero burden. I don't have to think about these things, the compiler thinks about them! That's kind of the point. I've also internalized the rules, so that I tend to program in a style that works. I am of course, extremely biased, but this story seems to play out with many people who stick with it.
- dpc_pw 7y ago
  > significant cognitive burden (...) I'm very skeptical that it ever gets to the point of a GC language My experience in this regard: Once you stop thinking in OOP, and embrace Data Oriented Design (which really helps structure your program like Rust wants it to be to avoid lifetimes issues) and get proficient with type system and popular libraries, Rust is far more productive and effortless than mainstream GC languages. I routinely do non-trivial changes to my open source projects late in the evening, after long day of work, after I've finally put my kids to sleep, and despite sloppiness and lethargy it's very much effortless. I don't have to debug weird stuff. Compiler just straight tells me what I did wrong and how to fix it. Languages expressiveness is first class, so I don't have think too much what's the best way to express this or that idea. Then - not only I don't have to worry about `free`, but I also get deterministic destruction: files, sockets and any other "resources" get closed/freed when I'm done with them. And then the libraries... they have beautiful, well-documented, and hard to misuse APIs.
  - throwaway894345 7y ago
    I'm already on-board with data-oriented design, and my pedigree includes lots of such projects and languages (C, C++, Go, etc). I'm also familiar with Rust; I've been dabbling in it since ~2014. Still, I come to opposite conclusions. Rust is a magnificent language for many things, but I'm manifold more productive in Go or Python, even in concurrent contexts. Notably, the ownership rules guarantee correctness, but they also prohibit all sorts of correct programs (e.g., functions that only run in a single threaded context or whose shared data doesn't actually mutate). I would say I have the hang of these rules, but I still struggle to make sense of the lifetime error messages (and I find this nearly impossible when I'm tired), contrary to your experience about the clarity of the compiler messaging. I don't mean to slight the compiler--communicating about lifetimes is fundamentally hard; however, the point is that these error messages must be dealt with in all code even though the overwhelming majority of my code isn't subject to race conditions in the first place. I really want to like Rust (I love it in theory); however, frankly I don't see how Rust can approach a GC language with respect for productivity for anyone unless the domain prioritizes correctness and/or performance above all else.
    - lukebitts 7y ago
      > I don't see how Rust can approach a GC language with respect for productivity for anyone My domain is games, and while this usually prioritizes performance that's not really what I care about (so I could be using Python for instance and it would be 'ok'). My take is this: When it comes to productivity even if writing the same code is easier in Python than Rust, working over time in a Python project (or any dynamic language really) is just a nightmare for me. No matter how many tests I write or how I structure my code when I have to add a new feature that touches large parts of the existing system I just have 0 confidence it is correct. I have to run my code through all the branches to make sure I didn't forget to, idk, add the new parameter to all function calls or something. Rust on the hand is just reliable. I can start updating my code with a half baked idea, start adding types to things, removing parameters from functions, changing variables names and I KNOW nothing will sneak on me during runtime. This is more of a feature of strong type systems than Rust itself, but still this is what productivity means to me. (Also, to me lifetimes were the hardest concept to grasp, but I think once you really get what they mean that's when the language clicks and you get the same productivity you would elsewhere)
- zozbot234 7y ago
  > This is true, but the inverse is that Rust's ownership model itself poses its own high cost in terms of a significant cognitive burden In "burdensome" situations, you can always defer ownership checking to runtime with the Rc<RefCell<T>> and Arc<Mutex<T>> patterns. It's less performant than using pure compile-time checks, but not nearly as problematic as general GC, or immutable-only data structures.
- eloff 7y ago
  Yes, I agree. Although one must be careful taking about high performance cost like immutable data structures and high cognitive cost like the borrow rules in rust. I think I prefer a GC most of the time, and when that's not true I'm fine if the language offers me an escape hatch (unsafe in Go, paired with a native allocator like jemalloc.)
- nicoburns 7y ago
  > I'm very skeptical that it ever gets to the point of a GC language For me, it does impose a (small) cost over a GC language. But other aspects of the language (enums, traits, type inference, etc) are so much better than most mainstream languages that it more than makes up for this. I write JavaScript quicker than I write Rust, but I write Rust quicker than I write Java.
  - pjmlp 7y ago
    > enums, traits, type inference, etc Available in any ML derived language, with the GC productivity.
snazz 7y ago
It really does depend on the problem domain. Go’s type system is probably easier to use for a web app backend, while Rust makes lower-level code easier and stuff involving linear algebra or anything else where a sophisticated type system is useful far less wordy and more safe. I would never write a ray tracer in Go, although it could be done.
BubRoss 7y ago
It is interesting that rust goes for a demographic of people coming from scripting languages or functional languages, but it seems like its niche might be much more suited to the lowest level of larger programs or embedded work where people are using straight C. Straight C seems to be used for transparency and compiler compatibility though, which could be at odds with rust's current workflow. I think pragmatically using rust, modern C++ or even C, any concurrency needs to be done at a generic and separate architectural level that is not part of the day to day refinements and features of a program. I don't think constantly thinking about data races, low level synchronization, or even lifetimes more complex than being returned from the creation scope is ever going to be a recipe for long term success. This is all to say that I think rust's safety strengths are greatest in areas of a program that should actually be as small as possible and changed rarely.
- steveklabnik 7y ago
  This is partially a thing that happened organically. People who don’t come from a low-level background hear “compiler checks your work!” and think “I need a lot of help, that sounds great!”. People who come from a C or C++ background hear it and think “great, something that will get in my way”, and also sometimes think that they know better when they actually don’t. It used to be pretty common for people to jump on IRC and say “ugh I know I’m right how can I get the borrow checker to shut up” and then have something they were missing pointed out to them. The compiler was right, in the end. (This is of course not true all the time but it is a lot of the time...)
- acheron9383 7y ago
  Honestly, coming to Rust from C/C++ is/was a breath of fresh air. I work mostly in C++ for my day job, and with Rust I spend so much less time thinking about the implementation because the compiler will check for me. With C++ I'm always scratching my head about whether I've remembered to make all the constructors properly, whether I'm initializing this variable properly, whether I'm invoking the STL correctly to get a shared_pointer or something. Whether this piece of STL is compatible with some other piece of C++. This list goes on and on. With Rust, the compiler will tell me when I forget things, through the strong type system and borrow checker. It is insane the number of times the code works once it compiles. With Rust, after getting over the hump with lifetimes, I spend so much less time thinking about syntax and language specifics, and so much more time thinking about the business logic of the problem. The language acts like a great belay system to keep me much safer.

by eloff 7y ago

throwaway894345 7y ago

I agree with everything you posted (and I also really like Rust!), but I especially took note of this: > A lot of functional languages offer this by avoiding mutable data, but that's high cost This is true, but the inverse is that Rust's ownership model itself poses its own high cost in terms of a significant cognitive burden (and while I have no doubt that the burden decreases with time, I'm very skeptical that it ever gets to the point of a GC language). This is roughly what you're saying in the second paragraph, but I wanted to be a bit more explicit that the ownership model itself comes with a cost.

steveklabnik 7y ago
I think how low it gets really depends on the person. For me, it's basically zero burden. I don't have to think about these things, the compiler thinks about them! That's kind of the point. I've also internalized the rules, so that I tend to program in a style that works. I am of course, extremely biased, but this story seems to play out with many people who stick with it.
dpc_pw 7y ago
> significant cognitive burden (...) I'm very skeptical that it ever gets to the point of a GC language My experience in this regard: Once you stop thinking in OOP, and embrace Data Oriented Design (which really helps structure your program like Rust wants it to be to avoid lifetimes issues) and get proficient with type system and popular libraries, Rust is far more productive and effortless than mainstream GC languages. I routinely do non-trivial changes to my open source projects late in the evening, after long day of work, after I've finally put my kids to sleep, and despite sloppiness and lethargy it's very much effortless. I don't have to debug weird stuff. Compiler just straight tells me what I did wrong and how to fix it. Languages expressiveness is first class, so I don't have think too much what's the best way to express this or that idea. Then - not only I don't have to worry about `free`, but I also get deterministic destruction: files, sockets and any other "resources" get closed/freed when I'm done with them. And then the libraries... they have beautiful, well-documented, and hard to misuse APIs.
- throwaway894345 7y ago
  I'm already on-board with data-oriented design, and my pedigree includes lots of such projects and languages (C, C++, Go, etc). I'm also familiar with Rust; I've been dabbling in it since ~2014. Still, I come to opposite conclusions. Rust is a magnificent language for many things, but I'm manifold more productive in Go or Python, even in concurrent contexts. Notably, the ownership rules guarantee correctness, but they also prohibit all sorts of correct programs (e.g., functions that only run in a single threaded context or whose shared data doesn't actually mutate). I would say I have the hang of these rules, but I still struggle to make sense of the lifetime error messages (and I find this nearly impossible when I'm tired), contrary to your experience about the clarity of the compiler messaging. I don't mean to slight the compiler--communicating about lifetimes is fundamentally hard; however, the point is that these error messages must be dealt with in all code even though the overwhelming majority of my code isn't subject to race conditions in the first place. I really want to like Rust (I love it in theory); however, frankly I don't see how Rust can approach a GC language with respect for productivity for anyone unless the domain prioritizes correctness and/or performance above all else.
  - lukebitts 7y ago
    > I don't see how Rust can approach a GC language with respect for productivity for anyone My domain is games, and while this usually prioritizes performance that's not really what I care about (so I could be using Python for instance and it would be 'ok'). My take is this: When it comes to productivity even if writing the same code is easier in Python than Rust, working over time in a Python project (or any dynamic language really) is just a nightmare for me. No matter how many tests I write or how I structure my code when I have to add a new feature that touches large parts of the existing system I just have 0 confidence it is correct. I have to run my code through all the branches to make sure I didn't forget to, idk, add the new parameter to all function calls or something. Rust on the hand is just reliable. I can start updating my code with a half baked idea, start adding types to things, removing parameters from functions, changing variables names and I KNOW nothing will sneak on me during runtime. This is more of a feature of strong type systems than Rust itself, but still this is what productivity means to me. (Also, to me lifetimes were the hardest concept to grasp, but I think once you really get what they mean that's when the language clicks and you get the same productivity you would elsewhere)
zozbot234 7y ago
> This is true, but the inverse is that Rust's ownership model itself poses its own high cost in terms of a significant cognitive burden In "burdensome" situations, you can always defer ownership checking to runtime with the Rc<RefCell<T>> and Arc<Mutex<T>> patterns. It's less performant than using pure compile-time checks, but not nearly as problematic as general GC, or immutable-only data structures.
eloff 7y ago
Yes, I agree. Although one must be careful taking about high performance cost like immutable data structures and high cognitive cost like the borrow rules in rust. I think I prefer a GC most of the time, and when that's not true I'm fine if the language offers me an escape hatch (unsafe in Go, paired with a native allocator like jemalloc.)
nicoburns 7y ago
> I'm very skeptical that it ever gets to the point of a GC language For me, it does impose a (small) cost over a GC language. But other aspects of the language (enums, traits, type inference, etc) are so much better than most mainstream languages that it more than makes up for this. I write JavaScript quicker than I write Rust, but I write Rust quicker than I write Java.
- pjmlp 7y ago
  > enums, traits, type inference, etc Available in any ML derived language, with the GC productivity.

snazz 7y ago

It really does depend on the problem domain. Go’s type system is probably easier to use for a web app backend, while Rust makes lower-level code easier and stuff involving linear algebra or anything else where a sophisticated type system is useful far less wordy and more safe. I would never write a ray tracer in Go, although it could be done.

BubRoss 7y ago

It is interesting that rust goes for a demographic of people coming from scripting languages or functional languages, but it seems like its niche might be much more suited to the lowest level of larger programs or embedded work where people are using straight C. Straight C seems to be used for transparency and compiler compatibility though, which could be at odds with rust's current workflow. I think pragmatically using rust, modern C++ or even C, any concurrency needs to be done at a generic and separate architectural level that is not part of the day to day refinements and features of a program. I don't think constantly thinking about data races, low level synchronization, or even lifetimes more complex than being returned from the creation scope is ever going to be a recipe for long term success. This is all to say that I think rust's safety strengths are greatest in areas of a program that should actually be as small as possible and changed rarely.

steveklabnik 7y ago
This is partially a thing that happened organically. People who don’t come from a low-level background hear “compiler checks your work!” and think “I need a lot of help, that sounds great!”. People who come from a C or C++ background hear it and think “great, something that will get in my way”, and also sometimes think that they know better when they actually don’t. It used to be pretty common for people to jump on IRC and say “ugh I know I’m right how can I get the borrow checker to shut up” and then have something they were missing pointed out to them. The compiler was right, in the end. (This is of course not true all the time but it is a lot of the time...)
acheron9383 7y ago
Honestly, coming to Rust from C/C++ is/was a breath of fresh air. I work mostly in C++ for my day job, and with Rust I spend so much less time thinking about the implementation because the compiler will check for me. With C++ I'm always scratching my head about whether I've remembered to make all the constructors properly, whether I'm initializing this variable properly, whether I'm invoking the STL correctly to get a shared_pointer or something. Whether this piece of STL is compatible with some other piece of C++. This list goes on and on. With Rust, the compiler will tell me when I forget things, through the strong type system and borrow checker. It is insane the number of times the code works once it compiles. With Rust, after getting over the hump with lifetimes, I spend so much less time thinking about syntax and language specifics, and so much more time thinking about the business logic of the problem. The language acts like a great belay system to keep me much safer.