I truly do not understand this Rust-for-all-problems mentality.
I was under the impression that Rust was essentially the next generation of C, meant for things like compilers, embedded systems, and other places where memory truly matters.
Why are we shoehorning it into things like REST APIs and frontend frameworks? One look at that syntax and I'd think anyone could see it's not the right tool for the job, even if there room for disruption in those spaces.
As a C (not C++) programmer, I understand where you're coming from — Rust is a big complicated language, like C++, in comparison to C — but personally, I really want to use Rust in some applications where I would otherwise use C. I don't think it can be said universally that Rust has no value to C practitioners or that Rust's designers don't understand why people use C.
As a long-time C guy, it's nice to see Rust as a modern replacement. But most of the time, such low level programming is not needed.
The popularity of Rust and its friendly hand-holdy docs almost don't even make sense for what it is, to me anyway. I suspect it will end up frustrating many high-level developers.
Rust wants to be the new C without C warts, using the compiler to ensure memory safety (up to a point), promoting immutability and having generics baked in.
I'm not a C programmer, but I think Rust can fit almost everywhere C can fit.
Ah. If anything, the whole "rust as better than C for everything" thing is starting to hurt its reputation, regardless of veracity. People get so focused on its use in perf-critical applications they ignore its other strengths. eg I've never replaced C code with it, but we redid our whole PHP backend as a rust app, because it's great for rigidly defined business rules too.
I can see C++ developers migrating as the philosophy of C++ seems to be more aligned with Rust than C (C solves problems by forcing you to write more C, C++ solves problems by adding more language features).
I’m not sure whether I would enjoy using Rust as I dislike the verbosity of C++ with its more complicated syntax and multitude of “features”.
What makes you think that rust is a long term replacement for c++? I'm neither a rustacean or a dogmatic c++ follower, but it'd pretty clear to me right now that rust isn't going to replace C++.
There is so much inertia in the field with both existing projects and new projects being written on C++, what seems more likely is you end up with a split akin to C vs C++
Pretty much this. I like C aesthetically, but once you had to debug memory corruption on an embedded MCU, writing Rust is a productivity upgrade. It certainly is a downgrade from Java or Golang, but thats because you're in the wrong domain - use the right tool for the right job.
Rust, I'd argue, is the language trying to really take on most of the C use cases. The only one it's really not trying to take over is old embedded work where C is pretty much the only option.
Otherwise, I can't think of any circumstance Rust isn't trying to muscle in on C and C++'s territory.
I know it's a meme, but it really does seem like most C or C++ code would be better off transitioning to Rust at some point. That includes the entire Linux kernel, web browsers, entire OS's...
Rust is not a C replacement, it is a C++ replacement.
Many of the people writing code in C do not want to use C++.
And many of the embedded use cases for C already involve very careful memory usage. If you've banned malloc and don't have threads, you've removed a huge swath of common bug sources right off the bat.
For someone writing code to setup registers on a DMA controller, Rust has nearly 0 benefit.
(That said, no one should be writing new command line utilities in C, parsing arbitrary data in C is dangerous!)
So your argument is that because rust doesn't solve all problems people shouldn't strongly consider replacing C code with it, even though rust avoids entire classes of critical bug types in C?
I happen to like rust, though I would not suggest that it is the only solution to the classes of problems it avoids. I would, however, suggest that people very strongly consider using languages that avoid the problems that rust avoids whenever possible. Like, literally any time you're considering writing C or C++, at least strongly consider rust or another much safer option.
Wouldn't modern C++ be better suited than Rust because it's closer to C?
I know that old C++ got some bad reputation in the past but I think it's time to reconsider that with the changes that started with C++11. The only area where Rust really is better is the management of lifetimes and its associated higher memory safety.
Ah. If anything, the whole "rust as better than C for everything" thing is starting to hurt its reputation, regardless of veracity. People get so focused on its use in perf-critical applications they ignore its other strengths. eg I've never replaced C code with it, but we redid our whole PHP backend as a rust app.
Of course, but shifting the burden onto developers, where most of them aren't professional libc or kernel engineers, leads to avoidable issues.
Rust seems familiar enough to many developers, and forces them to think about resource management before running the code by not allowing incorrect code, so I hope it will lead to more libraries and applications that would have otherwise been easily plagued with issues due to choosing C. Granted, I'm not a fan of how Rust's surface has turned out, but it's a sensible compromise to attract masses of developers into writing less buggy code that operates on the same level as that written in C. So I use it as a C replacement, and for that use case I like it because there's momentum behind it.
The only problem is that for some, rust is a silver bullet that is going to bridge lack of system dev. by learning another language. Sorry it does not work this way. C is just fine, we don't need rust, it can probably be implemented as another preprocessor layer of c. And quite frankly, I am failing to see, what benefits it provides if I throw c++ in equation.
I'm not promoting Rust, nor have I actually written anything in it. I do think though it's a step in the right direction.
> But you don't get that effect by ramming it down other people's throats, you get that effect by showing it in practice.
I disagree. I've seen many C programmers who think that C is the be all end all of programming languages. Those people will not be convinced by showing them another technology that is better in practice. The fact that it's actually unbelievably hard to write correct software in C is somehow a point of pride for many people, though I speculate that few of them can actually follow through.
Of course there will always be logic bugs in software, even with formal systems and whatnot (i.e. bugs in the specifications). But memory bugs and the resulting security exploits could in many cases be a thing of the past already.
Many industries have similar regulations, i.e. seatbelts in cars. If somebody dies because of a faulty or non-existing seatbelt, there will be consequences. If somebody dies because they were talking on the phone and the car didn't prevent it, well, you can't control everything.
Is this a buffer overflow? Why was this written in C? No good answer - pay up.
I was under the impression that Rust was essentially the next generation of C, meant for things like compilers, embedded systems, and other places where memory truly matters.
Why are we shoehorning it into things like REST APIs and frontend frameworks? One look at that syntax and I'd think anyone could see it's not the right tool for the job, even if there room for disruption in those spaces.
reply