Why you should, actually, rewrite some of it in Rust • Hacker News Board

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

#241

Post by akavel » Wed, Jul 12, 2017, 11:15 PM UTC

FRex wrote: post #238

cyphar wrote: post #203

Earlier quoted context omitted.

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…

Regarding my initial outburst, I'd like to clarify that it was specifically against a comment claiming that rewriting C code in ("modern" or not, whatever) C++ is the safest choice if someone is worried about security of a C codebase. I didn't actually even say a word about Rust. The C vs. C++ claim there was already enough to make me want to cry loud.

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

#242

Post by _dcwr » Wed, Jul 12, 2017, 11:16 PM UTC

thephyber wrote: post #218

_dcwr wrote: post #139

As someone who really likes C and C++ I feel like the biggest reason for me not even thinking of Rust as a viable language right now is the community attitude. It seems so damn hostile to C and C++. Anyone who thinks C and C++ is viable is a misguided idiot, bad programmer, writing unsafe software, etc. to these people. Some badass below even just said that "writing C++ code longer than a few lines without UB is huma…

> all these FUBAR C/C++ systems (...) work well enough to transfer that kind of garbage to me I don't think you read the article. The author specifically cites lots of different types of hyperbolic "rewrite everything in Rust!" arguments and explains how this article is not that and he doesn't advocate for that. The author of the article advocates "surgically replace weaker parts but keep most of the project intact."…

The garbage I was referring to was in the comments "below". Namely: "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" and "writing C++ code longer than a few lines without UB is humanly impossible", not the article, I quoted the latter shorter one in my original message.

I consider Java browser applets unsafe trash and I'd never run one I don't absolutely trust. This person has similar (or even worse) opinion of C and C++ languages but runs tons of software in them with seemingly no problems since his idiotic comment made it in here and arrived to me intact despite all the C and C++ software on the way from him to HN to me.

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

#243

Post by hyperpape » Wed, Jul 12, 2017, 11:18 PM UTC

lj3 wrote: post #29

Has anyone done any in depth explorations of the safety and security of rust code vs well written C or C++?

I've never seen anything in-depth, but there's a lot scattered throughout pcwalton's comments on HN. For instance: https://news.ycombinator.com/item?id=7587978.

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

#244

Post by _dcwr » Wed, Jul 12, 2017, 11:24 PM UTC

thephyber wrote: post #216

_dcwr wrote: post #139

As someone who really likes C and C++ I feel like the biggest reason for me not even thinking of Rust as a viable language right now is the community attitude. It seems so damn hostile to C and C++. Anyone who thinks C and C++ is viable is a misguided idiot, bad programmer, writing unsafe software, etc. to these people. Some badass below even just said that "writing C++ code longer than a few lines without UB is huma…

