Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust is not a good C replacement

drewdevault.com

Post reply on HN
Print view View original

201–210 of 213 posts

Re: Rust is not a good C replacement

#201

Post by bb88 »

bhaak wrote: post #184
bb88 wrote: post #177

Earlier quoted context omitted.

> You don't care that Rust is much more safe than C due to all the features it has that are unlike C. But the safety aspect is Rust's main raison d'être. Rust is still young. I think it's a bit naive to proclaim the language of the future is here. Why? That was also the point of Ada until people realized that unhandled Constraint Errors could still crash missiles. https://itsfoss.com/a-floating-point-error-that-cause…

> Rust is still young. I think it's a bit naive to proclaim the language of the future is here. I never claimed that Rust is the language of the future. I didn't say it directly but I think you can deduce it from my comments that I consider a multi language approach more sensible than using the same programming language for everything. Using Rust is more safe than using C. That's valuable. > So, what's the point of R…

> The Ariane 5 explosion was not a programming error, it was a testing and specification error.

What happens when you stick a 32bit float into a 16bit float type in Ada? CONSTRAINT_ERROR. And this could happen at runtime, not compile time. It was Ada's inability to deal with unknown/incorrect inputs and deal with them in an effective way without crashing. This is not that much different than buffer overflows from unknown inputs in C, btw.

It's worth noting that this was one of the primary reasons that Ada got less and less traction in the US government, as Ada was supposed to prevent things like this from ever happening.

Re: Rust is not a good C replacement

#202

Post by village-idiot »

picacho wrote: post #123
beders wrote: post #11

> Safety. Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows. I especially refuse to “rewrite it in Rust” - because no matter what, rewriting an entire program from scratch is always going to introduce more bugs than maintaining the C program ever would. And that is why we can't have nice things. "I don't really care" if someone overflows my buf…

imho he probably meant for experienced engineers we don't really care because knowing what's underneath is way more expert than learning another language/funny syntax which tries so hard using name mangling type system to hide it.

“Smart engineers won’t make that mistake” has been shown to be false on a constant basis.

Re: Rust is not a good C replacement

#203

Post by village-idiot »

wyldfire wrote: post #143
KirinDave wrote: post #141

Earlier quoted context omitted.

It's a pretty wild world where someone makes a claim about an entire project charter based entirely off of a single random comment on github, and then the folks who claim that's wrong and cite project documentation are "the Rust Evangelism Strike Force," even in jest.

I meant the HN comments section for this article as a whole. It went from very few comments to very many comments in a short amount of time.

Write a flamebait article, and you should expect flames.

Re: Rust is not a good C replacement

#204

Post by village-idiot »

chessturk wrote: post #132
postalrat wrote: post #58

Earlier quoted context omitted.

How many thousands are larger? Now how many thousands are smaller?

Taking a total shot in the dark, but I imagine AAA video games constitute a crap-ton of C++ codebases larger than Firefox, but I wouldn't know for sure.

Finance tends to write a lot of C++ too, but I couldn't possibly estimate their code base sizes.

Re: Rust is not a good C replacement

#205

Post by village-idiot »

ddevault wrote: post #64
wyldfire wrote: post #40

> C is the most portable programming language. This is a function of popularity and time. > C has a spec. No spec means there’s nothing keeping rustc honest. Agreed, language specification is critical. The language reference [1] is very detailed, though. I'm not sure what it would take to promote this to a "specification." > That really cool feature $other_language has? Not interested. It’ll be more trouble than it’s…

>This is a function of popularity and time. Correct, both of which you have to take into account when picking a programming language today . >We have to take the good with the bad in everything, right? If Rust's future is "spectacular failure like C++" then it's probably going to be a wild success. I wouldn't call C++ a wild success. It's failed to supplant C for its entire life, and thrives only in a few niches.

The standard of success is not "we don't use C anymore", that's an insane definition of success. By that definition C didn't succeed in knocking off Fortran.

Re: Rust is not a good C replacement

#206

Post by bhaak »

bb88 wrote: post #201
bhaak wrote: post #184

Earlier quoted context omitted.

