10 ms·

Why is Rust so popular on HN? Honest question.

by MikkoFinell 8y ago

jannes 8y ago
Probably because of its memory safety, which enables easier parallelisation of workloads among other things.
- MikkoFinell 8y ago
  Couldn't you achieve the same thing in C++ by using message passing between threads instead of shared memory? That way, you would get safe parallelisation without having to fight the borrow checker in every part of the program. I understand that having safety statically enforced at compile time is a real gain in terms of eliminating that class of bugs. However, the mental cost a Rust programmer pays for that trade (due to borrow checker) seems too high for me if you can get the same thing simply by shifting your programming patterns slightly.
  - heinrich5991 8y ago
    No, you can't. It's either performance or bugs – look at the big C++ projects.
  - exDM69 8y ago
    > However, the mental cost a Rust programmer pays for that trade (due to borrow checker) seems too high for me In C++ land, you'd have to use TSan thread sanitizer and a lot of other tooling (ASan, Valgrind, etc) to achieve even close to the same level of confidence. Not only is this a runtime check but all that tooling has a fairly heavy mental cost too.
  - danieldk 8y ago
    Couldn't you achieve the same thing in C++ by using message passing between threads instead of shared memory? I know that the parent post used multi-threading as an argument in favor of Rust. But there are many ways to blow of your foot in single threaded C++. For example, consider this single-threaded code: std::vector<size_t> v; v.push_back(1); size_t *first = &v[0]; std::cout << *first << std::endl; // The STL vector implementation will probably // reallocate the backing array at least once. for (size_t i = 2; i < 1000; i++) v.push_back(i); std::cout << *first << std::endl; You wouldn't be able to introduce the same error in Rust. Once you borrow the an element of a Vec immutably, you cannot create mutable borrows during the lifetime of any immutable borrows. So the compiler would reject pushing new elements. However, the mental cost a Rust programmer pays for that trade (due to borrow checker) seems too high for me The thing is that most of the errors that the borrow checker will point out are potential programming errors in C or C++ as well. However, current C/C++ compilers will put most of the responsibility completely on you (plus tools like Valgrind). So, to me C++ has at least the same cognitive load if you want to program responsibly.
    - rtpg 8y ago
      I agree with the general principle, but programming in Rust is not "program in C++, then fix errors". You really need to lay your code in away that will satisfy the checkers. That or jump into unsafe mode. A good example of the challenge is that there's unsafe inner code in rusts own container code. If you try to build your own custom containers (or things like arenas) you'll likely work with unsafe code... Or rely on rusts container code (not a bad thing of course). My feeling is that "C to Rust" is close to "Java to Haskell" more than anything else. The extra layers are important enough that they need a new thought process. (I say this as a proponent of rust)
      - xfer 8y ago
        Same thing is also true in C++, the stdlib also uses "unsafe" pointers inside, but you can use unique, shared etc. > You really need to lay your code in away that will satisfy the checkers. There are some patterns that are common but problematic but are being addressed by non-lexical lifetimes. Other than that it's almost "program in C++, then fix errors".
      - danieldk 8y ago
        You really need to lay your code in away that will satisfy the checkers. But that becomes a second nature after a while. I think all the edge cases that still exist make it more problematic. E.g. I was writing some SIMD code yesterday with a loop somewhat like this (simplified): let mut v = vec![1.0, 2.0, 3.0, 4.0, 5.0, 6.0]; let mut s: &mut [f32] = &mut v; while s.len() >= 2 { println!("{:?}", s); s = &mut s[2..]; } Playground: https://play.rust-lang.org/?gist=104348b0edb96ca0f68d701373eca7fa https://play.rust-lang.org/?gist=104348b0edb96ca0f68d701373e... It makes you scratch your head for a bit. A good example of the challenge is that there's unsafe inner code in rusts own container code. I am pretty proud that one of my first small Rust projects was a randomized ternary trie. Apparently, it does not use unsafe anywhere. https://github.com/danieldk/rtrie/blob/master/src/ternary.rs https://github.com/danieldk/rtrie/blob/master/src/ternary.rs Not that I am proud of the code ;). But in all seriousness, unsafe in container code is somewhat expected, because at some point you need to wrap raw memory (as e.g. in Vec). I think quite a bit of, but probably not all, unsafe use in containers such as Vec comes from that.
  - Ygg2 8y ago
    Mozilla was full of talented C++ programers. They thought it worthwhile to invent a new safer language for massive parallelism and security, rather than to attempt it in C++. Also coming from Java, the Rust experience is not that painful. It's like learning a completely foreign language.
  - unrealhoang 8y ago
    I think you misunderstood Rust. There’s no additional mental cost compared to C++. In C++ you must do thing the same way (keep track of references, variable lifetimes) in order to write any sane program. Rust just help you to declare those things and ask the compiler to enforce it. And no, message passing is not the savior to parallelisation.
    - sirclueless 8y ago
      There is definitely some mental cost. By making lifetimes explicit there are additional barriers in the way of doing certain things that are safe but involve invariants that are too high-level for rust's semantics. For example, taking mutable references to multiple elements of a container simultaneously.
      - steveklabnik 8y ago
        This cuts both ways. Because I can offload checking from my brain to the compiler, I feel personally that the mental cost is actually reduced overall. YMMV.
      - unrealhoang 8y ago
        .split_at_mut(), there you go. But I understand that there are cases when Rust rejects correct program, that is where we need unsafe to build safe abstraction. Come back to additional mental cost, it’s just the same debate between static & dynamic typed language. Either you write more, specify constraints, and have the usage checked or you write less, imply your constraints and must satisfy the constraints of usage by yourself (or with helper tools/tests). To me that’s just “when” I have to spend the mental resource, and the total cost is roughly the same. But then, knowing the separation helps to choose which tool for which type of project.
        sirclueless 8y ago
        I don't think this is just about being more or less verbose. It's about the awkward ways it contorts the ways you write programs. For example, in C++ you might write an asynchronous job scheduler with an API like the following: void Scheduler::schedule(const Job& job, Result* result); void Scheduler::wait(); The consumer of this API in C++ has an easy job. They can create an array of results and iteratively call schedule(jobs[i], &results[i]) for each job, and then call wait(). A similar API in Rust would be a giant pain in the neck to use, because there's no simple way to collect the results. You'd likely want to scrap this API entirely and have Scheduler expose some kind of queue or something. My point is that these extra constraints are not just extra typing locally to specify how you're using lifetimes. You'll likely have to rethink the way you write APIs and whole programs in Rust because of the ways it restricts mutability. Which is OK, it's a trade-off, all I'm saying is the safety doesn't come for free.
  - stefs 8y ago
    > However, the mental cost a Rust programmer pays for that trade (due to borrow checker) seems too high for me if you can get the same thing simply by shifting your programming patterns slightly. i remember reading about the stylo (multithreaded css styling) engine, something that has been tried times and times again to implement it in C++ without success: too complicated. sooner or later you'll get too-hard concurrency bugs and the project would be abandoned. and it wasn't just mozilla with firefox, google also failed to implement concurrent styling with chrome. the blog post stated that this time they were successful _only because of rust_. the mental overhead of managing the borrow checker is far lower than the mental overhead of dealing with concurrency issues in a complex high performance project.
