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

Why you should, actually, rewrite some of it in Rust

unhandledexpression.com

Post reply on HN
Print view View original

231–240 of 300 posts

Re: Why you should, actually, rewrite some of it in Rust

#231

Post by akavel »

bandook_raja wrote: post #107
akavel wrote: post #18

Earlier quoted context omitted.

Oh no, no, no! Some people may reasonably, with some extreme care and diligence, maybe try to claim they can write safe and UB-free C code. If stars align properly. (See maybe SQLite. Seen as one of the pinnacles of crazy pedantism in C. Also, see the article about errors found recently in SQLite with fuzzing!) But with C++, it's just impossible for a human. It's too big, too quirky, too big, too wide, too deep, too…

do you mind me providing a bit personal suggestion? When you've began resorting to play of words like 'barbed fences, trip-wire mines...' instead of providing concrete proof/examples in your post, you've already lost your argument. > Writing C++ code longer than a few lines without UB is humanly impossible. Do you want me to provide one for you? Because that will definitely change your definition of 'humanly impossib…

Ok, please let me ask you a question: have you read all the fragments of The ISO C++ Standard regarding undefined behavior? I have not, but I've read enough fragments/quotes to raise hair on my back and show me how many assumptions I had and assumed safe were subtly wrong. If you have not read all the fragments, you by definition don't know enough about UB to protect against it! Sorry.

Re: Why you should, actually, rewrite some of it in Rust

#232

Post by rurban »

anp wrote: post #81
rurban wrote: post #74

Earlier quoted context omitted.

I don't agree with the underlying thesis: In 15 years, I'll be heartbroken if we're still facing an endless stream of security updates and remote root compromises when all these projects were rewritten in a popular but unsafe language: Rust. There do exist fast and SAFE language out there. With guaranteed memory safety, null pointer safety, concurrency safety, dead-lock freedom, race freedom, and even with normal syn…

Can you be specific about which languages you include in the category of "fast and SAFE"?

There are so many:

Pony, ATS, Sing#, Spec#, Felix, Gordon, Æminium, DPJ (Deterministic Parallel Java), Kilim, Haller and Odersky. A lot of more linear type languages, like PRFJ or OIGJ. See e.g. http://www.doc.ic.ac.uk/~scd/fast-cheap.pdf

I'm not sure about Factor yet, but it looks good and beats Rust in performance and features also.

Re: Why you should, actually, rewrite some of it in Rust

#233

Post by the_why_of_y »

jcelerier wrote: post #113
ekidd wrote: post #73

Earlier quoted context omitted.

> If AFL would catch the same bugs, Rust isn't better than C in this case. You can find a list of my vobsub bugs in the Rust Fuzz Trophy Case: https://github.com/rust-fuzz/trophy-case They are: 1. The shift overflow: This was harmless in both C and Rust, I believe. 2. The arithmetic overflow: This was a runtime panic in Rust, resulting in a clean crash. In C, this might have been exploitable with a complex enough att…

You would get 2. and 3. as runtime panic in C if you used sanitizers.

You would also get additional attack surface if you used sanitizers, because they were designed as debugging tools, not for production deployment.

http://seclists.org/oss-sec/2016/q1/363

Re: Why you should, actually, rewrite some of it in Rust

#234

Post by fpgaminer »

sidlls wrote: post #177
fpgaminer wrote: post #75

Earlier quoted context omitted.

Sigh. This again. The Rust language is more than just memory safety. Memory safety is certainly the most prominent and unique feature of Rust, but the language also includes a lot of features that make writing good, bug-free code easier. For example: `Result`, when returned, forces all callees to check for errors. It's all too easy to throw away error codes in C/C++. This is probably one of the most important feature…

I mainly agree that Rust is more than about safety. I just wish these other features had a tenth of the vocal support as Safety. It's even worse here on HN, where the a certain group seem to thrive on blasting not-Rust, especially if that not-Rust is C or C++. I've seen comments to the effect that anyone writing in C or C++ today is literally acting with reckless indifference to life and safety. It's terrible.

