Why Learn Rust?
dublog.net
dublog.net
I found it amusing that the author kind of hinted at the same thing at the end himself. There’s probably a lot of people in that boat. It’s definitely my systems language of choice, but I can’t say I am experienced enough and true systems, languages to have my opinion carry any real weight.
I would suspect that the massive ecosystem built around C++ means that you can get it more done with it faster with less frustration.
Even so, having no experience with either one of those, I would have to go with Rust due to memory safety. It’s good to watch the rest ecosystem grow and adoption increase. It looks like Microsoft is essentially endorsing it as their primary system language if they have the option.
Moreover, you only have to learn Rust once because the language doesn't have nearly the same number of weird limitations and radical overhauls every 3 years. I attend the conferences and write C++ regularly. I still run into issues when reviewing teams where I have to consult the standard because I'm not sure if some weird construct is valid because everyone has their own subset of C++ they're comfortable with. God forbid you have to onboard someone new to the language and explain all the different kinds of initialization, a topic that's utterly trivial in literally any other language.
As an aside, static code analyzers are not able to provide the same kind of guarantees rustc does to arbitrary C++.
Yes, and now the question becomes - is this due to hard limitations of the C++ as a language (in the sense that provision of such guarantees is simply impossible for static code analyzers, no matter what), or is it that static code analyzers just didn't provide so far (but can and most likely will)?
I personally recognize and am thankful for Rust's effort to raise general awareness on the safeness aspect. This (awareness rising) would have been indeed hard to do without forcing this safety to the language core design, although I don't see it working well for Rust in the long run (after people will start having quality alternatives and won't have to pay the "safe by default" price that Rust asks of them).
That inane, insane (prideful?) complex that sucks the time we won't ever get back, forcing us to vintage consoles, obsolete hardware, the oldest books--chasing some Ur-experience where finally, at the end of that journey, on the docks of Middle Earth, we can finally step onto the boat that will take us to the land of the ageless.
For some definition of solemn purity, to work after already-solved problems, in order to understand the beneath: even as things race forward, incessant, and we moor to the mad calm of executing the projects we smash our minds upon.
Recently at my job, we started a new project in Python, which worked fairly well, but the code runs in a somewhat constrained environment. Out of interest, I rewrote the whole project in Rust in about two days, and implemented a big new feature in another day. What I found was that the code ran ~10× as fast, but it was, if anything, even simpler to implement than in Python. Part of that was probably the rewrite effect, and part was definitely the web framework (Warp), but I found I was still mostly writing fairly high-level code. On top of that, when I had to drop down into using more natural synchronisation primitives, it was very easy to (a) do that and (b) wrap that low-level code in a high-level abstraction.
In the end, we decided not to go down this route, mainly because others in the team were less confident about using Rust, but it was, for me at least, a really impressive example of how one can get a lot of the benefits of low level languages with relatively little development cost by using Rust. We probably noticed more of a benefit because of the more constrained environment (although bear in mind, the python alternative had been working just fine for us up until then), but even still, a quicker implementation means less hardware, which means cheaper costs - if you can do that without much effort, that's a pretty good trade-off!
Similarly, none of that code lives today because the team is too small and nobody else knows rust, so we're sticking with python everywhere
When I used Rust, the entire purpose of the project was performance. It was a software-defined networking middlebox that's part of LTE networks. But we were doing FFI with C code. Rust was better for the larger concurrent pieces, but I still liked writing in C better for the fine-grained stuff (packet parsers etc).