> Rust is still young. I think it's a bit naive to proclaim the language of the future is here. I never claimed that Rust is the language of the future. I didn't say it directly but I think you can deduce it from my comments that I consider a multi language approach more sensible than using the same programming language for everything. Using Rust is more safe than using C. That's valuable. > So, what's the point of R…

> The Ariane 5 explosion was not a programming error, it was a testing and specification error. What happens when you stick a 32bit float into a 16bit float type in Ada? CONSTRAINT_ERROR. And this could happen at runtime, not compile time. It was Ada's inability to deal with unknown/incorrect inputs and deal with them in an effective way without crashing. This is not that much different than buffer overflows from unk…

> What happens when you stick a 32bit float into a 16bit float type in Ada? CONSTRAINT_ERROR. And this could happen at runtime, not compile time. It was Ada's inability to deal with unknown/incorrect inputs and deal with them in an effective way without crashing. This is not that much different than buffer overflows from unknown inputs in C, btw.

That's completely wrong. It was an integer overflow. One that could not happen on Ariane 4 but because of different hardware specs. But that was only the end of the chain of fails that lead to the crash.

Ada is of course completely able to handle such a problem. But the programmers evaluated this and consciously decided not to handle it for performance reason and because it shouldn't happen anyway. But it could happen, just only on the Ariane 5.

Sorry to be blunt but I don't think you know as much as you think you do. You should read up more on the incident. You could even read the post mortem report. It is available on the net.

Re: Rust is not a good C replacement

#207

Post by steveklabnik »

MuffinFlavored wrote: post #195
steveklabnik wrote: post #135

Earlier quoted context omitted.

There are a number of different options. And today, yes, code is tied to one of them. But, and it’s not stable yet, futures and executors, the two traits, are being added to the standard library. This lets your code be generic over executors, and there are already more than just tokio. Including an embedded one, for example. Tokio wraps epoll/kqueue/iocp.

> But, and it’s not stable yet, futures and executors, the two traits, are being added to the standard library. Is this implementation going to wrap epoll/kqueue/iocp? Would you say Tokio has any drawbacks/flaws/design choices yo aren't a fan of? What are the popular choices other than Tokio?

Traits are not implementations, just interfaces. There won't be an implementation of one in std, just the interface, so that the ecosystem can interoperate.

At the moment, I think Tokio is pretty great. I wish that there was more development bandwidth to help test out some cutting-edge stuff, but I think the design is sound.

It really depends, Tokio is the most popular at the moment. This is because most of the new ecosystem is built around these new, unstable interfaces. Tokio currently runs on the older, not in the standard library one. It's all a bit confusing at the moment, to be honest.

Re: Rust is not a good C replacement

#208

Post by igouy »

mjw1007 wrote: post #62