Criticism is just so much easier than constructive arguments. That's why it's rampant in communities, even HN. And controversial subjects (Bitcoin, health, food, Javascript) will magnify the problem.

It's easy to find fault in C/C++. It's easy to parrot the Rust marketing. It's not so easy to actually have spent the time to learn and use Rust, let alone articulate the subtle ways that its design, taken as a whole, is better than alternatives.

Building those constructive arguments is _hard_. I remember reading an article about error handling. It had to have been at least 10 pages worth of content, covering the history of error handling throughout all the old and modern languages, and using examples for where each fails or succeeds. It culminates, more or less, in explaining exactly why the error handling of languages like Rust outperforms in the field of systems programming.

(NOTE: The author of that article was actually arguing for the error system used in the language they developed for their OS, IIRC. But Rust was pretty darn close to the ideal the author was going for, and they pointed out as much.)

My point is that it took 10+ pages to make a solid argument for _just_ error handling. Not many people have the experience, wisdom, time, and willingness to write even a fraction of such insightful content in a comment on HN.

That said, well written, balanced comments still generally float to the top in even controversial HN threads.

EDIT: I would also like to point out something specifically in response to "I've seen comments to the effect that anyone writing in C or C++ today is literally acting with reckless indifference to life and safety."

There is a tremendous amount of pent up anger in the programming community against C/C++. The language should have been put our to pasture a _long_ time ago. Rust is the first language which has a real chance to displace it. So it's no wonder that a lot of us are willing to just burn C/C++ to the ground and jump ship.

Not to mention that as programmers we may be quickly approaching a time when security bugs become a governmental issue, and the _last_ thing we want is the government mandating how we write code. So it is in everyone's interest if we self regulate. Again, that would explain why everyone is kinda jumpy about C and security bugs.

Re: Why you should, actually, rewrite some of it in Rust

#235

Post by akavel »

FRex wrote: post #155
akavel wrote: post #36

Earlier quoted context omitted.

I'm afraid I was not being sarcastic. Sorry. This is a totally honest and dead serious opinion from a long time C & C++ user. ("stars aligning" here means "you must also have luck". As I said: see SQLite.)

Then just delete your entire OS or at least your browser, don't force yourself to use C and C++ software. Seriously. I'll let you keep LLVM so you can play with Rust. There's disliking language or the boilerplate it forces on the programmer which I can REALLY understand in case of these two and there's being a jerk and an idiot and saying any C++ program that isn't few lines is broken by the UB, you need stars aligni…

Ah, but I never called to delete any C/C++-based code! That's a strawman from you here. Also, especially I didn't say it's impossible to write anything substantial and/or useful in C++, oh, most certainly it is! But truly, I did and do claim it's humanly impossible to write anything safe in those. As to doing a programmer's job wrong, sorry if you got such impression. Wasn't my intention. C++ is powerful, and in many cases, the gains of using it overpower the risks. As to endangering people, now that's a different topic, and there are measures to protect people possible even in case of unreliable systems. But anyway that's really niche, your Windows/Linux/OSX laptop/PC won't really endanger people until you start hitting them with it, to first approximation. In the other case, like medical software, logic bugs can be I suppose orders of magnitude more dangerous to people than UB-related etc. bugs.

I'm not saying C++ kills people. But I am saying it is producing inherently buggy software, on some level. I'd say it this way: improvements that Rust, Idris, Haskell & many other new languages (and also some old ones, actually, like reportedly Modula, Ada, etc.) try to bring to the table, are similar to what procedural programming or type systems brought over assembly. Resisting those improvements is... strange to me.