noelwelsh 8y ago
Because it's interesting. It is interesting because it advances the state of the art: it makes safe "systems programming" possible, which no production ready language previously provided. It is interesting because it is accessible to many of the people who frequent HN. It's community is similar enough to the community of HN readers that many HN readers can use Rust and not feel out of place. The concepts it introduces are not such a departure from the concepts familiar to many programmers that a huge amount of learning is required. (Compare to, say, more research oriented languages like Idris).
- pdpi 8y ago
  > The concepts it introduces are not such a departure from the concepts familiar to many programmers that a huge amount of learning is required. More specifically, I would say that it lands in the Goldilocks range: It's not so alien as to make it inaccessible, while being alien enough that you'll learn something from it.
- dozzie 8y ago
  > it makes safe "systems programming" possible, which no production ready language previously provided. I think you have just made Ada and several other languages disappear from the history.
  - noelwelsh 8y ago
    Yeah, "production ready" was the wrong phrase. It's more a combination of availability of language compiler, tooling, training, and interest from developers. If you start a new project using Rust there is a reasonable chance you'll be able to find libraries for common tasks and developers willing to work on it. You can make a case for it and not lose your job. With Ada, outside of a few niches that isn't going to be the case IMO. It's been a long time since I looked at Ada, but I believe it's memory mgmt is more inline with modern C++ than Rust. So perhaps it's not truly comparable.
  - kibwen 8y ago
    The thing that Ada and its peers lack that Rust has already tackled is finding a strong foothold in OSS. Doubtless there are more lines of Ada than Rust in the wild, but in 30 years of use the only OSS Ada project I can name is GNAT itself, whereas anyone using e.g. Firefox or VSCode is using Rust despite it being ten times younger. Given that most new developers these days seem to learn to program via OSS, and given that HN is largely OSS-focused, it's no surprise that Rust gets mentioned more.
