Seems like RUST needs work to become easier to learn. Hard for a business to take a risk on using it (outside of a use case absolutely needing a memory safe language) if the talent pool is shallow.
I was making a little toy compiler in rust and basically gave up when I wanted to make a change that would have amount to string -> string_view in c++ because in rust I now need to tell the compiler that the String to my &String is going to outlive the struct. Now I understand why it's good but Id rather just let c++ blow my feet off. Maybe once I nail down all the data structures I'll rewrite it in rust.
People used to C or C++ perspective tend to reflexively (over)use references to avoid copying, but references in Rust are to avoid owning, and not-copying is handled in different ways.
BTW, apart from edgiest of edge cases, &String is a useless type in Rust, because String already stores data "by reference" and is never implicitly copied. For loans it's generally better to deref to &str.
Can you give a few examples?
How would not copying be handled?
Sorry for the basic questions. Your comment tickles something in my brain that suggests I need to know.
It is 'borrowing' because you don't own it, not because you don't want to clone/copy it. Sometimes it is cheaper to borrow than it is to clone/copy; sometimes it is not.
I find it confusing still... Been wanting to do a few things that would mean dealing with it streams that could be cp437 or utt8, generally and haven't been quite sure how I want to deal with it.
Basically a BBS door running service, with some extra niceties internally.
Working with the code base gets so annoying if you suddenly want to change something you didn't plan for.
Such changes can have a domino effect through the code.
You need to know all of the rustisms. Plus you need to have a general knowledge of memory. You need to understand how memory is being abstracted and how to work within those constraints so as not to be slow. You need to know all of the monads, what they mean, why each exists, what the nuance is, and why you might use one over another in a specific situation.
It’s not difficult so much as it just takes so much time and challenging-yourself practice to try to memorize everything.
A “being effective at rust” book would probably dwarf a “being effective at C++” book in pages assuming similar prose. And we all know how much of a beast C++ is.
I've written C++ for close to a decade before switching to Rust, and this is categorically untrue.
> Plus you need to have a general knowledge of memory. You need to understand how memory is being abstracted and how to work within those constraints so as not to be slow.
If anything, this is more true so of C++.
> You need to know all of the monads, what they mean, why each exists, what the nuance is, and why you might use one over another in a specific situation
You can use a lot of stuff before needing to know their full history. You don't need to know the history behind 0, null, pointer, numbers and addresses before, how hardware works, etc to use Option, for example. You also don't need to know the (inconsistent and arcane) history of errno and magic numbers to use Result. Etc, etc.
This vastly over-exaggerates Rust's complexity.
Yes, it borrows concepts from functional programming, but a lot of these concepts are simpler than stuff you deal with in imperative programming.
I think the issues here is that people don't tend to like to change their way of thinking, even if it's for the better. Also, Rust has ample in common with imperative/traditional language, so it's not a huge leap into some alien mental model, as you make it sound.
Further, C++ makes you think way more than Rust; in Rust the compiler does a lot of the thinking for you. Not to mention, the type system is easiest to reason about than C++'s old (and mentally inefficient) template system.
the closest thing to required would be move semantics.
No it doesn't.
people were effective with C++ before std::optional existed, before compiler assisted move semantics existed, and SFINAE is not something anyone has ever needed to understand in order to use something like the STL or any other template based library, such as Boost.
You don't know what you're talking about, this isn't up for debate.
What's the difference?
Now some of the more complex things, have been far more complex to do by hand.. Shared data, channels, Arc, etc. Those have been a bit more cumbersome and still not sure I've done the right thing at times.
Arguably becoming an expert in C means you need to understand all the nuances of undefined behaviour. And that’s a much harder process. But it can happen slowly. Rust preloads all the pain. You essentially can’t write rust at all until you understand rust references, lifetimes (implicit and explicit) and the borrowchecker. The payoff is huge, but I found climbing that mountain to be no joke.
And I don’t think a lot of those CVEs come from people misunderstanding the languages. As I understand it they mostly come from honest software bugs. C++ makes it easy for honest mistakes by experts to become security nightmares. This is a controversial opinion - but I think the fault is in C and C++ themselves. Not the programmers who need to work even harder such that they stop ever making mistakes.
I like rust, I like the sensibilities. Maybe my experience is too limited to higher level problems though. There's plenty of room for the likes of Go, Java and C# is all I'm getting at.
But the software which does need or want "native performance" is incredibly important software. I'd use rust for things like databases, operating systems, web browsers, high performance web servers, network services (samba, ssh), and other "systems" software like that.
Most of the lines of code ever written are probably in application code. If you're making a company website, python or C# or whatever is totally fine. But a remarkable proportion of the lines of code your computer actually runs were written in C or C++. Your web server might be in python, but if you use nginx as a proxy - well, thats C++ (I think). Use postgres? C++. Running your software in linux? C. Testing with Chrome? C++. What is python itself written in? I dunno, but I bet its either C or C++. You get the picture.
Whether or not rust is a big deal is largely a matter of focus.
My point is that I just feel like "but someone please think of the ̶ ̶c̶h̶i̶l̶d̶r̶e̶n̶ memory safety" argument is over blown. There are ways to eliminate majority of those issues in cpp as well, but people simply don't care.
If You want to use Rust because it's just better language - go for it, I do it as well. But let's actually use that as an argument, instead of hiding behind superficial ones
If its that easy, why do Google, Apple, Microsoft and basically everyone else keep making memory safety related bugs? Are they all just idiots? Do you think they just don't care about security? Carmack found C++ static analysis tools found mountains of latent bugs in the quake source code - despite the game running great.
Personally I find it a very arrogant statement to claim that memory safety in C++ is easy. If google finds it hard, despite throwing millions each year into the problem, I'm of a mind to believe them.
Yes, people don't care nearly as much as we like to pretend in online debates
But memory bugs in C++ seem genuinely hard even if you do care about the problem. Google and Apple have never (as far as I know) had customer data stolen by some trivial misconfiguration problem. They pay out a lot of money in bug bounties. Google recruits some of the world’s smartest people to look for security problems in their products. And I’m sure they pay a bomb for access to proprietary C++ static analysis tools. And yet, they apparently still can’t consistently write memory safe C++ code. So yeah, I think that writing bug free c++ at scale is hard even if you do care about it.
The same company that has had a stream of no click 0days in imessage, because they parse the messages outside of a sandbox, and patch the issue but not the larger issue of the no-sandbox?
Yeah they don't care about security at all. It's mostly just a thing their marketing department talks about. I'm sure their R&D budget for it is quite limited given their size.
In fact all the laid off people probably feel less smart then average for accepting to work somewhere that treated them like that.
Google chrome has had a fair few CVEs over the years despite having a lot of the worlds best security researchers working full time looking for security vulnerabilities.
I think someone has tried reading the compiler warnings.
There’s an old story about John carmack running a new static analysis tool on the quake3 source code. The code worked well. The tool apparently found a huge list of issues in the code - including a massive pile of real bugs. Then he tried another static analysis tool and it found more real bugs. And so on.
The story is well worth a read. This is a great takeaway:
> This seems to imply that if you have a large enough codebase, any class of error that is syntactically legal probably exists there.
C++ is really hard to do “right”, at any scale in a real team.
http://www.sevangelatos.com/john-carmack-on-static-code-anal...
You can if you're willing to use stuff like .clone() and the interior mutability types. In Rust, you can tell when code has been written to be a bit sloppy because it has that kind of boilerplate. And the compiler checks are a huge help when it comes to refactoring the code and making it cleaner and better-performing.
You might be able to write some simple programs, but I wouldn’t say you know rust yet, or could really be productive with the language.
language itself maybe, but you also need to learn ecosystem, libs, build systems, testing.
Benchmark could be: how fast you can learn and bootstrap some type of app of your choice: high performance DB or torrent server, etc.
> You essentially can’t write rust at all until you understand rust references, lifetimes (implicit and explicit) and the borrowchecker
why is that? You can write rust the same way you write C but with nicer syntax, standard lib and build system and more potential to future expansion.
That’s a really good point that I hadn’t thought of. If we include header files, compiling and linking, makefiles and CMake and the mess of dealing with 3rd party libraries in C - well, yeah. All that stuff is probably worse than learning the rust borrow checker. I think I’ve forgotten how horrific that mountain is for beginners because I learned most of it decades ago, while the pain of learning rust is still fresh.
> why is that? You can write rust the same way you write C
Because I use pointers everywhere in my C code. Rust’s borrow checker simply won’t compile my code if I transliterate it directly from C. There are software patterns which work well in rust with the borrow checker in mind - but they take time to learn and get used to. Until you do, you simply aren’t productive.
borrow checker is more relevant to C references I think.
For pointers you can use Arc or Rc and don't worry about borrow checker.
Disclaimer, I am not a rust or c coder, so my opinion has a high chance to be wrong..
> Disclaimer, I am not a rust or c coder, so my opinion has a high chance to be wrong..
I’ll take a step back. I hope this is helpful to someone and not patronising.
Go and similar languages are memory safe because no matter what go code you write, go runs your program with a GC that makes sure your variables are freed correctly only when it’s safe to do so. Rust’s safety is very different. It comes from checking at compile time that your program is written in a way that obeys a bunch of complex rules. For that to work, you have to write your code very carefully. If you mess up, the compiler doesn’t fix it for you. It just refuses to compile. So you have to write your code with those invariants in mind, or your program won’t build at all.
C code generally doesn’t obey any of rust’s rules - for obvious reasons. If you were to just blithely translate C to rust code, the rust compiler will refuse to compile your program because the rules aren’t being followed. To write rust code that the compiler accepts, you need to first learn the borrow checker’s way of seeing the world. Then you need to restructure your code to work in accordance to rust’s rules. And sometimes that’s a super obscure and tricky problem.
Weirdly, I think it’d be much easier to go the other way. Any compiling rust program could be translated into a memory safe C program if we had a compiler that did that. (I think). And lots of C programmers say learning rust made them better at C - because rust’s rules genuinely teach you to be more disciplined with memory and show you some clear rules for making C code that’s much less error prone.
Not learning the borrow checker is like not learning how objects work in Python. You could write some simple programs. But you’re going to have a bad time, especially if you try to do anything nontrivial, use library code or read anyone else’s programs.
Specially if we are talking about anything related to graphics programming, or asynchronous programming.