zlacker

I mean, it's felt like anytime anyone mentions any code base not written in rust, someone pops in and points out that it's not safe, and should be rewritten in rust.

I think it's all part of the language maturing process. Give it time, zealots will either move on to something new (and then harass the rust community for not meeting their new standard of excellence) or simmer down and get to work.

>>chrsig+(OP)
Well they're right. Most code written in C is horribly unsafe. Most code written in Rust is very safe. No code is guaranteed to be 100% safe - not even formally verified code.

There's a clear safety spectrum, with C near the bottom and Rust near the top. It's tedious for people to keep saying "well it's not right at the top so we should just keep using C".

I'm sure pro-seatbelt people were called "zealots" back in the day too.

>>IshKeb+302
> Most code written in C is horribly unsafe.

I think that is untrue. I worked at the Network Systems arm of Bell Labs for sixteen years, and we could demonstrate five-nines of uptime on complex systems written entirely in C.

C is a rough tool, I will grant you that, and Rust is a welcome addition to the toolkit, but saying that most code written in C is horribly unsafe, does not make it true.

>>greyha+DX2
Perhaps I misunderstand, but I don't imagine most individuals or companies writing production C code to be on the same "level of competency" as a research company as prestigious as Bell Labs.

>>IshKeb+302
The issue isn't correctness. The issue is annoyingness.

> I'm sure pro-seatbelt people were called "zealots" back in the day too.

Given that vehicles were grandfathered in, pro-seatbelt people were irrelevant to owners & drivers of said vehicle.

Just like some rust zealot asserting that some existing project with millions of lines of code should be rewritten in rust is irrelevant to the project maintainers.

>>paoda+Xf3
UNIX was found to be less secure than Multics, thanks to the additional safety guarantees provided by PL/I type system.

https://www.acsac.org/2002/papers/classic-multics.pdf

So not even back then.

>>IshKeb+302
Rust isn't seatbelts, Rust is a tank. It's hard to steer, you need 4 people to operate it, but it's safe from bullets. It can also sink in quicksand or mud very easily. Rust advocates ignore the usability problems and say "Drive a tank everywhere, it's bullet-safe". Meanwhile the average programmer will get lost in the complexity of Rust and invent shortcuts like using unsafe {} in exactly the wrong place.

>>phendr+3db
This runs contrary to my experience.

1. Coming from C++, my productivity is x2-x3 in Rust, making Rust a middle point between C++ and Python (about x8 productivity). What's more, if we factor maintenance time in, the lower costs of maintenance of Rust code makes the multiplier tend to x10, which is equal or better than Python (whose maintenance costs are important).

2. I have a colleague coming from Python (so a very different background than my C++ background), and he doesn't "get lost in the complexity of Rust" but after some use of Rust makes pretty much the same conclusions as I do: initial coding slower than Python, but roughly equal when you factor in maintenance time. He now writes the quick tools that could be Python scripts in the past in Rust when we suspect that they won't be one-off scripts (which happens very often). We get ease of distribution (static binaries), portability (to Linux and Windows), and better performance out of it too.

Although this is a comparison with C++ and Python, not C, the reasons why are simple and apply equally so to C:

1. Easy access to a good ecosystem. Adding dependencies in C or C++ is a pain. Very easy to do in Rust, preventing the need of reinventing the wheel (squarely). C suffers even more from this, given its lack of standard library and data structures (everything is a linked list :-D)

2. Memory safety and lack of UB in safe Rust brings a definitive simplicity in coding, code review and debug.

3. Result-oriented APIs and generally expressive type system are what end-up bridging the gap with Python with time.

What Rust definitely has is a learning curve. It is not optimized for taking the language without deep diving into it, or learning it in a short time. IMO it is a reasonable trade-off, given that the experience past the learning curve is so good, and that many of the things that make the learning curve so steep are integral to that experience (exclusive borrows, trait system, ...).

>>dureui+dRn
You misunderstood my argument. My argument is that if forced to use Rust (given, say, a tectonic shift in the coding world where Rust becomes dominant - something many people are clamoring for), most average developers would have a difficult time writing secure code, because they'll have to keep a higher level of complexity in mind. Productivity is irrelevant. This is the classic trap of not being able to measure thing ABC, so you measure thing XYZ and assume that it's the same.

TL;DR: Let's see what happens when average C programers are forced to use Rust. Will their code be more secure? I see no convincing arguments one way or the other. Only measuring XYZs.