yitchelle 8y ago
Because it is has the potential to unseat C as the go to language for deeply embedded code. The safety aspect of Rust is quite compelling for Functional Safety applications in automotive, medical and aerospace domain. I can't wait for it to mature and be mass adopted.
- MikkoFinell 8y ago
  Are there any studies done that looks at the relative amount of bugs in C code compared to Rust? Making the claim that Rust is better for those applications isn't convincing to me until I can see the statistics that backs it up.
  - staticassertion 8y ago
    I think you'll have a hard time finding conclusive research like this for any languages. Many papers exist but often have conflicting results, or weird methodologies, or extreme artificiality. It's really expensive/ hard to generate good research on this topic that controls for the big variables - you basically need a company that's willing to throw away at on of developer time to build two versions of the same product in both languages, then a metric for measuring success, a way to ensure you take dev skill into account, etc. So instead it seems a lot more worthwhile to not bother looking for objective research as it won't be found. I think a better approach is to just use what we have - sense and anecdotes. From a sensibility standpoint, let's take a step back from rust. Do we expect fewer memory safety vulnerabilities in Java vs C? Probably yes - Java is a memory safe language with few escape hatches. So what about Rust vs C? It's a bit less clear as rust has a more oft used escape hatch, but I think we can reason that it's likely to have fewer memory safety bugs. Would we expect fewer bugs in general? That's much harder to discuss with that approach. You can look at testaments from Servo devs, and other companies using Rust ( https://www.rust-lang.org/en-US/whitepapers.html https://www.rust-lang.org/en-US/whitepapers.html ) and their experiences.
  - pcwalton 8y ago
    We looked at the number of security-critical bugs in one new component of Firefox—Web Audio—a few years ago in order to determine how many of them a memory-safe language would have prevented. The answer was 100%.
DC-3 8y ago
Have you tried it? If you have - why do you think it shouldn't be as popular as it is? If not, perhaps in using it you will discover why it is popular.
- majewsky 8y ago
  I sort of agree, but trying everything that's new and popular just doesn't scale. At some point, everyone needs to get on with their life.
  - AnIdiotOnTheNet 8y ago
    Maybe I'm getting old and cynical, but the fact that something is both new and popular makes me even more reluctant to try it. The commons seem to be really good at picking mediocre-at-best winners, and fad chasing is really common.
    - Retra 8y ago
      Yes, but "mediocre" is not measurable on an absolute scale. If you're trying to obsolete 50-year old technology, today's mediocre technology is probably good enough. Rust is a fairly conservative language. It doesn't really do anything novel, it mostly just synthesizes patterns that have existed for years. Hopefully Rust truly is mediocre (at least in hindsight). That would mean the things it is attempting to replace are seen for how primitive they truly are.
      - GolDDranks 8y ago
        Sorry for a moot comment but. This is so well said that I agree 100%, and couldn't say it any better.
olavk 8y ago
I find it interesting because of the novel approach to memory management. It is deterministic and zero-overhead like C, C++ and similar, while at the same time safe like garbage collected languages. I think of it like a compile-time garbage collection. I wouldn't use it as an alternative to garbage collected languages since garbage collection is just simpler overall, but I would consider using it as a safer alternative to C or C++.
- danieldk 8y ago
  I wouldn't use it as an alternative to garbage collected languages since garbage collection is just simpler overall, I do not disagree, but I think one could argue to the contrary as well. Since most garbage collected languages do not guarantee that objects are actually (timely) garbage collected, you cannot tie the lifetime of other resources (file descriptors, sockets, locks) to object lifetimes. So, the burden is on the programmer to ensure that resources are correctly finalized. Whereas in RAII languages you can properly tie all finalization to object lifetimes. Note: I am not arguing that GC-ed languages cannot do RAII. AFAIR D has a GC and supports RAII.
  - olavk 8y ago
    This is true - for example, C# has the `using` block to ensure resources are deterministically released when they go out of scope, not when they at some point later are garbage collected. I would still argue C# is much simpler than Rust since for most object you don't have to worry about this. But I guess there is a certain extra complexity in C# because you actually have to know if a class owns some external resource or not, while this distinction is not necessary in Rust.
    - moomin 8y ago
      In practice that's rarely an issue, because a) if it has a resource it'll implement IDisposable and b) my IDE screams when I don't dispose an IDisposable. This is not as good as the Rust model, but it's not awful, either.
