Earlier quoted context omitted.
"Rust basically just calls 'free' for you the moment something goes out of scope." C++ does that too with RAII. Go ahead and use whatever STL containers you like, emplace objects onto them, and everything will be safely single-owned with you never having to manually new or delete any of it. The difference is that C++'s guarantees in this regard derive from a) a bunch of implementation magic that exists to hide the fa…
the tradeoff is that ~you have to guess where rust is doing the frees, and you might be wrong . in the end this would be strictly equivalent to an explicit instruction to free, with the compiler refusing to compile if the free location broke the rules. It's really too bad rust went the RAII route.
Flattening Rust’s learning curve
171–180 of 405 posts
Re: Flattening Rust’s learning curve
#172Polymorphic dispatch on a set of known operations, that compose a specific type.
Re: Flattening Rust’s learning curve
#173Earlier quoted context omitted.
I don't know how to read your comment other than "nothing hard is worth doing". Some things have benefits and drawbacks, is the existence of drawbacks always a non-starter for you? I'm trying to phrase this as delicately as I can but I am really puzzled. If someone wrote an article about how playing the harp is difficult, just stick with it... would you also say that playing the harp is a terrible hobby?
Maybe people need persuading to learn Rust not just because they think it's hard, but also because they think it's bad? Not everything hard is worth doing. Difficulty is just one of the factors to consider. I started to learn Rust, but I was put off by the heavy restrictions the language imposes and the attitude that this is the only safe way. There's a lack of acknowledgement, at least in beginner materials, that by…
Historically, programmers drastically overestimate their ability to write perfectly safe code, so it's an enormous benefit if the compiler is able to understand whether it's actually safe.
Re: Flattening Rust’s learning curve
#174Rust is wonderful but humbling! It has a built in coach: the borrow checker! Borrow checker wouldn't get off my damn case - errors after errors - so I gave in. I allowed it to teach me - compile error by compile error - the proper way to do a threadsafe shared-memory ringbuffer. I was convinced I knew. I didn't. C and C++ lack ownership semantics so their compilers can't coach you. Everyone should learn Rust. You nev…
If it isn't the always hated SecDevOps group of people pushing for the security tooling developers don't care about, at very least on build pipelines, they would keep collecting digital dust.
Re: Flattening Rust’s learning curve
#175My problem with rust is not the learning curve, but the absolute ugliness of the syntax. It's like Perl and C++ template metaprogramming had a child. I just can't stand it. Python is my favourite, C is elegance in simplicity and Go is tolerable.
C has a simple syntax, but it is most certainly not elegant.
Re: Flattening Rust’s learning curve
#176Re: Flattening Rust’s learning curve
#177Re: Flattening Rust’s learning curve
#178Variable in rust is not a label you can pass around and reuse freely. It's a fixed size physical memory that values can be moved into or moved out of. Once you understand that everything makes sense. The move semantics, cloning, borrowing, Sized, impl. Every language design element of rust is a direct consequence of that. It's the values that get created, destroyed and moved around and variables are actual first-class places to keep them with their own identity separate from values that occupy them. It's hard to notice this because Rust does a lot to pretend it's a "normal" language to draw people in. But for anyone with experience in programming that attempts to learn Rust I think this realization could make the process at least few times easier.
It's hard to shift to this new paradigm and embrace it, so in the meantime feel use a lot of Rc and cloning if you just need to bang out some programs like you would in any other mainstream language.
Re: Flattening Rust’s learning curve
#179Earlier quoted context omitted.
I’m not sure why it’s counterintuitive that &str and String are different things. Do you also find it counterintuitive in C++ that std::string is different from const char* ? What about &[u8] and Vec ?
Better analogy is std::string_view vs std::string
Re: Flattening Rust’s learning curve
#180On the opposite, "Unsafe" Rust is not simple at all, but without it, we can't write many programs. It's comparable to C, maybe even worse in some ways. It's easy to break rules (aliasing for exmaple). Raw pointer manipulation is less ergonomic than in C, C++, Zig, or Go. But raw pointers are one of the most important concepts in CS. This part is very important for learning; we can't just close our eyes to it.
And I'm not even talking about Rust's open problems, such as: thread_local (still questionable), custom allocators (still nightly), Polonius (nightly, hope it succeeds), panic handling (not acceptable in kernel-level code), and "pin", which seems like a workaround (hack) for async and self-referential issues caused by a lack of proper language design early on — many learners struggle with it.
Rust is a good language, no doubt. But it feels like a temporary step. The learning curve heavily depends on the kind of task you're trying to solve. Some things are super easy and straightforward, while others are very hard, and the eventual solutions are not as simple, intuitive or understandable compared to, for example, C++, C, Zig, etc.
Languages like Mojo, Carbon (I hope it succeeds), and maybe Zig (not sure yet) are learning from Rust and other languages. One of them might become the next major general-purpose systems language for the coming decades with a much more pleasant learning curve.