Live data from Hacker News

Ask HN: Will Rust ever become a mainstream systems programming language?

news.ycombinator.com

21–30 of 291 posts

Re: Ask HN: Will Rust ever become a mainstream systems programming language?

#21
Rust has to stand the true test of time -- the test where 5-10 years-old codebases written in Rust are still being maintained. Someone who's literate in programming language theory can evaluate the design decisions in Rust and say "it looks good" (or not), but in order to determine whether Rust is actually good for building and maintaining large, complex software systems for long periods of time, there's no metric like really doing it.

I think at some point, Rust will have enough tooling that people will try to start using it for graphics and videogames -- the applications where C and C++ shine but their "safer" rivals Fortran and Ada can be a headache to work with. It's in this arena -- where Go is too slow -- that Rust will really sink or swim. And it has barely even started to make headway. Maybe GNOME 5 will be written in Rust, or maybe the GNOME 5 developers will try Rust and conclude it's not suitable. Whoever they are, they haven't even started yet.

Re: Ask HN: Will Rust ever become a mainstream systems programming language?

#22
post #10
post #7

I think it has a fair chance (Go is a "systems" language and grew very quickly). I also believe you'll see it pop up in unikernels as well. Why, you ask? Because there's always 1 person that starts a project that gets traction. I don't see it growing and replacing C++ though. I don't think there's much incentive post C++11 to really consider porting anything (even small things) over. Most of the features Rust gets pr…

> Ridiculous - if you need segfault protection, you're a bad programmer. Let's be honest, you don't segfault unless you're doing something idiotic. I've caused segfaults in the runtimes of three major languages in the last year by running code that, from a user perspective, is completely fine. I don't think the developers of those runtimes are "bad programmers".