exDM69 8y ago
It's the first "new" language in a long time that is viable for embedded/bare metal/kernel space, high performance and real time applications. The memory safety concepts are novel and unique to Rust but enough has been talked about them already. Additionally, it brings a lot of features from "advanced" programming languages (ML, Haskell) to a more mainstream language. Sum types, pattern matching, powerful macros. None of these are new or unique, but are executed particularly well in Rust. In addition to the new features and concepts, the Rust compiler and ecosystem are well engineered and have a good amount of support. It's the first "new" programming language in a decades worth getting excited about. Ok, maybe I was a bit excited about Julia too, but their execution is not as great as Rust's (and they have made some questionable design decisions).
- sevensor 8y ago
  There's also the community. I've never seen another language community built with so much deliberate effort, rather than just accreting around a project. And for a language like Rust, I think this is necessary -- with so many unfamiliar concepts and new ways to fail, it would have been very hard to get any traction without a strong community push.
- ThenAsNow 8y ago
  > Ok, maybe I was a bit excited about Julia too, but their execution is not as great as Rust's (and they have made some questionable design decisions). Could you expound on this? The code I currently write and expect to write in the near-to-mid-term is numerical for engineering purposes. I have the luxury of being able to write greenfield projects, at least for now. My experience with OCaml has inculcated a deep appreciation for powerful type systems and functional styles, so Python, despite its awesome ecosystem, is not particularly of interest. Julia appears to be the natural choice in this space for new development, but I've been a little leery after reading about Dan Luu's experience a couple of years ago: http://danluu.com/julialang/ http://danluu.com/julialang/ I'm interested in reasoned criticisms of Julia as it stands now, and what modern practical alternatives people have found.
coffeeacc 8y ago
Has it appeared more often than eg Go?
- deleted 8y ago
  [deleted]
- swsieber 8y ago
  I think go used top appear more often than rust (maybe as often as rust does now), but I think it's started appearing less frequently.
rkangel 8y ago
Because Hacker news has a large population of systems programmers, and we are desperate for something to liberate us from C and C++. We have watched programming languages advance apace in other areas, helping engineers be more productive and produce a higher quality output, but in the systems space nothing has come along that provides enough benefit for a low enough adoption cost for it to be a worthwhile choice over C and C++. Rust shows some promise of being that language, and so we hold out hope and enjoy reading about it.
codetrotter 8y ago
The promises about memory safety was what initially made me interested in it. When it turned out that it was actually possible to learn, it was comfortable to write for someone with Python and C/C++ experience like me, and I saw Cargo and that the ecosystem of packages was quickly growing is when I fell in love with it.
oconnor663 8y ago
Apart from all the other things people are mentioning, I'd add that the development of Rust happens in the open. That means that a lot of very interesting debates are there on GitHub for everyone to read. For example, here's where arielb1 discovered that the original scoped threads design was unsound: https://github.com/rust-lang/rust/issues/24292 https://github.com/rust-lang/rust/issues/24292 (which sparked a large debate about whether mem::forget should be allowed in safe code: https://github.com/rust-lang/rfcs/pull/1066 https://github.com/rust-lang/rfcs/pull/1066).
throwajay79367 8y ago
What I find an even more interesting is that every story about rust have posts whining about hn posts about rust. this is such a boring, ever-present “question” that i don’t actually believe you asked it honestly.
- catach 8y ago
  Seems to me that Rust's current point on the popularity curve suggests that the vast majority of programmers probably don't know much at all about the lang, or even that it exists. Busy people can note that there's plenty of HN threads about a thing without investigating further. Until they finally do. Better to be charitable, I think. Doing so costs us nothing.
staticassertion 8y ago
To give a somewhat different reason than what I'm seeing, I don't care too much about the 'memory safety plus speed' thing. I'm often building services that would be "fast enough" in Java. Is it nice to be faster? Yes, definitely, and that's part of why I write Rust, but not the whole story by any means. I like rust for a few reasons. * I really like Rust developers - I've met many, talked with many, and we get along and they've helped me through many technical problems, both big and small. * I found rust extremely easy to get started with. I knew I'd have to learn the language, I did not also want to learn build tooling, package management, etc. These barriers exist in many other languages, it's frustrating because I just want to focus on programming. Cargo is excellent and I am a huge fan of how rust manages crates. * I find it very easy to express what I want in rust, to reason about the code, etc. I know when a function might error, I know when I need to handle some unforseen case, I can express how a variable is used, when it is usable, whether it can be mutated. I can cut down on boilerplate with generics and macros. The last point is what keeps me coming back. I find rust extremely easy to write, because it makes the things I care about easy to express.

