How not to learn Rust (Hints how to make the start easier)
Posted by Alexander_Selkirk@reddit | programming | View on Reddit | 20 comments
Posted by Alexander_Selkirk@reddit | programming | View on Reddit | 20 comments
Illustrious-Map8639@reddit
No, it's potentially harmful to make every field in your struct pub as a reflex. Enum's are not the idiomatic way to enforce invariants, they are an idiomatic way to enforce a sum type. The notable exceptions given don't even scratch the surface of invariants you might want to protect: strings that can always be parsed to numbers, sorted vecs, multiple vecs with equal length or coupled lengths, and so forth. If you are a person that sees and enforces invariants, you will be doing it a lot instead of constantly double checking things.
If you have some related data with some invariant you will want to rely upon safely later, you encapsulate that in a struct with a particular way to create the struct. Or you make a closure over the data after verifying it and start calling code with that closure, but this is just OOP vs FP strategies and you should use them both, the closure with anti-aliasing rules will be stronger than access control. You might not have real getters (or you might), since the struct's representation might be different from how you work with the data. If the fields are public the owner can mutate them at will and your impl cannot safely rely upon those invariants.
Moreover, if you give pub access to every field in your struct, you couple external code to that precise representation. Changing the struct becomes a major version change, even adding a field is not reverse compatible. Even the lesser pub(crate) can cause internal refactoring problems especially if you want to initialize the new field with a default value. Pub structs need to be considered carefully from a versioning stand point.
The one language I am familiar with where these considerations are really overruled is python because the fields are public anyways and you just _ name them to indicate that using them directly voids the warranty, and if you later decide you don't like the internal structure you can use
@propertyto avoid the semantic major version bump.Pharisaeus@reddit
Mistake 3 is golden. I've seen people trying to start learning Rust by writing a linked list and it turned into descent into madness very quickly.
Yumpai@reddit
That's a good sign when your language has such restrictions.
yojimbo_beta@reddit
Is Rust too hard? I ask this as somebody on board with a strong memory model, sum types, non nullables, and zero cost abstractions.
I can see there are domains where this cost is worth paying but does it confine Rust to a niche? It's not a rhetorical question, I'd like to be convinced I'm wrong
TwoIsAClue@reddit
As a system language, Rust is niche in the same way C/++ is niche; the cost of using C/++ outside of that niche is arguably greater than Rust's, but it's paid in crashes and security concerns rather than in fighting with the compiler.
juhotuho10@reddit
Rust is not too hard, the compiler is great errors are great for teaching you what you did wrong and what to change in the code.
Though Rust can get pretty hard if you come to Rust from another language any try to force Rust to be like other languages. It's pretty easy tie yourself into many lifetime knots by doing things like needlesly returning references from functions, trying to have references to everything, everywhere (C programmers sometimes try to do this) or having your program architecture looking more like a graph instead of tree.
renatoathaydes@reddit
All systems languages are kind of niche: you see people using them for really low level stuff (drivers, embedded, operating systems, some categories of gaming, industrial automation, coreutils and adjacent terminal apps). You don't see people using them very often for web development, business applications, scripting which is probably 90% of all software. So all the stuff that makes up that 10% is kind of niche.
But Rust, while being as hardcore as any systems programming language in the sense of being able to do anything at all without a runtime with extremely high performance, can also claim to provide enough high level constructs (incredibly, almost always at zero cost), stuff like traits, sum types and lambdas, not to mention memory safety so you don't need to be a infallible genius to never use-after-free or access memory that's out-of-bounds, that it COULD BE used for other things too.
I do think that even though that's possible, it's not really desirable, at least to me, because the mental overhead Rust imposes is still high when compared to your favourite high level language which you can just write without thinking or ever knowing that questions like "who owns this memory, does it go in the stack or heap" exist.
Full-Spectral@reddit
Well, it's primarily a systems language, so it's not designed to make easy stuff easy, it's designed to make really hard stuff as manageable as is reasonable. And, as a GOOD systems language, it's not about writing stuff fast, it's about the long term commitment to a product and keeping it stable, secure, and robust over years and massively changing requirements.
C++ is 'easier' only because it doesn't actually make you do the right thing, and you can have a code base full of spooky action at a distance and relationships that depend completely on humans remembering to honor them and lots of potential ownership issues particularly around threading that you may never actually find.
Anyhoo, all that means that it's not the kind of thing that you'd use to whip together a CRUD application quickly or tend to use in the browser (though as a target for WASM it's applicable.) Or the kind of thing that non-programmers will likely use as a scripting language to invoke canned libraries. It's more the kind of thing that the back end sits on top of and that the browser is written in, and the many subsystems that in turn underly those things.
Of course, C++ and it's OOP concepts was a mystery and challenge to a lot of people when it came out, but now those ideas are just baseline concepts, and in fact now considered old fashioned to the point of rejection. 20 years from now, these ideas that Rust is finally pushing out into the general development population will probably be the same, and even fairly casual developers familiar with them.
r1veRRR@reddit
In my opinion Rust is pretty simple, but not necessarily easy. Go is the perfect opposite: It's easy, but not simple.
For example, in Rust, if you want to add to a list, you have to express in code whether this happens in line or whether you get a new thing back. In Go, the compiler will choose for you without ever explicitly surfacing the decision. That means the exact same code might produce a new, independent slice or return the old slice and you have no way of knowing until runtime what the case is. Simple vs. easy.
Rust is still pretty easy, IF you compare it to manually creating all the solutions to problems that Rust automatically takes care of. The error and null handling is the best in the business, and those are both things you'll eventually have to deal with in any code base of any noteworthy size.
But what about small tools, or short scripts? To me, Rust is still a great choice, though familiarity reigns supreme in this category. Meaning, you should write your scripts and tools in whatever language your team/you knows best. That being said, if you invest the time to understand Rust (which does take more time than other languages) you can very easily just use "easy hacks" to work around any more complicated topics. Use anyhow to just return a general Error, instead of having to manually define every possible error (better, but very slow). Borrow checker complains? Just clone the thing. Less memory efficient, but far faster than doing it "
the right way".
Finally, we all know what happens with small tools or quick hacks: They become forever tools. If they're written in Rust, it's a lot easier to scale from a hacky POC to a real application, where it might be harder to do in easier languages, like Python.
Alexander_Selkirk@reddit (OP)
No. For example, good C++ code tests error return codes religioously, and uses the ownership by convention. Writing good C++ is not easier to get a Rust program to compile.
kuikuilla@reddit
Nope. Especially if you know C++.
UltraPoci@reddit
Regarding mistake 8, the one about ignoring non standard library crates, there is a cool website, https://blessed.rs, which lists many well made and somewhat "standard" crates.
Derice@reddit
https://lib.rs may also be a useful website for finding crates.
Dave9876@reddit
But at times it can be hard to work out which is the one worth using, and which is the one that was abandoned 5 years ago
teerre@reddit
6.c is particularly pointant to me. I feel like every day there's someone on /r/rust or /r/learnrust asking about how to use dyn Any or TypeId to concoct some crazy data structure
cach-e@reddit
I don't quite agree with #2, at least if you are experienced in other languages.
Some year ago I tried to learn Rust by reading the book and I just got nowhere. It was a slog, so many new definitions, things to think about, etc.
When I did it the next time, and tghis time I actually learned to program Rust, I just picked a year of Advent of Code I hadn't done and went to town. As soon as I ran into something I didn't know how to do I googled it. The compiler and clippy are really helpful there as well.
I think reading the book works well for many, but I don't think it's a panacea.
PhysicalMammoth5466@reddit
I learned rust, realized its built in lies, then successfully forgotten rust, except for the scars. The scars are deep
jaskij@reddit
Re: Mistake 10 (looking at the source).
This is both good and bad advice.
Good in that it exposes people to idiomatic Rust and lets people see how others write in general.
Bad, because API documentation is a contract, and the source is an implementation detail. People will inadvertently end up relying on behavior that's prone to changing.
Speykious@reddit
I definitely made mistake 2 when I started. Although I'm fine now :p
pdxbuckets@reddit
The title led me to expect AI slop or a basic blog by someone trying to pad their LinkedIn profile, but it was thoughtful and good. Many of these I’ve already learned the hard way; many I’m still learning.