That hasn’t been my experience with it. I found rust significantly harder to learn than C; and this is after I already knew C. (At least - learn rust to the point of feeling productive, and like I wasn’t fighting the borrow checker constantly).
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.
> You essentially can’t write rust at all until you understand rust references, lifetimes (implicit and explicit) and the borrowchecker.
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.
Eh. If you don’t know how references work in rust, you’ll struggle to use most of the standard library or any 3rd party crates. And if you can’t pass mutable references to functions or iterators there’s a lot of programs that will be hard to write at all. Performance will be pretty rubbish too.
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.
> but you also need to learn ecosystem, libs, build systems, testing.
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.
If you want to learn rust, there really isn’t a way to avoid learning lifetimes and the borrow checker. It’s a core part of how the language works. You can probably get partway there with Rc and by cloning stuff everywhere but you’ll still run into borrowck problems. Rc doesn’t turn off the borrow checker. (Nor does unsafe). But then you won’t have the tools to solve your problems. And you also won’t know how to use most of the standard library or any crates. That’s no way to write rust.
> 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.
Given the number of CVEs that can be directly attributed to C and C++ you only need to be half-joking to argue that approximately nobody has managed to learn the languages sufficiently to write production code in them.
As uncomfortable as this is to say, the existence of latent security vulnerabilities doesn’t seem to stop people from shipping a lot of apparently working code in C and C++.
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.
Which is why some people push for no longer using C and C++ as much as possible. It's just not feasible to expect the average programmer to avoid all the security pitfalls. Of course, whether Rust is the best option isn't a given.
There aren’t a lot of memory safe options if you want the kind of performance rust offers. Rust is fine, but it’s far from perfect. It’s hard to learn, complex, and the macro and async systems are honestly a bit of a mess. I’m really looking forward to whatever comes after rust. I’m hoping some bright sparks out there manage to make a language with rust’s memory safety but that cleans up some of rust’s rough edges.
To be fair, how many applications really need Rust's level of performance? I mean operating system code and drivers... But, many apps are getting the job done in electron with a browser engine.
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.
Yeah I think I broadly agree with you. Not many applications need rust's performance. Go, Java, C#, nodejs, python, etc are all great languages.
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.
In their defence, there are entire classes of security bugs that memory safe languages protect you from. A large percentage of the security bugs in Chrome, OpenSSL, iMessage and lots of other apps wouldn’t have happened in any of the languages you listed. Or, almost certainly, in Rust.
I suspect fewer than you think. At least in FAANG code.
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.
If you're going to start writing it testing or C++ like Rust or follow certain guidelines, a lot of them. But if you're going to constrain how you do things, why not use a language that also gives you higher level functionality along the way?
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
> There are ways to eliminate majority of those issues in cpp as well, but people simply don't care.
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.
I partially agree with you. I think most security compromises are due to misconfigured mongodb databases, bad passwords and unpatched software staying unpatched for months or years. Things like that. Lots of B tier engineering companies get done by this stuff every year because they’re sloppy.
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.
Apple? The same company that forked the JVM and then was taking months to fix vulnerabilities for which exploits were readily available on the internet, and that had been fixed immediately on linux and windows?
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.
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.