I think the bad programmers are ones who state "segfault protection" as a feature of Rust because they read it on Rust's site. I genuinely don't think these features of Rust are really all that useful (they're being disingenuous; acting like C++ is some primitive language where you segfault every 5 minutes). Even Bjarne would probably agree. He talks about the same issue at his "The Essence of C++" talk. Someone asks if he shares the blame, alongside Ritchie, for all of today's major security issues (Heartbleed is the given example). He says something similar to what I've said. Segfaults are not a major issue at all unless you're consciously doing something idiotic.

Re: Ask HN: Will Rust ever become a mainstream systems programming language?

#23

Not too sure what is meant by "mainstream" but I can see Rust getting a foothold in certain industry, such as medical, automotive or aerospace. To get there, it will need to be mature and be stable significant enough. It will also need a big player to take that first step and prove it in production. Imagine if Ford mandates its suppliers to use Rust for the software in its car and it faced little problems after a few…

I'm an aviation enthusiast and a CS undergrad. I've always wondered what's different about code written for airplanes. Anybody have any insight ? And is there a modern replacement for ADA?

Ada is still under active development and widely used in applications requiring extremely reliable software.

http://www.ada2012.org/

Re: Ask HN: Will Rust ever become a mainstream systems programming language?

#25
post #22
post #10

Earlier quoted context omitted.

> Ridiculous - if you need segfault protection, you're a bad programmer. Let's be honest, you don't segfault unless you're doing something idiotic. I've caused segfaults in the runtimes of three major languages in the last year by running code that, from a user perspective, is completely fine. I don't think the developers of those runtimes are "bad programmers".

I think the bad programmers are ones who state "segfault protection" as a feature of Rust because they read it on Rust's site. I genuinely don't think these features of Rust are really all that useful (they're being disingenuous; acting like C++ is some primitive language where you segfault every 5 minutes). Even Bjarne would probably agree. He talks about the same issue at his "The Essence of C++" talk. Someone asks…

I don't disagree with you in that well-written code should make invalid memory accesses rare. And I don't disagree that, if you write good C++ (and I've stumped around here for C++ because I really didn't learn it until C++11 and have never had an environment where I didn't have the tools to write good C++), they are. But I feel, and pretty strongly, that Rust makes it a lot harder to write bad code in general. Memory protection is just one of the ways this is true.

I replied to you mostly because "you're a bad programmer if you need protection against invalid memory accesses" is rampant nonsense. Everyone needs that protection. It is at best a question of whether you need other things more. (Few people do.)

Re: Ask HN: Will Rust ever become a mainstream systems programming language?

#26
post #9
post #6

Earlier quoted context omitted.

Also anyone big besides mozilla, who created it?

https://www.rust-lang.org/en-US/friends.html

That's 60 companies. Granted there's bound to be a few more but calling it "pretty mainstream" based on that seems like a stretch to me.

Though not a flawless datapoint I'd rather use something like the TIOBE[1] index, which puts Rust at 0,37% rating, or position 41, right below Erlang.

I hope that'll change, I think Rust has some interesting concepts and could be a notable step forward for some things that we've always done in C. But I can't find a datapoint that would make out Rust as being mainstream today.

[1]: https://www.tiobe.com/tiobe-index/

Re: Ask HN: Will Rust ever become a mainstream systems programming language?

#27
I had great hopes for Rust as the future of systems programming, but they've decreased over time. Parts of the language are just too cute.

The borrow checker was brilliant. Any future language that doesn't use garbage collection will have to have one. That was the big advance in Rust.

But the object system (yeah, they're called structures and traits) is too weird. The enum approach to variant records is too weird. The error handling is too weird. The half-functional style is too weird. The widespread use of closures for simple stuff is too weird. There's too much unnecessary originality. Trying to port something from another language to Rust is difficult because Rust's ways of doing things are so different from other languages.

I have the feeling that Rust is destined for a niche like Haskell - cool, but not mainstream. That's sad. I really thought early on that Rust meant the end of the decades of hell from the lack of memory safety in C and C++. But that's not happening.

The Go crowd knew when to stop. The Rust crowd didn't.

Re: Ask HN: Will Rust ever become a mainstream systems programming language?

#28
post #7

I think it has a fair chance (Go is a "systems" language and grew very quickly). I also believe you'll see it pop up in unikernels as well. Why, you ask? Because there's always 1 person that starts a project that gets traction. I don't see it growing and replacing C++ though. I don't think there's much incentive post C++11 to really consider porting anything (even small things) over. Most of the features Rust gets pr…

Even if only "bad programmers" segfault (debatable - especially depending on the type of code you are writing), most of the software written in the world is not made by amazing programmers who never segfault. It doesn't matter your opinion of the developer in question when a buffer overrun happens and your data gets stolen. Encourage people to write code with less safety at your own peril.

Re: Ask HN: Will Rust ever become a mainstream systems programming language?

#29
I work for Faraday (.io, not the car folks), and we use Rust in production. I personally suspect that Rust will continue to grow in popularity.

We've been really happy with Rust. Our Rust programs tend to be fast and resource efficient, and they tend to have few bugs (and most of those are cases of misunderstanding the problem or the spec).

The learning curve tends to be pretty rough for the first week or two, but you can reduce that by pairing with a more experienced Rust developer. And after that, it's pretty smooth sailing. Certainly any C++ programmer should be able to make the leap fairly quickly--it helps to have used at least one non-GCed language.

The third party library situation is better than you might think for a young language (the database clients, RabbitMQ clients, HTTP clients, compression, etc., are all basically usable), but I normally expect to fill one or two library gaps per project.

Overall, I find it difficult to articulate why I like Rust. It's pleasant to write (now that I know how), it runs fast, the CLI tools are pretty solid, and has enough abstractions to keep the boilerplate in check. And I can throw cluster-sized workloads at it and trust it to work, and work fast.

Re: Ask HN: Will Rust ever become a mainstream systems programming language?

#30
post #7

I think it has a fair chance (Go is a "systems" language and grew very quickly). I also believe you'll see it pop up in unikernels as well. Why, you ask? Because there's always 1 person that starts a project that gets traction. I don't see it growing and replacing C++ though. I don't think there's much incentive post C++11 to really consider porting anything (even small things) over. Most of the features Rust gets pr…

> if you need segfault protection, you're a bad programmer. Let's be honest, you don't segfault unless you're doing something idiotic. I've not segfaulted in the past 8 years in anything but assembly sigh Please look at the "trophy case" here: http://lcamtuf.coredump.cx/afl/

My views are the responses you'll probably get from the people who've been doing systems programming in C for the past 20 years. I don't doubt lots of common applications have memory issues. Maybe not a definite segfault but it's incredibly disingenuous to act like it's a major issue (as if writing C and C++ are similar to disarming a bomb or something). It's nonsense and the same reason I have been learning C++17's stuff rather than bothering with Rust.

I want a better argument for: 1) A C++ developer who's been writing C++ for a long time and is skilled in modern C++ who is wondering why he'd pick up Rust for user application development? I await more superfluous bindings like "Rust-Qt". 2) Porting C/C++ to Rust code (with a rather large codebase).

Every argument I've seen for Rust is: out of context, disingenuous when they compare it to other languages, or just incredibly biased. I don't think it's ironic that the majority of people I've met who have started doing Rust are bad at C and C++ and have bought into the list of features on Rust's homepage without any knowledge of anything related to them.

Post reply on HN