> I feel like the biggest reason for me not even thinking of Rust as a viable language right now is the community attitude Kinda reminds me of the "coal vs. renewable energy" feud. The first tier arguments are formed around {economics, externalized costs, existing infrastructure, base load vs intermittent load} and then second-tier arguments align around {culture, history, identity, momentum, geography, political par…

I'm an outsider and there is a war every damn time the word Rust comes up on HN. I've yet to see bashing any language to that degree in Erlang threads, Python threads, etc. Something has to be up with that.

I'm not using C and C++ professionally at all so the only place Rust has to fit in is fun or potential long term professional opportunity (assuming Rust is a fair bit more widespread than now by then, otherwise C and C++ win in the native field for employment opportunities), I'll not have fun (and I won't learn anything I don't immediately need that won't bring me fun) in a sea of vitriol against anyone who doesn't hate C and C++ so I'm happy Rust community guidelines forbid such idiocy in official spaces and documentation.

Rust is apparently targeting C and C++ devs but at the same time the ones that like it are going crazy and saying stuff about C and C++ being impossible languages (I agree they are by far the most spartan and hardest in the mainstream right now but not impossible as evidenced by lots of quite reliable software written in it, some that lives depend on).

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

#245

Post by akavel » Wed, Jul 12, 2017, 11:33 PM UTC

blub wrote: post #108

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…

I struggle to imagine how you could be more wrong. C offers minimal if any possibilities for writing safe code, while C++ offers many. Anybody who has the faintest clue about both languages should know that.

C is kinda small enough, that I imagine one can maybe have some chance at trying to hold the whole of it, including all nuances/warts, in one's head. Like, maybe even actually write a compiler for it. (See e.g. Dennis Ritchie, Fabrice Bellard.)

With C++, good luck even reading and understanding The ISO C++ Standard. Not to say fully internalizing all possible interactions between all nuances. I presume not all of them may even be truly 100% fully fleshed out and explored in The Book. As to writing a compiler - even just writing a parser for C++ is famously super hard!

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

#246

Post by FRex » Wed, Jul 12, 2017, 11:34 PM UTC

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…

The call for removal of C++ is implicit or do you now say we keep extremely unsafe (in your eyes) software around and put our lives on the line? Lives and livelihoods do depend on C and C++ software in nuclear, medical, governmental, financial, etc. and somehow millions are not dying due to all this unsafe software. No software is 100% safe, even Erlang (another dear of HN but one that is enjoyed in a more civil environment than the "Go Rust, Fuck C++") is just "nine nines" reliable.

You made C++ sound as bad as Java applets or something similar. Obviously anyone saying Java applets are unsafe, bad, etc. is telling you between the verses to not run any, ever. The words you used were very strong and made it sound like everything is buggy as hell while the bugs are minor and few and far between (relatively speaking, there are lots in some places but your browser and OS is not crashing or leaking your data to hackers on a daily basis, the situation is nowhere near tragic).

Saying C and C++ are unsafe basically shitted on every programmer ever that picked them for anything important, kernel makers, browser makers, server makers, languages VM makers - all idiots, endangering people and property, writing unsafe software!

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

#247

Post by FRex » Wed, Jul 12, 2017, 11:36 PM UTC

kazinator wrote: post #239

akavel wrote: post #235

Earlier quoted context omitted.

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 ter…

That's actually why I call BS on anyone who says "C/C++" while claiming to be a (former) C++ high level user (dabbling in it doesn't count, I dabbled Java, C# and PHP but it's not even on my CV because I don't consider myself anywhere near production level in them) and try to use "C and C++" myself. See: http://www.stroustrup.com/bs_faq.html#C-slash

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

#248

Post by AnimalMuppet » Wed, Jul 12, 2017, 11:36 PM UTC

_dcwr wrote: post #244

thephyber wrote: post #216

Earlier quoted context omitted.

> I feel like the biggest reason for me not even thinking of Rust as a viable language right now is the community attitude Kinda reminds me of the "coal vs. renewable energy" feud. The first tier arguments are formed around {economics, externalized costs, existing infrastructure, base load vs intermittent load} and then second-tier arguments align around {culture, history, identity, momentum, geography, political par…

I'm an outsider and there is a war every damn time the word Rust comes up on HN. I've yet to see bashing any language to that degree in Erlang threads, Python threads, etc. Something has to be up with that. I'm not using C and C++ professionally at all so the only place Rust has to fit in is fun or potential long term professional opportunity (assuming Rust is a fair bit more widespread than now by then, otherwise C…

Up until about six months ago, I saw it a lot from Haskell proponents here on HN. But with them, it was pretty much against everybody (except maybe users of F#).

Either the most obnoxious ones left, or they learned that this was not a productive approach. It's been refreshingly quiet lately...

But I disagree that there's a war every time Rust comes up, as a general thing. Many of the Rust proponents here are quite reasonable, willing to listen, willing to explain gently. (The conversation on the current article has gotten a bit out of hand, I'll admit.)

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

#249

Post by rbehrends » Wed, Jul 12, 2017, 11:39 PM UTC

naasking wrote: post #240

rbehrends wrote: post #227

Earlier quoted context omitted.

> 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…

> 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.

I'm not comparing to C/C++. I'm comparing to other memory-safe languages.

The more general problem is that Rust cannot offer zero-cost abstractions for shared ownership as a result of how it is designed. This is the really killer issue. It's a problem for pretty much any persistent data structure, for example.

> 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.

The unsafe approach would be to do use an array representation, use indices instead of pointers, and roll your own garbage collector. Or manually remove unnecessary reference count updates whenever you can prove that they are unnecessary. Both of which cannot be easily hidden behind a safe zero-cost API.

> 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 polymorphica elaboration, which is a natural and compositional language feature, not some ad-hoc secondary language or restricted module system.

The entire Wirth family of languages qualifies, too. Or Eiffel. Or Fortran. Or Modula-3. As do more recent languages such as Nim and D. Honestly, off the top of my head I can't think of an imperative language with native compilation that doesn't and isn't totally obscure, other than Swift and Go (and even they only some of the time). Note that zero-cost abstractions need to only exist, not that they have to be the only option. Languages can and do provide both expressive constructs that come with overhead and less expressive constructs that are overhead-free. 90:10 rule, premature optimization, and all that.

In addition, parametric polymorphism cannot ever have a zero-cost abstraction (or rather, the term has no meaningful definition in this context), because you pay for it either in runtime overhead (shared generics) or code size (specialization).

I also wouldn't bring up syntactic and semantic costs; that's throwing stones while sitting inside a glass house. Rust is probably one of the worst offenders in this regard.

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

#250

Post by lossolo » Wed, Jul 12, 2017, 11:40 PM UTC

Rusky wrote: post #190

CalChris wrote: post #161

Earlier quoted context omitted.

If you are calling C or assembly and there is any sort of processor exception, you need to establish a signal() handler and you will need setjmp/longjmp to re-establish a safe stack frame. Yes, this is a C/assembly thing. But it is also a Linux/BSD/Unix thing. You really cannot call Rust a systems programming language if signal/setjmp/longjmp are not fully supported. It just goes with the territory.

Linux/BSD/Unix are hardly the only systems programming environments. I'd hesitate even to call them the majority. And for now, there are definitely ways to handle signals using libraries.

> Linux/BSD/Unix are hardly the only systems programming environments. I'd hesitate even to call them the majority.

Do you have any source that can confirm that? Because what you wrote seems really wrong. I see linuxes/bsd/unix EVERYWHERE (Android/iOS/OSX/almost all backend servers etc.)