12 ms·

Could someone explain why Rust is so damn popular/controversial?

by qz_ 11y ago

jinst8gmi 11y ago
It guarantees memory safety without a GC. The result is a high performance language that doesn't require manual memory management like C or C++, and generally consumes less memory, as noted by the Dropbox guys. It's an expressive language which is also suitable for systems programming. It's a more modern language than Go (in the sense that is incorporates modern features, unlike Go which keeps things simple by sticking to familiar features dating back to the 70's), but does require more time to learn.
- echelon 11y ago
  Rust is also an absolute pleasure to write. It feels like a functional Ruby (minus the bad parts) with types. The RAII is natural; writing C++ feels cludgy by comparison. Cargo is absolutely brilliant, too. It's better than NPM. I'm writing most of my new side projects in Rust now, FWIW.
skoczymroczny 11y ago
I think a lot of people are looking for a replacement for C++ that isn't C#/Java. As in a language that is still low-level enough to offer stuff like pointers, but without the pitfalls and minefield which is C++ (a lot of which is due to historic reasons and backwards compatibility with C). Some newer languages that try to fill the niche are D, Nim, Rust and Go. Can't say much about Nim, it seems to be in the background. Go started as a systems programming language, but since then they backed out on it and it's mostly pushed as nicer C and webservice language. That leaves D and Rust on the field. Both are competing for the same audience, but Rust has the advantage of a popular brand backing (Mozilla) and a potential killer app (Servo, Mozilla's new work in progress browser engine). It also seems to have a clearer vision because of Mozilla backing and constant dogfooding in Servo. Meanwhile D is more of a design by community, as a result it gets not always the features that are needed or people want, but the features people are willing to work on. Also, D gets a lot of backlash from the game dev and system programming languages communities for using a (not too great) garbage collector, whereas Rust uses memory management somewhat similar to C++ model with RAII/smart pointers, however greatly improved and with much stronger static checks. I think people just view Rust as the language that could actually be the alternative to C++, because there is a place for a language that is safer to use than C++, yet performs at similar speeds and doesn't handhold you like C#/Java do.
- gjm11 11y ago
  > Some newer languages that try to fill the niche are D, Nim, Rust and Go. Can't say much about Nim, it seems to be in the background. Nim is frustrating, because to my taste it gets so many things just right while getting one particular thing so spectacularly wrong that I can't bring myself even to try it. The one thing is its rule for when two identifiers are the same. They are compared case-insensitively, ignoring any underscores and en-dashes in either name, except that the first character must match exactly. Consequence #1: if you have, say, something called user_sort (perhaps it's a function that sorts users) and something called use_RSort (perhaps it selects which of two sorting algorithms to use somewhere) then they will be the same identifier, with results anywhere from compilation failure to silent malfunction you don't notice until a year later. Consequence #2: if you want to search for an identifier using some obscure tool like, say, grep or Vim or Eclipse, you're out of luck. (You can make your own tool -- call it "nimgrep", perhaps -- and extensible things like Vim and Eclipse can be given the ability to search for Nim identifiers. But their built-in facilities, like what "*" does in Vim, will do the wrong thing if you are working on Nim code.)
  - nyan4 11y ago
    This criticism usually comes from people that do not use Nim. I was very surprised as well at first - now after 1 year of using Nim I realize I never run into any trouble because of case/underscore insensitivity. #1: those variables have to be in the same scope or be procs working on the same types to be an issue. #2: I don't use nimgrep, I just keep a consistent style across my files. When reading somebody else's code, case-insensitive search is usually enough.
    - gjm11 11y ago
      I suspect this criticism usually comes from people who don't use Nim because anyone inclined to be bothered by it will not use Nim for that reason. I agree that "just keep a consistent style" is a good approach for single-person projects. It's harder to keep it working well as you get more people working on the code, though.
masklinn 11y ago
Relatively recent, trying for a fairly rarefied "niche" (that of C and C++) which many believe has issues (C++) and for which improvements have been in short supply, brings some innovations and safety to said niche (mostly decades-old FP stuff, but affine types are a bit more original, not exactly novel but not in common use either)
llogiq 11y ago
It is so popular because it elegantly solves a set of problems that plague systems-level programming (use-after-free, dangling pointers, data races). It is so controversial because there are system programmers who have lived for so long with those problems that they now refuse their existence.
- tomp 11y ago
  You're right on the pros but dead wrong (intentionally?) on the cons. The real reasons it's controversial are: (1) it requires what some people consider excessive amount of annotations for borrowed types, resulting in visual noise, (2) it has an overly restrictive memory safety model (e.g. it prevents concurrent modification, even when provably safe), (3) it claims to be (memory) "safe", but requires (see 2) the use of "unsafe" features for the most basic tasks, such as implementing various collections. There is other criticism (e.g. allowing overflows), but I think the above is the most controversial.
  - AlisdairO 11y ago
    > (3) it claims to be (memory) "safe", but requires (see 2) the use of "unsafe" features for the most basic tasks, such as implementing various collections. I think this is an interesting one - implementing collections is (IME) the main thing one needs to use unsafe for in rust. Outside of that I barely find myself needing it at all. Unfortunately, collections are also a go-to intro project for a lot of systems programmers, so I can see how it would be easy to get a bad first impression.
  - Certhas 11y ago
    The collections criticism is bizarre. How often do you actually have to use "unsafe" in practice? Collections is one example, but it seems to be quite atypical, and not something you'd typically implement yourself. The argument has always been that it reduces the amount of code you have to check for safety manually. Most of it will be checked by the compiler. Have you run into the problem that most of your code is unsafe? I've only started dabbling in Rust for some projects, but I've not had to write a single line of unsafe yet, and don't see where that would change.
