Big Surprise: Rust is shit

> github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1291-2018-09-25

I thought all you Rust "evangelists" said that the language would eliminate entire classes of bugs including overflows and memory errors?

Other urls found in this thread:

archive.adaic.com/pol-hist/history/holwg-93/holwg-93.htm
twitter.com/NSFWRedditImage

durrr

Still better than the top tier of c codebase.

Attached: Dget1gqUcAAlrhE.jpg (702x508, 51.17K)

...

Because c only has "unsafe", it is designed to be as safe as possible. This includes ergonomics (rust shills find a dictionary), compiler warnings, and external tools. Rust has a "safe" mode, sure, but it is so obtuse that you *have* to write "unsafe" code to do anything non-trivial. Add to that unsafe is designed to be as unwieldy as possible, because "you said unsafe, you asked for it", and you'll find top tier rust code bases have these sorts of bugs again and again.

c is literally the most retarded unsafe language there is

Safe while still letting you do whatever you want. Not as bad as assembly, or unsafe rust.

This thread is retarded
t. I don't even use Rust

Terry was right (again)

Attached: improving-the-c-language.webm (316x236, 159.58K)

Unsafe rust is safer than standard c you retard. C Lacks so many basic type safety features.

Integer overflow is as much of an error as out of bounds indices and addresses.

Bullshit. Null-terminated strings, array decay, and lack of error handling make C less safe, as well as slower. The whole problem of "security holes" and having to constantly stay updated so you don't get exploited is caused by C. What really sucks is that most of these problems were solved in the 60s and have very simple solutions, but C can never use them.

All of that sucks compared to real languages. The only way you could possibly think C is "ergonomic" is if you're comparing it to C++.

archive.adaic.com/pol-hist/history/holwg-93/holwg-93.htm

Why am I retraining myself in Ada? Because since 1979 Ihave been trying to write reliable code in C. (Definition:reliable code never gives wrong answers without an explicitapology.) Trying and failing. I have been frustrated tothe screaming point by trying to write code that couldsurvive (some) run-time errors in other people's code linkedwith it. I'd look wistfully at BSD's three-argument signalhandlers, which at least offered the possibility of providehardware specific recovery code in #ifdefs, but grit myteeth and struggle on having to write code that would workin System V as well.There are times when I feel that clocks are running fasterbut the calendar is running backwards. My first seriousprogramming was done in Burroughs B6700 Extended Algol. Igot used to the idea that if the hardware can't give you theright answer, it complains, and your ON OVERFLOW statementhas a chance to do something else. That saved my bacon morethan once.When I met C, it was obviously pathetic compared with the_real_ languages I'd used, but heck, it ran on a 16-bitmachine, and it was better than 'as'. When the VAX cameout, I was very pleased: "the interrupt on integer overflowbit is _just_ what I want". Then I was very disappointed:"the wretched C system _has_ a signal for integer overflowbut makes sure it never happens even when it ought to".It would be a good thing if hardware designers wouldremember that the ANSI C standard provides _two_ forms of"integer" arithmetic: 'unsigned' arithmetic which must wraparound, and 'signed' arithmetic which MAY TRAP (or wrap, ormake demons fly out of your nose). "Portable Cprogrammers", know that they CANNOT rely on integerarithmetic _not_ trapping, and they know (if they have donetheir homework) that there are commercially significantmachines where C integer overflow _is_ trapped, so theywould rather the Alpha trapped so that they could use theAlpha as a porting base.