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 li…
> I think at some point, Rust will have enough tooling that people will try to start using it for graphics and videogames The game developer community is actually one of the communities that jumped onto Rust really early, well before it hit 1.0.
Ask HN: Will Rust ever become a mainstream systems programming language?
81–90 of 291 posts
Re: Ask HN: Will Rust ever become a mainstream systems programming language?
#82With it's borrowing semantics and steep learning curve, Rust will never gain significant market share in the world of web development. And why should it? Time to market matters more than speed. It's much easier to ramp up new hires on a C# or Go code base than on a Rust one. And the borrow checker will always create friction for people new to the language. As someone with a C++ background, it still took me over a month before I stopped fighting with the borrow checker and with lifetimes. I can't imagine how long it would take to get a completely new programmer up to speed.
Re: Ask HN: Will Rust ever become a mainstream systems programming language?
#83Earlier quoted context omitted.
> But the object system (yeah, they're called structures and traits) is too weird. So you praise Go for having structures and interfaces, but you criticize Rust for having structures and interfaces because that's "too weird". > The enum approach to variant records is too weird. Why? Because of the keyword? Swift uses that keyword too! > The error handling is too weird. What would you rather see? > The half-functional…
If Rust doesn't differ from Go, from Swift, from Ruby, from JavaScript in these regards then perhaps, as was pointed earlier, Rust didn't know when to stop. It seems to violate the Law of Parsimony. I like Rust's borrow checker and that's pretty much it. Sometimes I think CRust would be a good idea, the minimal ideas that I like from Rust just layered on top of C as a linter.
The point is that these ideas are not "weird"—they're just decisions taken straight from other languages.
I can't believe we have to defend closures, of all things, from the charge of being "weird" because a language from the 1970s didn't have them, but here we are.
> Sometimes I think CRust would be a good idea, the minimal ideas that I like from Rust just layered on top of C as a linter.
That is not possible. You can't just graft the borrow check from one language onto another language that was not designed for it. For example, C doesn't even have generics, and the lifetime system is designed around generics.
Honestly, I'm tired of responding over and over to the suggestion that we should have done Rust as a static analysis on C++. If you actually try to design such a system, it becomes obvious very quickly that it cannot work for systematic reasons.
Re: Ask HN: Will Rust ever become a mainstream systems programming language?
#84Earlier quoted context omitted.
You have a point. I've done medium-sized C projects in my degree, but my professional background is mostly web. I've been using Rust heavily for 10 months. I think that if you want to use it for web stuff you very much can, but the language is more immature than it might first appear. If the community keeps going the way it is, I hope to work with it commercially by 2020. The most promising things I've read about it…
Why use Rust for web development? There are very few web back ends in the world that need the speed of C++ or Rust. Java, C#, Go, Haskell, OCaml are much easier to ramp people up with and hire for.
Re: Ask HN: Will Rust ever become a mainstream systems programming language?
#85Earlier quoted context omitted.
> But the object system (yeah, they're called structures and traits) is too weird. So you praise Go for having structures and interfaces, but you criticize Rust for having structures and interfaces because that's "too weird". > The enum approach to variant records is too weird. Why? Because of the keyword? Swift uses that keyword too! > The error handling is too weird. What would you rather see? > The half-functional…
>> The error handling is too weird. >What would you rather see? Exceptions
Re: Ask HN: Will Rust ever become a mainstream systems programming language?
#86Earlier quoted context omitted.
> But the object system (yeah, they're called structures and traits) is too weird. It's equivalent to writing C++ with: * No structural inheritance (i.e. no inheritance of data) * Inheritance only from pure virtual interface classes * MyCppPureVirtualClass * pointers in various interfaces Except that traits are also usable for static dispatch as in templates/concepts. This isn't the most common style of C++, but it's…
I can't think of much real originality in Rust. It just brings together "exotic" features from lesser-known languages. I think you're right. Except for the borrow checker, which was a major breakthrough.
Edit: As an aside, I found a Reddit post the other day asserting that the Cyclone developers knew that it would never become mainstream but thought it was important because other languages would adopt it's ideas. It's amazing that they predicted that regions would be picked up later on by Rust.
You can find it here: https://twitter.com/tmccrmck/status/850465514807631872
Re: Ask HN: Will Rust ever become a mainstream systems programming language?
#87I 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. Th…
> 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. This. I've spent some time researching Rust but it's just ugly language for me, really. When I read D everything is so clean, so re…
I think that language will end up looking a lot more like Rust than you think. You can't just compare a language that wasn't designed for zero-cost memory safety to one that was, as if the zero-cost memory safety features have no learning curve.
Re: Ask HN: Will Rust ever become a mainstream systems programming language?
#88Earlier quoted context omitted.
> 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…
I've been doing systems programming in C for 20 years. I disagree with your claim.
Re: Ask HN: Will Rust ever become a mainstream systems programming language?
#89Earlier quoted context omitted.
You're being so rude and inflammatory, for no reason. What's so frustrating is how you're convinced that everyone else is an idiot. > it's incredibly disingenuous to act like it's a major issue I gave you a trove of real world examples of serious security issues in widely used software developed by competent teams. Quite a few of these would have not existed in a language with the kind of guarantees that Rust provide…
> I gave you a trove of real world examples of serious security issues in widely used software developed by competent teams. Quite a few of these would have not existed in a language with the kind of guarantees that Rust provides. How is this disingenuous? Genuine question : do we know that those bugs would have been avoided using rust? Maybe some of those part would have had to be done unsafe mode for some reasons.…
A lot safer, judging by browser exploits.
Re: Ask HN: Will Rust ever become a mainstream systems programming language?
#90Earlier quoted context omitted.
Certainly more then Nim. I'd say, before Rust becomes really mainstream, we have to wait for the current generation of sysdevs to die. But I guess till this is the case, there will be new languages invented that may be better than Rust. On the other hand, most new companies don't hire old devs, so maybe IoT will give rise to new companies and young sysdevs all using Rust before the old generation is gone...
> I'd say, before Rust becomes really mainstream, we have to wait for the current generation of sysdevs to die. Why?
It's like with everything. Most people simply do what they always did, most never reinvent themselves.