blub 11y ago
Technical reasons alone don't clarify what's happening. Everyone's explaining basically why "Rust is awesome", which is not what was asked. It's popular because Rust fans are heavily promoting it on HN as the solution to certain classes of programming errors. 2016 is probably going to be the year of Rust on HN, generally there's a new language every year such as Ruby, Javascript, etc. This year Go is a strong competitor and Elixir was looking strong but it fizzled out. :-) It's controversial because users of other languages (understandably) don't want to rewrite their project, or they don't want to learn an entire new ecosystem that does exactly what the previous thing did, except in a safer way. Finally, some of them have enough experience to recognise that a new tool is never perfect, and we just haven't had enough time to figure out what the pitfalls and cons of Rust are. The facts that Rust is quite young, has no shipping hero project as a case study and there are basically no jobs available are adding fuel to the fire. Programmers are suckers for a good programming language story and love thinking that there's a language that is truly a joy to program in and will fulfill all their wishes. PL topics are always under heavy discussion.
- jinst8gmi 11y ago
  > The facts that Rust is quite young, has no shipping hero project as a case study Dropbox using it sounds like a pretty good hero project...
  - blub 11y ago
    Hard to say. I've seen posts by jamwt (I assume someone that's working on the said Rust project) which are more confusing than enlightening. In one they say that Dropbox is investing multiple millions in a key piece of infrastructure written in Rust. One month later they say that the project is written in go with some Rust and it will "stay that way". There was also a HN thread, maybe that contains more clues.
    - Manishearth 11y ago
      The fact that it was Go+Rust has never changed. Dropbox had a huge piece of infra being written in Go, they rewrote a core part of it in Rust and got massive savings from that. I presume a lot of that infra isn't bottlenecked by perf, so it doesn't make sense to rewrite it.
SpaceCadetJones 11y ago
Personally, what caught my attention was that it's a systems language with a lot of inspiration from ML.

Could someone explain why Rust is so damn popular/controversial?

by qz_ 11y ago

Could someone explain why Rust is so damn popular/controversial?

It guarantees memory safety without a GC. The result is a high performance language that doesn't require manual memory management like C or C++, and generally consumes less memory, as noted by the Dropbox guys. It's an expressive language which is also suitable for systems programming. It's a more modern language than Go (in the sense that is incorporates modern features, unlike Go which keeps things simple by sticking to familiar features dating back to the 70's), but does require more time to learn.

echelon 11y ago
Rust is also an absolute pleasure to write. It feels like a functional Ruby (minus the bad parts) with types. The RAII is natural; writing C++ feels cludgy by comparison. Cargo is absolutely brilliant, too. It's better than NPM. I'm writing most of my new side projects in Rust now, FWIW.

skoczymroczny 11y ago

I think a lot of people are looking for a replacement for C++ that isn't C#/Java. As in a language that is still low-level enough to offer stuff like pointers, but without the pitfalls and minefield which is C++ (a lot of which is due to historic reasons and backwards compatibility with C). Some newer languages that try to fill the niche are D, Nim, Rust and Go. Can't say much about Nim, it seems to be in the background. Go started as a systems programming language, but since then they backed out on it and it's mostly pushed as nicer C and webservice language. That leaves D and Rust on the field. Both are competing for the same audience, but Rust has the advantage of a popular brand backing (Mozilla) and a potential killer app (Servo, Mozilla's new work in progress browser engine). It also seems to have a clearer vision because of Mozilla backing and constant dogfooding in Servo. Meanwhile D is more of a design by community, as a result it gets not always the features that are needed or people want, but the features people are willing to work on. Also, D gets a lot of backlash from the game dev and system programming languages communities for using a (not too great) garbage collector, whereas Rust uses memory management somewhat similar to C++ model with RAII/smart pointers, however greatly improved and with much stronger static checks. I think people just view Rust as the language that could actually be the alternative to C++, because there is a place for a language that is safer to use than C++, yet performs at similar speeds and doesn't handhold you like C#/Java do.