Why is Rust so popular on HN? Honest question.

jannes 8y ago

Probably because of its memory safety, which enables easier parallelisation of workloads among other things.

MikkoFinell 8y ago
Couldn't you achieve the same thing in C++ by using message passing between threads instead of shared memory? That way, you would get safe parallelisation without having to fight the borrow checker in every part of the program. I understand that having safety statically enforced at compile time is a real gain in terms of eliminating that class of bugs. However, the mental cost a Rust programmer pays for that trade (due to borrow checker) seems too high for me if you can get the same thing simply by shifting your programming patterns slightly.
- heinrich5991 8y ago
  No, you can't. It's either performance or bugs – look at the big C++ projects.
- exDM69 8y ago
  > However, the mental cost a Rust programmer pays for that trade (due to borrow checker) seems too high for me In C++ land, you'd have to use TSan thread sanitizer and a lot of other tooling (ASan, Valgrind, etc) to achieve even close to the same level of confidence. Not only is this a runtime check but all that tooling has a fairly heavy mental cost too.
- danieldk 8y ago
  Couldn't you achieve the same thing in C++ by using message passing between threads instead of shared memory? I know that the parent post used multi-threading as an argument in favor of Rust. But there are many ways to blow of your foot in single threaded C++. For example, consider this single-threaded code: std::vector<size_t> v; v.push_back(1); size_t *first = &v[0]; std::cout << *first << std::endl; // The STL vector implementation will probably // reallocate the backing array at least once. for (size_t i = 2; i < 1000; i++) v.push_back(i); std::cout << *first << std::endl; You wouldn't be able to introduce the same error in Rust. Once you borrow the an element of a Vec immutably, you cannot create mutable borrows during the lifetime of any immutable borrows. So the compiler would reject pushing new elements. However, the mental cost a Rust programmer pays for that trade (due to borrow checker) seems too high for me The thing is that most of the errors that the borrow checker will point out are potential programming errors in C or C++ as well. However, current C/C++ compilers will put most of the responsibility completely on you (plus tools like Valgrind). So, to me C++ has at least the same cognitive load if you want to program responsibly.
  - rtpg 8y ago
    I agree with the general principle, but programming in Rust is not "program in C++, then fix errors". You really need to lay your code in away that will satisfy the checkers. That or jump into unsafe mode. A good example of the challenge is that there's unsafe inner code in rusts own container code. If you try to build your own custom containers (or things like arenas) you'll likely work with unsafe code... Or rely on rusts container code (not a bad thing of course). My feeling is that "C to Rust" is close to "Java to Haskell" more than anything else. The extra layers are important enough that they need a new thought process. (I say this as a proponent of rust)
    - xfer 8y ago
      Same thing is also true in C++, the stdlib also uses "unsafe" pointers inside, but you can use unique, shared etc. > You really need to lay your code in away that will satisfy the checkers. There are some patterns that are common but problematic but are being addressed by non-lexical lifetimes. Other than that it's almost "program in C++, then fix errors".
    - danieldk 8y ago
      You really need to lay your code in away that will satisfy the checkers. But that becomes a second nature after a while. I think all the edge cases that still exist make it more problematic. E.g. I was writing some SIMD code yesterday with a loop somewhat like this (simplified): let mut v = vec![1.0, 2.0, 3.0, 4.0, 5.0, 6.0]; let mut s: &mut [f32] = &mut v; while s.len() >= 2 { println!("{:?}", s); s = &mut s[2..]; } Playground: https://play.rust-lang.org/?gist=104348b0edb96ca0f68d701373eca7fa https://play.rust-lang.org/?gist=104348b0edb96ca0f68d701373e... It makes you scratch your head for a bit. A good example of the challenge is that there's unsafe inner code in rusts own container code. I am pretty proud that one of my first small Rust projects was a randomized ternary trie. Apparently, it does not use unsafe anywhere. https://github.com/danieldk/rtrie/blob/master/src/ternary.rs https://github.com/danieldk/rtrie/blob/master/src/ternary.rs Not that I am proud of the code ;). But in all seriousness, unsafe in container code is somewhat expected, because at some point you need to wrap raw memory (as e.g. in Vec). I think quite a bit of, but probably not all, unsafe use in containers such as Vec comes from that.
- Ygg2 8y ago
  Mozilla was full of talented C++ programers. They thought it worthwhile to invent a new safer language for massive parallelism and security, rather than to attempt it in C++. Also coming from Java, the Rust experience is not that painful. It's like learning a completely foreign language.
