Programming is hard. Programming will always be hard. Better/newer tools (and sometimes influences from the old finally making it mainstream, like Standard ML) make programming easier but not fool proof. It's misleading and harmful to hype the crap out of any language.
Unfortunately this stupidity is never going to end as long as language creators measure language success in adoption numbers and TIOBE scores rather than the warm fuzzy feeling of handling certain people's needs really, really well.
I am somewhat disappointed that we still feel the need to create entirely new toolchains and rewrite everything just to support what should be an incremental improvement. But at a certain point, a lot of the reason for the hype is that it sells these solutions to newer developers that haven't had exposure to these concepts before. I suppose we can consider them fortunate for not having to do systems programming while suffering through implementing their own reference counting and garbage collection semantics.
Those, plus the total package of tradeoffs in Golang did for me, in terms of implementing a game server. The whole package really is game changing for what I'm doing.
I am somewhat disappointed that we still feel the need to create entirely new toolchains and rewrite everything just to support what should be an incremental improvement.
There's something wrong with programming as an entire field. Don't other fields figure out ways of not reinventing the wheel?
But at a certain point, a lot of the reason for the hype is that it sells these solutions to newer developers that haven't had exposure to these concepts before.
Luminaries of our field have been lamenting for decades that programming forgets its own history and discoveries. Maybe we should make it de rigeur that people relate their "inventions" with past art? A lot of times, when I point out past art, I get met with instant open hostility from younger devs. Is it any wonder that programming has the attributes of a popular medium, not a field of engineering study?
If young coders want to be the future intelligentsia and harbingers of a better kind of programming, they need to foster a set of subcultural norms that best leverages collective knowledge. Programming has to become a field that remembers its own history and can learn from its mistakes.
I've been doing C/C++ for close to 15 years now, I find that the borrow-checker not only helps with safety but also with guiding a good architectural foundation. Nothing keeps you from dropping into an unsafe block and cranking out very c-like code if you want as well.
All my green-field code now is Rust. Sure there's some hype but that's because people are genuinely excited about the language.
I agree that "salvation" is a bit much, though.
For whatever hype Go had and may have, it's still a resoundingly successful language that's building meaningful stuff that improves people's lives. Sounds like a success to me.
I don't personally divide my life into "before move semantics" and "after move semantics" - but thanks to move semantics, I have to anyway. And I feel like I'm all the better for it.
Any ideas about how to add this small "incremental improvement" of Rust-like safety to C, for example?
I don't think that the language creators are behind this in this instance, more over-excited users continuing the hype cycle. I definitely agree that it does a disservice to the language. I posted this on /r/rust[0]:
> Please don't push the hype train to far - our language, tooling and strong community does a lot of work to sell itself, and we will get a backlash if we are not up-front honest about Rust's problems. Ruby and Go are experiencing that now. Some languages are better than others especially in specific domains, but even the better ones are not silver bullets, and Rust is no different. I use Rust for some things because I feel the trade-offs are worth it.
Not all of us feel the need to sugar coat Rust.
[0]: https://www.reddit.com/r/rust/comments/5kytg5/rust_is_softwa...
I think the main hype danger for rust right now is that the number of killer applications written it will fall short of the hype. But the linked article is from someone writing redox-os, so it's hard to criticize this article specifically for contributing to overhype.
Ruby had the opposite problem, which is that a lot of people were writing amazing applications, but it fell down technically (applications got messier and slower; or at least that is the perception). In theory the same thing could happen to rust, but it seems less likely.
Having said this, Go got its killer application in the form of the main language driving container implementations.
Rust might eventually get its one beyond the current browser implementation and get adopted by an OS vendor.
Just with Apple doing Swift, Microsoft .NET Native and C++/GSL, maybe it is left for Google and their Fuchsia project or an embedded OS vendor to do it.
It's a vast oversimplification of the real issues while ignoring the reasons programming or are hard.
Of course it's possible. Say you would fork gcc (or clang) and teach it a few extensions for the C type system that allow some more safety checks at compile time (for example something similar to Rusts borrow checker). Since those checks don't change the generated code, you now have a language that's safer than C, but equally fast. Now you add some language primitives that make it easier for the compiler to understand the intend of the programmer, making it easier to optimize the code (there are already plenty of opportunities used by C extensions, like signaling that some if branch is unlikely to be taken. More opportunities exist if you modify the language more heavily). Now you have a language that's both safer and faster than C.
I don't want to make any claims about Rust performance in practice, I haven't run enough benchmarks for that. But it's perfectly possible that the statement could be true.
Maybe not faster than C but at least as fast while bringing modern patterns and better safety.
It's actually entirely possible. For example it's how Fortran has been traditionally faster than C, by not allowing for aliasing (which is also an unsafe feature) it can give the compiler more room from optimization.
That's C's limitation: it can only be as fast as the compiler geniuses can make it, or as concurrent as its users can explicitly make it. Given that almost all computers where you care about raw performance are multiprocessing now, that's a huge deal. Languages with primitives like async/parallel map() are going to have a hard time keeping up with those that do.
Sure, you can write ultra fast code in C or assembly. The fastest way to do so might be to write it first in Erlang, Go, or Rust and reverse engineer it from the resulting machine language.
Rust's safety guarantees dont extend to logic or protocol implementation problems or misconfigured security settings.the part of the article about service providers leaking creds or other info...Rust all the things and that will still happen.
Some of this stuff is just too much. Also, why not work on lifetime and memory safety in a c based language? Rust looks like Klingon to me. functional-ish-ness is really hot right now. (Like Hansel.)
There's this really sophomoric theme that this seems to be a part of that keeps resurfacing here. its almost like a conspiracy of influences made the wrong tech choice in the past and everything would be ok now if we used X. Where X could be haskell, rust, os2, plan 9, lisp, lisp, lisp, go...theres quite a few saviors out there they resurface every now and again.
https://hoverbear.org/2016/10/12/rust-state-machine-pattern/
https://blog.tarn-vedra.de/posts/phantom-types-for-safe-apis...
https://insanitybit.github.io/2016/05/30/beyond-memory-safet...
https://scribbles.pascalhertleif.de/elegant-apis-in-rust.htm...
Some libraries use such features to prevent certain kinds of nonce-reuse during encryption (one of the more common ways of screwing up encryption). These constraints are checked at compile-time.
Such guarantees are not possible with weaker type systems like that of C.
I'm a huge strong typing fan! I'm just saying, type systems can get you a long way toward correct construction. (Or correctness by construction...) The issues with the software/computing world are bigger than array bounds checking and type correctness.
It's worse than the phase Java went through when it hit its peak.
I'll be honest. Until we start seeing some more balanced (frankly, I'd settle for nuanced) discussion about the compromises made to get Rust's strengths, I'm staying the hell away from it.
As a person who lived through the 1990s Java hype and had a bookshelf full of the official Java books (Addison-Wesley white books)[1], the Rust evangelism is nowhere near that level.
To refresh the memory, 1990s Java evangelists predicted:
1) C/C++ would become obsolete because in the age of abundant desktop resources (cpu power and more RAM), the GC would take care of all that
2) Java's "write-once-run-anywhere" JVM would render the Windows operating system obsolete and weaken the evil Microsoft
3) Java applets so you could create rich dynamic websites in the browser
As we now know, none of that actually happened. Java is still a success but it couldn't match the breathless press it initially received.
Yes, this particular Rust blog promising "salvation" seems to defy Fred Brook's more conservative "no silver bullet".[2] But relatively speaking, Rust's enthusiastic community is fairly tame.
For example, the internal wars between Windows and DevTools divisions at MSFT, were the biggest reason for Longhorn's failure.
MSR with Midori has proven the viability of using C# for systems programming, when no politics are in play and everyone is focused on technical improvements.
> Until we start seeing some more balanced (frankly, I'd settle for nuanced) discussion about the compromises made to get Rust's strengths, I'm staying the hell away from it.
If all you see about Rust is what hits Hacker News, you're probably not going to see much of that. The narrative about Rust's safety and the terrible state of software engineering today and dangers of all of the existing C and C++ code is a strong one that resonates with a lot of people, and so posts about that are likely to be voted up on HN. Posts about how Rust isn't a perfect language and has some flaws, well, maybe not so interesting, because every language has flaws, so there's nothing all that noteworthy there.
Also, FWIW, the post you're commenting on is written by someone who believes what they're saying in the post so strongly that they're writing an entire unix-like OS, including kernel and applications, in Rust. So it's no surprise that they're talking about what excites them about Rust and why they're using it to write a whole OS, rather than any flaws it might have.
Err, the title of this article is "Rust is Software's Salvation". The previous one was "Rust is mostly safety". No discussion of trade offs, no negatives to be found. From the original article: "[Rust is] Technology from the past come to save the future from itself"
> Not sure why marketing Rust implies that the community is trying to defend it
The original article was a call for marketing material, because they don't feel enough people are using it. Those people are, to paraphrase the sentiment from the comments in the first article, wrong for thinking they write safe C or C++ code.
Look into the issues surrounding the borrow checker, that's one of Rust's main pain points. Long compilation times are another common issue.
To Rust fans, I realise both of those issues will be addressed to some degree as MIR matures, but I'm looking for flaws as things stand now.
- It will be super hard to hire for Rust for a long time. It would be a very bold move to write your app in Rust if you plan to grow your tech team anytime soon.
- I havn't tried learning Rust myself, but I have read that little that it can be a little tricky to start thinking the rust way (borrowing?) Plus the language "looks" hardcore. I wonder if that will put off new devs.
It's a combination of two things, as far as I know.
1. The LLVM backend is slow.
2. The Rust frontend has historically abused the LLVM backend badly, by feeding it large amounts of barely optimized code. This is being worked on, but it's going to take a while.
What you aim for and what you achieve are different things. These things take time. We've been getting faster every release. 10x faster within a single six-week period is not realistic.
(Borrow checking is not generally the slowest part; it's the codegen. Which is LLVM. But also is the IR we feed to LLVM.)
Every time a new release happens, it takes around one hour to update all VSCode related tooling.
To an outside observer (me), seems like Rust evangelicism tries to cast a too wide net, ending in "meh" response from many.
That's a bold, yet generalized statement.
It performs on par with C++, on the other hand, for what that's worth.
Many of the others boil down to "explicit SIMD isn't in stable yet."
http://www.anthropic-principle.com/?q=anthropic_principle/do...
I don't hate C, like some here, but I am receptive to the many objections to it: it makes a lot of sense.
But I would be a lot more receptive to this particular attack on C (which is pretty reasonable) if it wasn't so melodramatic: claiming that Rust will "save software" and that C is some kind of garbage with no advantages of any sort. Both are false (although the latter has some truth to it: C has many issues).
The truth is strongly in your favour: No need to stretch it.
A hilariously wrong/misleading analogy in an otherwise compelling and agreeable blog post.
There could be though. Maybe the successor language to both Rust v4.4 and C++26 will be named Silver Bullet. You never know.
I like Rust. I just don't think doing things in a better C than C is going to yield as much of a payoff as these guys think it will.
I was able to replace pages of "cleverness" with a few lines of code in the same language.
These guys are very impressed with their improved hammer. It might not be the best tool for the job.
I don't write new languages any more, I figured this out 20 years ago, it's something that is very very hard to suceed at, and rather a crap shoot.
The same goes for OSs.
Oh, and BTW, functional languages, the very best thing since sliced bread, for, what? the third time around now?
That's... not saying all that much.
> Better performance than C
In 2014? Objection, your honor. Assumes facts not in evidence.
About problems with C:
> Maybe a bug in GCC outputted the wrong machine code
And Rust compilers will never have bugs?
> Maybe a race condition in Linux gave an unprivileged process the ability to tamper with your program
And writing your program in Rust is going to save you? Nope.
Now, in the previous two points, the claim may be that GCC/Linux is written in C, rather than that my program is written in C. But a compiler written in Rust can still output the wrong machine code, and the borrow checker won't save you.
> [ ... ]
> Maybe a bug in GCC outputted [sic] the wrong machine code
How does Rust protect against a bug in Rust outputting the wrong machine code?
> Maybe a race condition in Linux gave an unprivileged process the ability to tamper with your program
Too bad the race-condition free Rust OS that can replace Linux isn't here yet.