I think there is a gap in the market for small language which is just a "better C", but developing a new language is a great deal of work, and it would be hard to compete against the alternative of using a small subset of {Ada, Rust, whatever}. Maybe the large languages should look at defining official subsets, to make life simpler both for programmers and validation. Ada used to have something of the sort (and still…

> Ada used to have something of the sort (and still does for all I know).

https://docs.adacore.com/spark2014-docs/html/ug/en/tutorial....

Re: Rust is not a good C replacement

#209

Post by Raphael_Amiard »

bb88 wrote: post #201
bhaak wrote: post #184

Earlier quoted context omitted.

> Rust is still young. I think it's a bit naive to proclaim the language of the future is here. I never claimed that Rust is the language of the future. I didn't say it directly but I think you can deduce it from my comments that I consider a multi language approach more sensible than using the same programming language for everything. Using Rust is more safe than using C. That's valuable. > So, what's the point of R…

> The Ariane 5 explosion was not a programming error, it was a testing and specification error. What happens when you stick a 32bit float into a 16bit float type in Ada? CONSTRAINT_ERROR. And this could happen at runtime, not compile time. It was Ada's inability to deal with unknown/incorrect inputs and deal with them in an effective way without crashing. This is not that much different than buffer overflows from unk…

> What happens when you stick a 32bit float into a 16bit float type in Ada? CONSTRAINT_ERROR. And this could happen at runtime, not compile time. It was Ada's inability to deal with unknown/incorrect inputs and deal with them in an effective way without crashing. This is not that much different than buffer overflows from unknown inputs in C, btw.

That's immensely different actually ... One is undefined behavior, the other is defined but crash. In the first case the problem can stay unnoticed almost forever until somebody exploits it. In the second case, if you actually test and cover your code, you will catch the problem.

Short for using a proof technology (which Ada enables and makes easy because of the large palette of constraints you can add on types), there is NO language that can statically guarantee that your program won't crash at runtime. Yes, Ada is not special in that regard. What Ada guarantees is that it will crash, so you can actually catch those kind of bugs in testing. Also nowadays you can use SPARK Ada to formally prove your code correct. https://en.wikipedia.org/wiki/SPARK_(programming_language)

Blaming on the language what is actually bad testing/architecture is pretty unfair.

> It's worth noting that this was one of the primary reasons that Ada got less and less traction in the US government, as Ada was supposed to prevent things like this from ever happening.

Do you have any source for that ? From my sources, Ada got less and less traction because of various reasons, one of them being the price of compilers at the time. I have never seen anybody saying that it was because Ada was "not safe enough", and even today it stays one of the safest languages out there in many aspects.

Re: Rust is not a good C replacement

#210

Post by bb88 »

Raphael_Amiard wrote: post #209
bb88 wrote: post #201

Earlier quoted context omitted.

> The Ariane 5 explosion was not a programming error, it was a testing and specification error. What happens when you stick a 32bit float into a 16bit float type in Ada? CONSTRAINT_ERROR. And this could happen at runtime, not compile time. It was Ada's inability to deal with unknown/incorrect inputs and deal with them in an effective way without crashing. This is not that much different than buffer overflows from unk…

> What happens when you stick a 32bit float into a 16bit float type in Ada? CONSTRAINT_ERROR. And this could happen at runtime, not compile time. It was Ada's inability to deal with unknown/incorrect inputs and deal with them in an effective way without crashing. This is not that much different than buffer overflows from unknown inputs in C, btw. That's immensely different actually ... One is undefined behavior, the…

> Blaming on the language what is actually bad testing/architecture is pretty unfair.

I think we can both agree that a SEGFAULT and an unhandled CONSTRAINT_ERROR lead to program termination.

Your right in that at least Ada raised a CONSTRAINT_ERROR. But -- the cause for a CONSTRAINT_ERROR and a SEGFAULT in this case are the same: bad handling of inputs to a function.

So in this case the results would have been the same as well. In either case it comes down to design and proper handling of inputs.

So I don't buy your argument that it is different because of undefined behavior vs. defined behavior. Ada 83 had undefined behavior, too. It's just that Ada coders (well the good ones) knew to avoid it.

> Do you have any source for that ? From my sources, Ada got less and less traction because of various reasons, one of them being the price of compilers at the time.

Having worked in a Large Defense Corp(TM) during the height of the Ada popularity, it became pretty clear that the cost of a compiler for a $100mm program wasn't really the issue.

The GNAT Ada compiler came out in 1995, and I know smaller defense contracts used that as a viable solution to write software.

The primary issues with Ada were:

1. Ada was oversold and underperformed. The Arianne-5 was the kind of tragedy that Ada was supposed to prevent. Interfacing with external systems was a pain. Tooling was a pain. The resulting executables were HUGE at the time.

And then the development itself was expensive. Towards the end of my time writing Ada, our group was coding at the rate of 2 lines of Ada code / developer hour. Compiling took hours, running and testing took hours, etc. So a 20 line code change might easily result in 10 hours of a compiling/testing cycle.

2. No code reuse across defense contractors. Ada didn't have a package manager at the time, and while there were software libraries, there weren't a lot of them. Not like the C/C++ or later the Java world would have. So if you needed something, most likely you had to write it from scratch.

3. Java got popular around 2000ish and showed what a great software ecosystem looked like. Around 2005ish most new successful defense development was on java.

Post reply on HN