[edit: I noticed I wasn't allowed to reply to some comments downstream a while before. I think this may be some kind of a signal for me to just STFU and drop the ball; even if not, I decide to just treat it so, I've said more than enough words already probably. Actually, biggest outburst of my posts on HN ever. I'm starting to think I might be having some kind of a PTSD w.r.t. C++. Anyone knows of some good therapy centers for recovering C++ veterans? :) ]

Re: Why you should, actually, rewrite some of it in Rust

#236

Post by wtallis »

biokoda wrote: post #132
bboozzoo wrote: post #130

Earlier quoted context omitted.

Can you elaborate? Although haven't tried it myself, I was under the impression that it's quite possible to write low level code for at least for x86 and ARM (and AVR?).

You can write low level code. Tier 1 platform list is very short however. https://forge.rust-lang.org/platform-support.html

It's probably unreasonable to expect a wide variety of IoT platforms to meet the "automated testing" requirement for Tier 1 status.

Re: Why you should, actually, rewrite some of it in Rust

#237

Post by tspiteri »

FRex wrote: post #176
moomin wrote: post #148

Earlier quoted context omitted.

Show me the programming language community that's a fan of the language it's intending to supplant and we'll talk. :)

I've never seen Python or Lua community do that so far. But Python is its own animal (which IMO is only highlighting how good it is), it's not supplanting anything. Rust meanwhile both hates C and piggybacks on it (using LLVM, similar syntax, cited compatibility and coexistence with C). Lua is similar, no hate, its own animal, custom syntax, good in its niche (Python's niche seems to be literally everything not super…

I've never seen Python or Lua community do that so far.

Back then, wasn't it readable Python versus unreadable Perl?

Re: Why you should, actually, rewrite some of it in Rust

#238

Post by FRex »

cyphar wrote: post #203
FRex wrote: post #155

Earlier quoted context omitted.

Then just delete your entire OS or at least your browser, don't force yourself to use C and C++ software. Seriously. I'll let you keep LLVM so you can play with Rust. There's disliking language or the boilerplate it forces on the programmer which I can REALLY understand in case of these two and there's being a jerk and an idiot and saying any C++ program that isn't few lines is broken by the UB, you need stars aligni…

I'm not sure I agree with the amount of hyperbole in the original post, but you must be joking if you want to claim that browsers or OSes are "safe" in the Rust sense of the word. Use after frees and numerous other memory bugs are discovered all the time in C/C++ programs (including kernels and browsers). This isn't an imaginary problem. Then combine multithreading and you've got a whole extra level of possible issue…

Your point being exactly what? Don't put words in my mouth because I never claimed C and C++ are as safe as Rust, just that they are good enough for millions, including you, to rely on daily with their lives and that Rust itself relies on some C++ (LLVM). I'd even say that yes, C is the least friendly and most spartan language and C++ is the most complex and hard language that are in wide use nowdays but that wasn't the OP's claim. The OP's claim was ridiculous and on the level of opinion people have of Java applets ("totally unsafe", "useless", etc.). These people who have such opinions of them don't run them in their browsers so you should not run any C or C++ on your machine either or you are clearly overdramatizing.

Mathematical provability and technical excellence has sadly little to do with adoption - see where JavaScript, Erlang, Haskell, OCalm, Modula, etc. ended up and tell me every language got what it deserved based on its own merit.

Fanboying over Rust and RedoxOS (it being impressive or not is besides the point) won't fix all that "doable if stars align C" and "humanly impossible C++ that has UB even after few lines" code out there in the government, power plants (including nuclear), infrastructure, stores, embedded, banks, ...

Egos have nothing to do with it. I dislike JavaScript, Java and C# personally (not for any technical reasons but due to my tastes) but if I've seen someone saying the are useless and everything written in them is broken I'd call BS. I'm similarly fond of Free Pascal with LCL for personal GUI toys but if someone said it'll take over the world and destroy Qt and GTK+ behemoths I'd also call BS. Hell, I'd defend your precious little Rust if someone said something stupid about it.

There's factual critique (which I have lots of myself and I don't recommend C or C++ to new hobbyist programmers but Python3), there's personal taste (that you mustn't camouflage as technical opinions) and then there's pedal to the metal "I hate the language so it's totally useless and no human can use it" BS like the OP's comment.