gjm11 11y ago
> Some newer languages that try to fill the niche are D, Nim, Rust and Go. Can't say much about Nim, it seems to be in the background. Nim is frustrating, because to my taste it gets so many things just right while getting one particular thing so spectacularly wrong that I can't bring myself even to try it. The one thing is its rule for when two identifiers are the same. They are compared case-insensitively, ignoring any underscores and en-dashes in either name, except that the first character must match exactly. Consequence #1: if you have, say, something called user_sort (perhaps it's a function that sorts users) and something called use_RSort (perhaps it selects which of two sorting algorithms to use somewhere) then they will be the same identifier, with results anywhere from compilation failure to silent malfunction you don't notice until a year later. Consequence #2: if you want to search for an identifier using some obscure tool like, say, grep or Vim or Eclipse, you're out of luck. (You can make your own tool -- call it "nimgrep", perhaps -- and extensible things like Vim and Eclipse can be given the ability to search for Nim identifiers. But their built-in facilities, like what "*" does in Vim, will do the wrong thing if you are working on Nim code.)
- nyan4 11y ago
  This criticism usually comes from people that do not use Nim. I was very surprised as well at first - now after 1 year of using Nim I realize I never run into any trouble because of case/underscore insensitivity. #1: those variables have to be in the same scope or be procs working on the same types to be an issue. #2: I don't use nimgrep, I just keep a consistent style across my files. When reading somebody else's code, case-insensitive search is usually enough.
  - gjm11 11y ago
    I suspect this criticism usually comes from people who don't use Nim because anyone inclined to be bothered by it will not use Nim for that reason. I agree that "just keep a consistent style" is a good approach for single-person projects. It's harder to keep it working well as you get more people working on the code, though.

masklinn 11y ago

Relatively recent, trying for a fairly rarefied "niche" (that of C and C++) which many believe has issues (C++) and for which improvements have been in short supply, brings some innovations and safety to said niche (mostly decades-old FP stuff, but affine types are a bit more original, not exactly novel but not in common use either)

llogiq 11y ago

It is so popular because it elegantly solves a set of problems that plague systems-level programming (use-after-free, dangling pointers, data races). It is so controversial because there are system programmers who have lived for so long with those problems that they now refuse their existence.

tomp 11y ago
You're right on the pros but dead wrong (intentionally?) on the cons. The real reasons it's controversial are: (1) it requires what some people consider excessive amount of annotations for borrowed types, resulting in visual noise, (2) it has an overly restrictive memory safety model (e.g. it prevents concurrent modification, even when provably safe), (3) it claims to be (memory) "safe", but requires (see 2) the use of "unsafe" features for the most basic tasks, such as implementing various collections. There is other criticism (e.g. allowing overflows), but I think the above is the most controversial.
- AlisdairO 11y ago
  > (3) it claims to be (memory) "safe", but requires (see 2) the use of "unsafe" features for the most basic tasks, such as implementing various collections. I think this is an interesting one - implementing collections is (IME) the main thing one needs to use unsafe for in rust. Outside of that I barely find myself needing it at all. Unfortunately, collections are also a go-to intro project for a lot of systems programmers, so I can see how it would be easy to get a bad first impression.
- Certhas 11y ago
  The collections criticism is bizarre. How often do you actually have to use "unsafe" in practice? Collections is one example, but it seems to be quite atypical, and not something you'd typically implement yourself. The argument has always been that it reduces the amount of code you have to check for safety manually. Most of it will be checked by the compiler. Have you run into the problem that most of your code is unsafe? I've only started dabbling in Rust for some projects, but I've not had to write a single line of unsafe yet, and don't see where that would change.

blub 11y ago

Technical reasons alone don't clarify what's happening. Everyone's explaining basically why "Rust is awesome", which is not what was asked. It's popular because Rust fans are heavily promoting it on HN as the solution to certain classes of programming errors. 2016 is probably going to be the year of Rust on HN, generally there's a new language every year such as Ruby, Javascript, etc. This year Go is a strong competitor and Elixir was looking strong but it fizzled out. :-) It's controversial because users of other languages (understandably) don't want to rewrite their project, or they don't want to learn an entire new ecosystem that does exactly what the previous thing did, except in a safer way. Finally, some of them have enough experience to recognise that a new tool is never perfect, and we just haven't had enough time to figure out what the pitfalls and cons of Rust are. The facts that Rust is quite young, has no shipping hero project as a case study and there are basically no jobs available are adding fuel to the fire. Programmers are suckers for a good programming language story and love thinking that there's a language that is truly a joy to program in and will fulfill all their wishes. PL topics are always under heavy discussion.

jinst8gmi 11y ago
> The facts that Rust is quite young, has no shipping hero project as a case study Dropbox using it sounds like a pretty good hero project...
- blub 11y ago
  Hard to say. I've seen posts by jamwt (I assume someone that's working on the said Rust project) which are more confusing than enlightening. In one they say that Dropbox is investing multiple millions in a key piece of infrastructure written in Rust. One month later they say that the project is written in go with some Rust and it will "stay that way". There was also a HN thread, maybe that contains more clues.
  - Manishearth 11y ago
    The fact that it was Go+Rust has never changed. Dropbox had a huge piece of infra being written in Go, they rewrote a core part of it in Rust and got massive savings from that. I presume a lot of that infra isn't bottlenecked by perf, so it doesn't make sense to rewrite it.

SpaceCadetJones 11y ago

Personally, what caught my attention was that it's a systems language with a lot of inspiration from ML.