- unrealhoang 8y ago
  I think you misunderstood Rust. There’s no additional mental cost compared to C++. In C++ you must do thing the same way (keep track of references, variable lifetimes) in order to write any sane program. Rust just help you to declare those things and ask the compiler to enforce it. And no, message passing is not the savior to parallelisation.
  - sirclueless 8y ago
    There is definitely some mental cost. By making lifetimes explicit there are additional barriers in the way of doing certain things that are safe but involve invariants that are too high-level for rust's semantics. For example, taking mutable references to multiple elements of a container simultaneously.
    - steveklabnik 8y ago
      This cuts both ways. Because I can offload checking from my brain to the compiler, I feel personally that the mental cost is actually reduced overall. YMMV.
    - unrealhoang 8y ago
      .split_at_mut(), there you go. But I understand that there are cases when Rust rejects correct program, that is where we need unsafe to build safe abstraction. Come back to additional mental cost, it’s just the same debate between static & dynamic typed language. Either you write more, specify constraints, and have the usage checked or you write less, imply your constraints and must satisfy the constraints of usage by yourself (or with helper tools/tests). To me that’s just “when” I have to spend the mental resource, and the total cost is roughly the same. But then, knowing the separation helps to choose which tool for which type of project.
      - sirclueless 8y ago
        I don't think this is just about being more or less verbose. It's about the awkward ways it contorts the ways you write programs. For example, in C++ you might write an asynchronous job scheduler with an API like the following: void Scheduler::schedule(const Job& job, Result* result); void Scheduler::wait(); The consumer of this API in C++ has an easy job. They can create an array of results and iteratively call schedule(jobs[i], &results[i]) for each job, and then call wait(). A similar API in Rust would be a giant pain in the neck to use, because there's no simple way to collect the results. You'd likely want to scrap this API entirely and have Scheduler expose some kind of queue or something. My point is that these extra constraints are not just extra typing locally to specify how you're using lifetimes. You'll likely have to rethink the way you write APIs and whole programs in Rust because of the ways it restricts mutability. Which is OK, it's a trade-off, all I'm saying is the safety doesn't come for free.
- stefs 8y ago
  > However, the mental cost a Rust programmer pays for that trade (due to borrow checker) seems too high for me if you can get the same thing simply by shifting your programming patterns slightly. i remember reading about the stylo (multithreaded css styling) engine, something that has been tried times and times again to implement it in C++ without success: too complicated. sooner or later you'll get too-hard concurrency bugs and the project would be abandoned. and it wasn't just mozilla with firefox, google also failed to implement concurrent styling with chrome. the blog post stated that this time they were successful _only because of rust_. the mental overhead of managing the borrow checker is far lower than the mental overhead of dealing with concurrency issues in a complex high performance project.

noelwelsh 8y ago

Because it's interesting. It is interesting because it advances the state of the art: it makes safe "systems programming" possible, which no production ready language previously provided. It is interesting because it is accessible to many of the people who frequent HN. It's community is similar enough to the community of HN readers that many HN readers can use Rust and not feel out of place. The concepts it introduces are not such a departure from the concepts familiar to many programmers that a huge amount of learning is required. (Compare to, say, more research oriented languages like Idris).

pdpi 8y ago
> The concepts it introduces are not such a departure from the concepts familiar to many programmers that a huge amount of learning is required. More specifically, I would say that it lands in the Goldilocks range: It's not so alien as to make it inaccessible, while being alien enough that you'll learn something from it.
dozzie 8y ago
> it makes safe "systems programming" possible, which no production ready language previously provided. I think you have just made Ada and several other languages disappear from the history.
- noelwelsh 8y ago
  Yeah, "production ready" was the wrong phrase. It's more a combination of availability of language compiler, tooling, training, and interest from developers. If you start a new project using Rust there is a reasonable chance you'll be able to find libraries for common tasks and developers willing to work on it. You can make a case for it and not lose your job. With Ada, outside of a few niches that isn't going to be the case IMO. It's been a long time since I looked at Ada, but I believe it's memory mgmt is more inline with modern C++ than Rust. So perhaps it's not truly comparable.
- kibwen 8y ago
  The thing that Ada and its peers lack that Rust has already tackled is finding a strong foothold in OSS. Doubtless there are more lines of Ada than Rust in the wild, but in 30 years of use the only OSS Ada project I can name is GNAT itself, whereas anyone using e.g. Firefox or VSCode is using Rust despite it being ten times younger. Given that most new developers these days seem to learn to program via OSS, and given that HN is largely OSS-focused, it's no surprise that Rust gets mentioned more.

