I'm (finally) starting to look at Rust and it seems to have hit the nail on the head. Actually I haven't written any code yet (shame on me) but from reading "The Book", it looks wonderful and I had to share :). Solving almost every major pain point I can think of in the programming languages I've used for any reasonable length of time (namely C/C++, Go if we're talking system langugages).
Like resource management for example… No automatic deep copying nor wondering who owns complex members data after a struct copy. Borrowing instead of reference/pointer management. Compile-time data race prevention? Seriously?! Seems to good to be true. I guess it does have some learning curve but if that means being able to worry less about correctness? Worth. every. minute.
Also, those value-containing ENUMs? Together with compiler-enforced complete matches. I can’t count how many times I’ve seen code not matching all possible cases in a switch/if-else…
Needless to say I’m getting really excited to start putting Rust through its paces. Please share your thoughts on this :)
Top comments (21)
The learning curve is also overstated. The compiler completely walks you through it, just don't be stubborn. Sometimes you might have to try a different pattern than you thought of first and that's okay. After a bit it just clicks and feels as natural as anything else.
This is just so not true. The compiler walks through very simple errors. Sure, it points you in a direction, but the compiler's messages are not nearly as helpful with lifetimes and borrowing. So yes, it is indeed very difficult. So is writing safe code.
I disagree, I find the compiler very helpful for these issues. It's clearly shows me why I'm trying to do something I shouldn't be doing, and why it's problematic.
I find people who struggle with it also struggle with thinking about how memory is being used and are trying to use Rust like they use a managed language.
I have tried Rust a bit and I added it to my "To learn" list, between Go and C#.
I have seen some criticism to the compiler being "too loud" complaining about everything. To me, is one of its best features.
It is very hard to write bad code that way.
Exactly, it forces you to not do stupid stuff that can bite back in the future. Also I love how it seperates unsafe memory stuff from safe stuff based on a keyword. You will never do anything unsafe unless you explicitly tell it too.
That's precisely what I prefer. More diligence during development, less time spent debugging obscure errors.
I have a love-hate relationship with strict compiler and I prefer flags that removes the strictness because sometimes I don't want to look at the edge cases and want things to work in most of the case.
Problem is that "sometimes" usually end up turning into "never". You turn off a feature because it becomes an annoyance, and you "just want to test something". Then you get used to it, and if you enable it later on, it will become an annoyance again, which is why you disabled it the first time and it eventually just stays off...
I think turning off strictness project-wide is too big a hammer.
unwrap()is always used in Rust to defer error handling during prototyping, and the wayOptionandResultpreserves the inner type information helps with silly mistakes. OTOH, if the strict compiler doesn't come with good type inference, I know how frustrating writing all the types manually can be. Rust's type inference is on par with OCaml, so you rarely need to declare types on variables. Where Rust struggles is if you use callback functions a lot: the closure types are restricted by the lifetime rules and can be unwieldy.If you ever run into situation where you're needing to design a complex system where the borrow-checker and lifetimes get in the way, check out the slotmap and froggy crates. It's a common pain point for some that are trying to write self-referential and graph data structures.
Slotmap provides generational arenas returning entity keys to data in a slotmap, with secondary maps for storing additional optional components to an entity key. Essentially a simple entity-component system.
Froggy provides a component graph system, where components are stored in arenas, with runtime reference counting to free slots when a pointer ceases to exist.
Additionally, it's a good idea to look into taking those enums and combining them with channels for message-passing between threads. One of the neat things about the generational arena approach is that you can pass entity keys along with the enum to associate requests with an entity.
Thanks for the info, I'll have a look. Indeed, graphs are one of the situations where borrowing wouldn't do so I'm curious how that can be solved.
Your link to froggy is still to slotmap.
Use this: crates.io/crates/froggy
I also have read all the documentation before writing a single line of code... and I avoided forever writing anything when I came to this passage:
Honestly, twenty chapters of documentation telling me that Rust is awesome and avoid common problems, but at the end you cannot do the right thing?
So yes, I loved the language, but no, I won't use it :-(
Interesting. They didn't have to admit that in the book/docs, they could act like it was "by design"/"a feature, not a bug", etc. and just jump straight to the workaround ("solution") they present. I've worked with languages/technologies in the past that do that. To me, the level of sincerity is a big plus.
I'm perfectly aware Rust is still pretty young but from what I've seen so far, I have high hopes for the future and am not going to sign it off just for being honest about its shortcomings.
Not trying to persuade you, or saying you're not right to do that. Just my point of view on this topic.
At that time I was exploring, searching for the good language for a big project for my company. We needed a good choice with high reliability because it would be put in production with customers who pay a lot of money, so the sincerity was appreciated but wasn't an option :-D
Then I guess it's good that you didn't go through with it. If for nothing else, using a new tech without enough experience is usually not a good idea for a "big project" :)
FYI: That specific error has been fixed since 1.41.0.
Because compilers are not perfect, they must trade-off between over-restricting and under-restricting. Rust biases towards the former, so sometimes the compiler rejects something safe. On the flip side, the compiler (almost) always rejects anything unsafe. That's what makes it safer and more stable than many languages. If you know what you are doing, Rust gives you two escape hatches:
unsafeand macro.Rust is pretty much the state-of-the-art of incorporating linear logic into memory and resource management. There are many (so many!) things in theory which we have not implemented in reality. That theoretical perspective makes the design coherent and reveals flaws in implementation as what they are. In my experience, the degree to which the Rust community devotes itself to logical soundness is second only to the academic communities working on Haskell and proof assistants. I'd really recommend you to take a second look if you are after stability, unless you are using the likes of Ada/SPARK.
I found that I had a really hard time learning Rust when I tried to pick it up a little at a time, and it was not until I went "all in" and made myself wrestle with the compiler for quote a while that it started to click. It's pretty magical when you write a piece of code and it just compiles without any issue.
I love Rust, its one of my favorite languages to read about and code in at the moment (that and ReasonML). The books, guides, and documentation are pretty top notch and well written.
Also I just wrote a article about building GraphQL servers with Rust, using Juniper and Diesel over Postgres. Give it a read after I publish tomorrow morning if you're interested :)
Sure, thanks for the tip.