Rust supposedly targets C and C++ programmers so it shouldn't be acceptable to shit all over their tools and by extension their work, telling them they are stupid for liking these languages and are doing everything wrong as an engineer. The fact that such BS is disallowed in official Rust spaces is really telling of how idiotic and ridiculous it is: https://news.ycombinator.com/item?id=14755394

Re: Why you should, actually, rewrite some of it in Rust

#239

Post by kazinator »

akavel wrote: post #235
FRex wrote: post #155

Earlier quoted context omitted.

Then just delete your entire OS or at least your browser, don't force yourself to use C and C++ software. Seriously. I'll let you keep LLVM so you can play with Rust. There's disliking language or the boilerplate it forces on the programmer which I can REALLY understand in case of these two and there's being a jerk and an idiot and saying any C++ program that isn't few lines is broken by the UB, you need stars aligni…

Ah, but I never called to delete any C/C++-based code! That's a strawman from you here. Also, especially I didn't say it's impossible to write anything substantial and/or useful in C++, oh, most certainly it is! But truly, I did and do claim it's humanly impossible to write anything safe in those. As to doing a programmer's job wrong, sorry if you got such impression. Wasn't my intention. C++ is powerful, and in many…

You can write large C++ programs that are quite safe, using only higher level abstractions (no pointers or explicit memory management). This doesn't require any fancy new C++; code written to C++98 (first ISO C++ standard) will do it just fine.

For exmaple, in C++, we can put two strings together to make a new string without worrying about whether we have a buffer large enough to hold the result, and whether null termination is ensured and so on, or whether or not the original source strings are damaged in the process (they are not), or whether that memory will disappear when we return to the caller. It's just str1 + str2.

I'm no C++ advocate, bu the fact is C++ code can look like a scripting language and be safe like one. C++ also has tools for isolating and managing the C-like semantics that a C++ program might contain.

So even to clump together C and C++ as "C/C++" is not well considered. There isn't a "C/C++" language. If you post a message about C/C++ in the comp.lang.c newsgroup, put on your flame-proof asbestos underwear first.

Re: Why you should, actually, rewrite some of it in Rust

#240

Post by naasking »

rbehrends wrote: post #227
naasking wrote: post #225

Earlier quoted context omitted.

I made a claim of zero runtime overhead after directly quoting the context of automatic memory management. So are you suggesting that claim in such a context is false, citing BDDs as some example, or are you taking my claim to be more broad than the context warrants, and so are arguing a strawman?

> I made a claim of zero runtime overhead after directly quoting the context of automatic memory management. And that's what I was referring to. BDDs inherently require Rc /Arc (as long as you want to be memory-safe, at least) and therefore incur significant overhead (reference counting is one of the most expensive forms of automatic memory management). I use BDDs as an example, because there's no way to work around…

Even if your claim is correct, the existence of some programs that cannot be expressed with memory-safe zero overhead abstractions still doesn't entail your original claim. As you just said, you can use Rust's unsafe escape hatch to preserve your desired performance where it's critical and you haven't lost anything from C/C++, but you can still enjoy the safety benefits where unsafety is not needed.

And BDDs expose a safe API behind which you can hide the unsafety, so only a fragment of your system would dependent on unsafe Rust.

So we come full circle to your claim that Rust is not "at all attractive", despite being able to express programs more compactly, more elegantly, and more safely than in C/C++, without losing the performance. So I still don't see the case for this claim.

> Outside functional languages, lack of zero-cost abstractions is not a particularly common issue.

Pretty much only Ada and C++ can provide the zero cost abstractions, and they do so only with heavy syntactic and semantic costs (templates for C++, packages and wordy instantiation for Ada). The Rust language does this as part of polymorphic elaboration, which is a natural and compositional language feature, not some ad-hoc secondary language or restricted module system.

I'm frankly finding it hard to believe you think there are serious alternatives. Certainly MLTon if you want the same specialization done, but you then have the unavoidable GC cost, so you're still back to non-zero runtime overhead.

Post reply on HN