yitchelle 8y ago

Because it is has the potential to unseat C as the go to language for deeply embedded code. The safety aspect of Rust is quite compelling for Functional Safety applications in automotive, medical and aerospace domain. I can't wait for it to mature and be mass adopted.

MikkoFinell 8y ago
Are there any studies done that looks at the relative amount of bugs in C code compared to Rust? Making the claim that Rust is better for those applications isn't convincing to me until I can see the statistics that backs it up.
- staticassertion 8y ago
  I think you'll have a hard time finding conclusive research like this for any languages. Many papers exist but often have conflicting results, or weird methodologies, or extreme artificiality. It's really expensive/ hard to generate good research on this topic that controls for the big variables - you basically need a company that's willing to throw away at on of developer time to build two versions of the same product in both languages, then a metric for measuring success, a way to ensure you take dev skill into account, etc. So instead it seems a lot more worthwhile to not bother looking for objective research as it won't be found. I think a better approach is to just use what we have - sense and anecdotes. From a sensibility standpoint, let's take a step back from rust. Do we expect fewer memory safety vulnerabilities in Java vs C? Probably yes - Java is a memory safe language with few escape hatches. So what about Rust vs C? It's a bit less clear as rust has a more oft used escape hatch, but I think we can reason that it's likely to have fewer memory safety bugs. Would we expect fewer bugs in general? That's much harder to discuss with that approach. You can look at testaments from Servo devs, and other companies using Rust ( https://www.rust-lang.org/en-US/whitepapers.html https://www.rust-lang.org/en-US/whitepapers.html ) and their experiences.
- pcwalton 8y ago
  We looked at the number of security-critical bugs in one new component of Firefox—Web Audio—a few years ago in order to determine how many of them a memory-safe language would have prevented. The answer was 100%.

DC-3 8y ago

Have you tried it? If you have - why do you think it shouldn't be as popular as it is? If not, perhaps in using it you will discover why it is popular.

majewsky 8y ago
I sort of agree, but trying everything that's new and popular just doesn't scale. At some point, everyone needs to get on with their life.
- AnIdiotOnTheNet 8y ago
  Maybe I'm getting old and cynical, but the fact that something is both new and popular makes me even more reluctant to try it. The commons seem to be really good at picking mediocre-at-best winners, and fad chasing is really common.
  - Retra 8y ago
    Yes, but "mediocre" is not measurable on an absolute scale. If you're trying to obsolete 50-year old technology, today's mediocre technology is probably good enough. Rust is a fairly conservative language. It doesn't really do anything novel, it mostly just synthesizes patterns that have existed for years. Hopefully Rust truly is mediocre (at least in hindsight). That would mean the things it is attempting to replace are seen for how primitive they truly are.
    - GolDDranks 8y ago
      Sorry for a moot comment but. This is so well said that I agree 100%, and couldn't say it any better.

olavk 8y ago

I find it interesting because of the novel approach to memory management. It is deterministic and zero-overhead like C, C++ and similar, while at the same time safe like garbage collected languages. I think of it like a compile-time garbage collection. I wouldn't use it as an alternative to garbage collected languages since garbage collection is just simpler overall, but I would consider using it as a safer alternative to C or C++.

danieldk 8y ago
I wouldn't use it as an alternative to garbage collected languages since garbage collection is just simpler overall, I do not disagree, but I think one could argue to the contrary as well. Since most garbage collected languages do not guarantee that objects are actually (timely) garbage collected, you cannot tie the lifetime of other resources (file descriptors, sockets, locks) to object lifetimes. So, the burden is on the programmer to ensure that resources are correctly finalized. Whereas in RAII languages you can properly tie all finalization to object lifetimes. Note: I am not arguing that GC-ed languages cannot do RAII. AFAIR D has a GC and supports RAII.
- olavk 8y ago
  This is true - for example, C# has the `using` block to ensure resources are deterministically released when they go out of scope, not when they at some point later are garbage collected. I would still argue C# is much simpler than Rust since for most object you don't have to worry about this. But I guess there is a certain extra complexity in C# because you actually have to know if a class owns some external resource or not, while this distinction is not necessary in Rust.
  - moomin 8y ago
    In practice that's rarely an issue, because a) if it has a resource it'll implement IDisposable and b) my IDE screams when I don't dispose an IDisposable. This is not as good as the Rust model, but it's not awful, either.

exDM69 8y ago

