Hacker News Reader

Comment by Someone1234 | Hacker News Reader

I don't follow that argument.

C++ didn't break through because the benefits didn't outweigh the drawbacks compared to straight C (meaning you can implement C++ like concepts in straight C, and not have to deal with a lot of baggage C++ brings).

Rust is a whole other kettle of fish. It has more or less been proven by this point that people cannot write memory safe C, even experts in the language are still introducing memory-unsafe bugs in 2018. Therefore Rust is bringing features the C language cannot offer.

Which isn't to say I know that Rust will be "successful." I don't know that. But I do know it is worth TRYING to see if it can be successful, and C++'s lack of success isn't really a counter-argument.

I'm still sad that Microsoft's Singularity OS[0] never got further developed, interesting concept.

[0] https://en.wikipedia.org/wiki/Singularity_(operating_system)

View on HN

> ... It has more or less been proven by this point that people cannot write memory safe C, ...

Or concurrency safe. There aren't many languages that can help with this class of bugs. Like race conditions. (Someone on HN said Pony is another language that has concurrency/thread safety guarantees.)

Bias is everything, Joe Duffy briefly mentioned at his RustConf keynote that many at WinDev did not believe Midori was possible, even when shown running in front of them.

i think this would be the link, if anyone is interested: https://www.youtube.com/watch?v=EVm938gMWl0

Not to shill but I'm working on a Singularity/Midori-inspired Rust JIT-compiled operating system. If that ever gets anywhere I'll post a link/Show HN.

Yeah I was sad about Singularity too. As for C++, yes it doesn't being an absolute guarantee of memory safety, but C is so error prone that it's ridiculous to suggest anything below an absolute 100% guarantee wouldn't be a compelling improvement. C++ was a gigantic improvement in the safety of C (i.e. such that following good coding practices actually gives you legitimate confidence your code is memory-safe) while still having all of its flexibilities, and yet it still got shunned, so I'm unconvinced that a nitpicky language like Rust makes all the difference just because of its formal verification. If kernel folks wanted compiler help with memory safety they could've embraced C++ and gotten most of the way there.

C++ can bring very little baggage. That's why its widely used in Embedded environments.

And I'd wager that C++ can write far better optimized abstractions than a human in C every could. In most cases.

Writing memory-safe C is clearly possible - many other enviroments are written in C. It come down to using a safe subset.

> Writing memory-safe C is clearly possible - many other enviroments are written in C

Show me one major piece of C software that does not have frequent memory-safety bugs and I might believe that.

djbdns/qmail might qualify here.

qmail had LP64 memory corruption bugs.

One ever right? I wouldn't count that as "frequent" - lots of programs in memory-safe languages have more/worse bugs than qmail.

Of course, the existence of one significant not-too-vulnerable C program doesn't really prove a lot either way...

I though Georgi Guninski found several.

Reply on news.ycombinator.com