Re:Ask HN: Will Rust ever become a mainstream systems progra...
by kixunil on Tuesday April 11, 2017 @09:53AM
(#14087730)
> It doesn't use segmented stacks so it doesn't achieve the M:N performance of Go
Actually, if you use Tokio or similar approach, you achieve better performance than Go (no need to re-allocate stacks) while code is still quite readable and boilerplate-free.
Re:Ask HN: Will Rust ever become a mainstream systems progra...
by Rusky on Tuesday April 11, 2017 @10:09AM
(#14087875)
They seem to be aware: ", but it has memory and data race safety, OS threads, and futures, so no problem."
However, futures are certainly not boilerplate-free. They destroy your ability to use native control flow the way you can with threads (M:N or 1:1). You can get some of that back with async/await, but Rust doesn't have that and it's still not boilerplate-free.
Re:Ask HN: Will Rust ever become a mainstream systems progra...
by camgunz on Tuesday April 11, 2017 @11:26AM
(#14088801)
Yeah Tokio is the answer and what I'm referring to. All I meant was if you implement M:N in Rust it'll be slower than Go. I think this is probably the right answer, as segmented stacks cost you C interoperability, but it's not right for everything.
I'm not shy about my dislike of Rust. I like C, I don't think avoiding buffer overflows and memory errors is that hard, and I chafe at the idea of a language I dislike aesthetically taking over systems programming.
But even I have to admit the arguments for using C instead of Rust are niche. Sure there's probably always going to be some instance where C makes sense technically, but if we could wave a wand and convert the world's C/C++ code to Rust, we'd immediately fix millions of memory errors and data races. It's impossible to overstate that benefit.
Think of the things the Rust team has to deal with:
"Is Rust a good web language?"
Is C or C++? Is Ocaml?
"Is Rust a good language for an OS?"
Is Python? Is JavaScript?
"Is Rust too big?"
Is C# or Java? Rust is a pretty small language, both in terms of features and implementation size.
"Is Rust powerful enough?"
Is Go? Go deals with this all the time ("Go ignores decades of PL research"). Rust's feature set is pretty good, but more importantly it's well thought out.
"Is Rust fast enough?"
Is Java? Is C#? Is Go?
"Does Rust compile fast enough?"
Does C++? Does Clojure?
"Will your Rust program be memory safe and free of data races?"
It sure will be. This is a monumental achievement. Your options for a memory-safe language without GC are... Rust and Ada?
"Does Rust have a good concurrency/parallelism story?"
Rust has one of the best, actually. It doesn't use segmented stacks so it doesn't achieve the M:N performance of Go, but it has memory and data race safety, OS threads, and futures, so no problem.
"Is Rust too hard?"
Honestly, programming is hard, other languages just let you ignore it. There's an example about manipulating a string as a global array in this thread somewhere, which is not really something you should do, and the argument was "this was wildly difficult". It is, yeah, because safely managing concurrent access to a global, bounded section of memory is wildly difficult.
Again, I'm not a Rust fan and I sort of can't believe I'm writing this. But look at what Rust has:
- memory and data race safety
- scripting language ergonomics (after you internalize the borrow checker)
- the speed and memory usage of C
- a low surface area
- advanced features
- great community outreach and documentation
- familiar structure (as opposed to something like Erlang or Haskell)
If a language like that doesn't succeed, you have to start wondering what will.
My personal belief is that it is succeeding, but I think success looks a lot different than most expect: new projects that need a systems language are far more likely to be written in Rust than in C/C++.