It's the first "new" language in a long time that is viable for embedded/bare metal/kernel space, high performance and real time applications. The memory safety concepts are novel and unique to Rust but enough has been talked about them already. Additionally, it brings a lot of features from "advanced" programming languages (ML, Haskell) to a more mainstream language. Sum types, pattern matching, powerful macros. None of these are new or unique, but are executed particularly well in Rust. In addition to the new features and concepts, the Rust compiler and ecosystem are well engineered and have a good amount of support. It's the first "new" programming language in a decades worth getting excited about. Ok, maybe I was a bit excited about Julia too, but their execution is not as great as Rust's (and they have made some questionable design decisions).

sevensor 8y ago
There's also the community. I've never seen another language community built with so much deliberate effort, rather than just accreting around a project. And for a language like Rust, I think this is necessary -- with so many unfamiliar concepts and new ways to fail, it would have been very hard to get any traction without a strong community push.
ThenAsNow 8y ago
> Ok, maybe I was a bit excited about Julia too, but their execution is not as great as Rust's (and they have made some questionable design decisions). Could you expound on this? The code I currently write and expect to write in the near-to-mid-term is numerical for engineering purposes. I have the luxury of being able to write greenfield projects, at least for now. My experience with OCaml has inculcated a deep appreciation for powerful type systems and functional styles, so Python, despite its awesome ecosystem, is not particularly of interest. Julia appears to be the natural choice in this space for new development, but I've been a little leery after reading about Dan Luu's experience a couple of years ago: http://danluu.com/julialang/ http://danluu.com/julialang/ I'm interested in reasoned criticisms of Julia as it stands now, and what modern practical alternatives people have found.

coffeeacc 8y ago

Has it appeared more often than eg Go?

deleted 8y ago
[deleted]
swsieber 8y ago
I think go used top appear more often than rust (maybe as often as rust does now), but I think it's started appearing less frequently.

rkangel 8y ago

Because Hacker news has a large population of systems programmers, and we are desperate for something to liberate us from C and C++. We have watched programming languages advance apace in other areas, helping engineers be more productive and produce a higher quality output, but in the systems space nothing has come along that provides enough benefit for a low enough adoption cost for it to be a worthwhile choice over C and C++. Rust shows some promise of being that language, and so we hold out hope and enjoy reading about it.

codetrotter 8y ago

The promises about memory safety was what initially made me interested in it. When it turned out that it was actually possible to learn, it was comfortable to write for someone with Python and C/C++ experience like me, and I saw Cargo and that the ecosystem of packages was quickly growing is when I fell in love with it.

oconnor663 8y ago

Apart from all the other things people are mentioning, I'd add that the development of Rust happens in the open. That means that a lot of very interesting debates are there on GitHub for everyone to read. For example, here's where arielb1 discovered that the original scoped threads design was unsound: https://github.com/rust-lang/rust/issues/24292 https://github.com/rust-lang/rust/issues/24292 (which sparked a large debate about whether mem::forget should be allowed in safe code: https://github.com/rust-lang/rfcs/pull/1066 https://github.com/rust-lang/rfcs/pull/1066).

throwajay79367 8y ago

What I find an even more interesting is that every story about rust have posts whining about hn posts about rust. this is such a boring, ever-present “question” that i don’t actually believe you asked it honestly.

catach 8y ago
Seems to me that Rust's current point on the popularity curve suggests that the vast majority of programmers probably don't know much at all about the lang, or even that it exists. Busy people can note that there's plenty of HN threads about a thing without investigating further. Until they finally do. Better to be charitable, I think. Doing so costs us nothing.

staticassertion 8y ago

To give a somewhat different reason than what I'm seeing, I don't care too much about the 'memory safety plus speed' thing. I'm often building services that would be "fast enough" in Java. Is it nice to be faster? Yes, definitely, and that's part of why I write Rust, but not the whole story by any means. I like rust for a few reasons. * I really like Rust developers - I've met many, talked with many, and we get along and they've helped me through many technical problems, both big and small. * I found rust extremely easy to get started with. I knew I'd have to learn the language, I did not also want to learn build tooling, package management, etc. These barriers exist in many other languages, it's frustrating because I just want to focus on programming. Cargo is excellent and I am a huge fan of how rust manages crates. * I find it very easy to express what I want in rust, to reason about the code, etc. I know when a function might error, I know when I need to handle some unforseen case, I can express how a variable is used, when it is usable, whether it can be mutated. I can cut down on boilerplate with generics and macros. The last point is what keeps me coming back. I find rust extremely easy to write, because it makes the things I care about easy to express.