Live data from Hacker News

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

news.ycombinator.com

41–50 of 291 posts

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

#41
post #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. Th…

This is like reading criticism of Erlang which we use. A bunch of people (the vast majority of which never shipped anything in it) have plenty of arguments against it, those of us that actually use it love it to bits.

Rust is productive, efficient and a joy to use. For things we required C/C++ before, we will be using Rust now.

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

#42
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…

>"I don't think there's much incentive post C++11 to really consider porting anything (even small things) over" I am curious why specifically C++ 11? Could you elaborate?

Let's look at Rust's homepage: - Zero-cost abstractions - C++, in my opinion, is the founding father of zero-cost abstractions. - Move semantics - we've had this since C++11. - Threads without data races - C++11 introduced a threading library as part of the language. We can avoid a lot of data races, deadlocks, etc. if you actually look deeper into how to implement the modern threading library well. - Efficient C bindings - this had to be listed because we all know the world relies too much on C at the moment for this not to be a feature. C++ is almost a perfect superset of C, fantastic.

Modern C++ has made great strides in the direction of making writing good code a lot simpler. I don't think you're gonna convince C++ (and C developers, of course) programmers who've been doing systems programming for a long time to stop everything and jump to Rust. It's just not viable.

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

#43
post #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 yo…

Trying to articulate why I like it: it marries the low-level control and type safety from C++ to modern language features as found in Python/Ruby etc, and in doing so manages to hit a pretty sweet spot in terms of having the compiler finding actual bugs early. With enums and pattern matching and the borrow checker, there are a bunch of features that help make the type system expressive enough that you can generally express what you need and still allow the compiler to perform very thorough, important checking on it, with the effect that "it compiles -> it works" is true much more than for, for example, C++.

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

#44
post #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. Th…

> 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 not uncommon either, and I happen to like it a lot; it's all over Cef's and Chromium's code, for example.

> The enum approach to variant records is too weird.

What's weird about it? It's just the same as e.g. Haskell, ML, but with a different (arguably slightly overloaded) keyword. Swift uses the same terminology.

> The error handling is too weird.

Eh. I certainly like the way that explicit error handling is "forced" on the caller with mechanisms like Result::unwrap. But I agree that magical things like the question mark operator are a little too cute.

> There's too much unnecessary originality.

FWIW, I can't think of much real originality in Rust. It just brings together "exotic" features from lesser-known languages.

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

#45
post #16
post #12

I would say unlikely, for the simple reason that Rust is just really hard .

C++ is hard, too. So is C, to write correctly. Hasn't stopped either of them from literally powering almost every computer in use. Rust's complexity is equivalent to, but distinct from C++'s. I prefer it over C++, and I'm one big fan of the latter.

I think C++ is much harder actually. Making sure that the system doesn't crash means writing a lot more unit tests than what would be needed, and sometimes these problems come out in production only. I would love to switch to Rust, but it takes many years in a big company.

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

#46
post #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. Th…

I don't know why you're calling all of that stuff "weird". I have to assume it's simply because you were never exposed to another language that had stuff like it. But you're definitely wrong about that keeping Rust from going mainstream - just look at Swift, which has a very similar trait system (called protocols), enum variants with associated values, an arguably weirder error system, widespread closures, and half-functional style. And I'd say Swift is already fairly mainstream.

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

#47

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 big into Rust, but I doubt that anyone in security-critical industries is going to put themselves on the line by using a language that's neither standardized nor government-approved. Nobody ever got fired for buying IBM, and nobody ever got fired for picking MISRA C.

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

#48
post #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. Th…

> 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 style is too weird.

I can't think of any way that Rust differs in this regard from, say, Ruby. Or JavaScript.

> The widespread use of closures for simple stuff is too weird.

Again, it doesn't differ from Ruby. (Actually, Rust uses closures/blocks quite a bit less than Ruby does, because of the pull-style iterators...)

> There's too much unnecessary originality.

Such as? None of the features you've mentioned are at all original.

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

#49
post #36

It does keep rising in popularity, but is that coming from folks actually using system languages like C, C++, Ada, and Forth? I'm guessing only a portion. There's a difference between a web developer using Rust enthusiastically for hobby projects and a seasoned C coder switching to Rust for a professional job. In fact, a lot of the projects I've seen in Rust (ex: Dropbox) are commonly being done in Go as long as the…

Rust is the first language since C++ that can improve/not hinder runtime speed while making development safer, so I definately see its future. The only problem is that the compiler is very slow now, so it doesn't scale to large code bases, which is a no-go in my company. Hopefully the Rust team understands that this is not only a would-be-nice to have feature (I see learning the borrow checker as a smaller problem)

> The only problem is that the compiler is very slow now, so it doesn't scale to large code bases

The way of working with that is use cargo check command which is much faster and splitting your problem into multiple crates so you don't have everything in one giant project. Which is what tends to happen in large code bases anyway.

Also they are putting quite a lot of work into making it faster. Before you get to that large code base it will be better.

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

#50
post #47

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 big into Rust, but I doubt that anyone in security-critical industries is going to put themselves on the line by using a language that's neither standardized nor government-approved. Nobody ever got fired for buying IBM, and nobody ever got fired for picking MISRA C.

Totally agree with you. Rust is just a baby growing up. C is a middle aged guy with tons of experience. Rust just needs to catch up.
Post reply on HN