Happy birthday (or rather, stabilization day) to Rust!
I really enjoy programming in it, and I sincerely hope I'll manage to use it at work soon. Some years ago, I managed to write one component of a data processing pipeline with it, and it worked well, but the whole project ended up being scrapped because of unrelated reasons. Using Rust was possible because the project was really small, so I had a lot of freedom in choosing the technologies, but at the time the ecosystem and the human part of the equation wouldn't have scaled.
I think the time is significantly more ripe now. The biggest hurdles are no longer in the language itself or the tooling or lately even because of ecosystem limitations, but rather, inertia and concerns about whether there are enough people who know it, and even that is improving rapidly.
I got into using Rust fairly recently (after using Go and Python almost exclusively for the past few years) and I just want to say that this is the first time in a while that I've really enjoyed programming.
Python and Go are also the main languages I've been using for the last decade. Noticing all the hype around Rust recently is prompting me to learn a new language. The last time I learnt a language from scratch was Go around 2010.
Go was fascinating to learn, precisely because it looked like C, but it wasn't. Another aspect that makes me love Go is its minimalism and concurrency features.
I also used to enjoy C++ and Java quite a lot for larger projects, so tell me, can I expect Rust to somehow remind me a bit of Go in comparison to C++ and Java? In other words, a simpler, more concise and more enjoyable to use version of C++ for instance?
> can I expect Rust to somehow remind me a bit of Go in comparison to C++ and Java?
Nope. Go and Java are about on the same "complexity plane" (Java is there 20 years later and having made different choices obviously, but the original java was not so different).
Rust is a much more complex language, in large part due to its purpose. It's often compared / conflated with Go because they arose around the same time, because the initial versions of Rust were much closer to applications languages (and Go e.g. runtime, green threads, segmented non-C stacks, …), and because Go's designers misleadingly called Go it a systems language.
Rust is more like taking OCaml, or Haskell, painting it in a C/C++ livery, and making it suitable as an actual replacement for C with all that implies.
I'd certainly agree that the initial learning curve of Rust can be substantial, wrapping your head around things like the borrow checker. It was for me.
But I'd never put it in the same tier as a completely different programming model like functional programming. It's still fundamentally a procedural language. Coming from C, I found Rust simpler than idiomatic modern C++, for instance.
> Nope. Go and Java are about on the same "complexity plane" (Java is there 20 years later and having made different choices obviously, but the original java was not so different).
That's actually a very good point. I think a lot of people forgot about it (I did).
Java started very simple and then it just got enterprisy frameworks and best practices. I'm wondering how Go will look in 20 years.
> Go's designers misleadingly called Go it a systems language.
I think one definition of what a systems language is one that you would use to write operating systems. I'd also call K8ts an distributed operating system and Hashicorp tools as components of one. Doesn't seem a huge stretch to call Go a modern systems language.
As someone who recently learned Go as well as Rust, I would definitely say they are very different (but both great!)
Go is way more minimalist and easy to quickly get some code going.
Rust has a lot more moving parts when writing, so it takes more thought to write, but it’s great for large projects because it’s fast and its features make it scalable (with a lot less worry about bugs).
From personal experience learning the language - despite its syntax, Rust inherits a lot of its concepts from OCaml and Haskell rather than C++ and Java. If you program stuff in Rust the same way that you would program it in C++, you're going to find yourself constantly fighting the borrow checker and having a rough time of it.
I came from Go and found it to be reasonably straightforward to learn Rust. I'm definitely not a Rust expert but I found it to be fairly similar. Structs and no classes, defining methods on structs, lots of the stdlib (like IO) uses reader and writer interfaces, etc.
I'd argue that it still can be used for low-level programming (ie bare metal Arduino stuff) so it's more like C. One thing I hate about C was the memory management, and I had segfaults all over the place (but that may be more due to my pathetic C skills than anything else imo).
When I said "It's like C, but not C" I meant that it can be used for the same applications as C but it doesn't have most of the shortcomings of C itself.
Does the article you linked necessarily contradicts Drew points (C's portability, spec, implementations, stable ABI, and safety isn't always needed)? Yes, Rust may be a better choice for some (many) use cases but you cannot say it's "like C" or "better C". Like how you wouldn't (I guess) refer to Go as like or better Python although many Go devs are former Pythonistas.
Maybe this exact one doesn’t say exactly against that specific article. It’s not a direct response to it, so it wouldn’t.
But the line some people espouse is “Rust is a new C++ not a new C and C programmers who don’t like C++ would never like Rust,” and while some folks do feel that way, it isn’t universal. That’s all I’m saying.
C programmers are numerous and in a variety of fields doing all sorts of things, pretending you can speak about this stuff as though there’s a monolith of opinion is a category error, in my opinion.
>“Rust is a new C++ not a new C and C programmers who don’t like C++ would never like Rust,” and while some folks do feel that way, it isn’t universal.
While I am big fan of C, I didn't meant it to mean that comparing Rust to C++ as an insult. I was thinking more as Rust isn't bare bone like C and has high level language constructs.
More adoption for low-level, embedded, and safety critical domains will help Rust to mature in these domains and provide competition and new developments where there is too much complacency and stagnation.
Happy birthday Rust! It's crazy to think personally that it's been 6 years since I stumbled on this little esoteric language on hacker news and decided it might be fun to learn. Ended up changing the trajectory of my career in a big way. I owe a lot to Rust!
I'm curious if anyone has experience maintaining (not writing from scratch) pre-existing systems in Rust - now that it's 6 years old (!), what's it like to interact with in contexts where you aren't building from the ground up?
I am maintaining part of a popular Rust crate. Working on existing Rust code and modifying it is a pleasure. It's a lot of fun and I wouldn't trade it back for C++ in a million years.
How stable Rust is? That is does, and how often if it does, your crate break or becomes (idiomatically) outdated when a new Rust version is released? Can I for example compile with the latest Rust compiler 1,2,..6 year old code?
Your code will always compile with newer versions of the compiler. It will never break when you upgrade your compiler. (Modulo bugs that are rare and fixed quickly). The 6-year old Rust 1.0 stability guarantee still holds.
> Can I for example compile with the latest Rust compiler 1,2,..6 year old code?
Yes.
There have been some backward incompatible changes, but those are opt-in. So it wouldn't affect you.
You usually have a Minimum Supported Rust Version (MSRV). Depending on crate this has to be set higher or lower. Of course you try to support old Rust compilers as long as possible, but you will bump it up once in a while. Rust has become fairly stable now, especially since it's past the 1.0 release so stuff largely remains backwards compatible. You usually see MSRV requiring a compiler younger than 1-2 years, that's what I'm used to seeing.
One of these — global shared mutable state - is almost always horrible bad practice and leads to unwieldy code that is hard to test or compose with other code. It’s also a major culprit in bugs that arise when shared objects are used in multithreaded programs. I practice the rule that shared variables are always const and use e.g. const_cast if they need to be lazily initialized. I also make sure to make any lazy initialization thread safe.
There are very few cases when a global mutable is good. Usually these arise in things like embedded or kernel code that by definition is only run as a single instance or if you need something like a global random number generator or global singleton access to something by definition unique.
Even in the latter cases it makes me itch a little.
I really enjoy programming in it, and I sincerely hope I'll manage to use it at work soon. Some years ago, I managed to write one component of a data processing pipeline with it, and it worked well, but the whole project ended up being scrapped because of unrelated reasons. Using Rust was possible because the project was really small, so I had a lot of freedom in choosing the technologies, but at the time the ecosystem and the human part of the equation wouldn't have scaled.
I think the time is significantly more ripe now. The biggest hurdles are no longer in the language itself or the tooling or lately even because of ecosystem limitations, but rather, inertia and concerns about whether there are enough people who know it, and even that is improving rapidly.