3 ms·
Why is that?
by endorphine 3y ago
Why is that?
- _hypx 3y agoC is basically portable assembly. It should be as simple as possible. That is closer to what Zig is trying to do than Rust.
- xedrac 3y agoNot sure I follow your line of reason. From a technical standpoint, I see only one reason why Rust could not completely replace C. And that reason is obscure hardware platforms that LLVM doesn't target. Otherwise, it's superior in every way I can imagine. More complex? I guess that depends on your project. If you work mostly in small code bases where it's easy to get things right, then I'd say it's a toss up. But if you're dealing with a large multi-threaded code base, with lots of heap allocations and shared ownership etc... Rust will be far less complex than C. I highly doubt the Linux kernel developers introduced Rust to add more complexity. They did it to reduce complexity in the system, and make it more accessible to new developers. The Rust compiler is soooo liberating once you get over the initial learning curve, which I admit can be a little annoying.
- _hypx 3y agoThere are a vast number of “obscure hardware platforms” especially once you include embedded systems. There are also many circumstance where you must write unsafe code. While you could in theory use Rust for most cases where C is being used, there are a lot of cases where it would be a bad fit. There will never be one language that can do everything well.
- xedrac 3y agoFor those obscure hardware platforms, I agree that Rust isn't a good tool for the job. (Although there are GCC integrations for Rust too, which may solve those issues in the future). But arguing that having to write unsafe Rust means it's a bad fit, makes no sense. 100% of C is "unsafe" in the sense of the word, whereas you may reduce that close to 0% with Rust. Even if you only got to 50%, that's a large chunk of your code base that you have certain guarantees about, simply by compiling it. Anyway, my whole point here is that I haven't heard any good arguments about why Rust isn't a good C replacement, other than the fact that it cannot target as many platforms. If it targets the ones you care about, then it's a wonderful choice to replace C.
- _hypx 3y agoFor a lot of cases, 0% unsafe code is pretty unrealistic. Using even 50% unsafe code means that you must be able to reason about how safe and reliable the code really is. At which point you are better off with a simple language that a good developer can quickly figure out what is happening. A complex language makes this harder, not easier.
- xedrac 3y agoI think we can just disagree here. But I have to assume you haven't done any significant development in Rust, or at least haven't experienced the freedom it gives once you get over the initial awkwardness. I find Rust is easier to reason about than C, partially because it's more explicit. And that its compiler is better than a good C developer. I've mentored many veteran embedded C developers who scoffed at Rust with a similar attitude. Within a month or two though, they all changed their tune and came to prefer it.
- _hypx 3y agoYou are basically attacking a strawman. It is not Rust vs. C, but Rust vs. alternatives to C. It is unlikely that Rust will end up being better than all alternatives that are being developed.
- xedrac 3y agoDidn't mean to attack. I just didn't see any valid arguments as to why Rust was less suited to replace C than other candidates.