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

201–210 of 300 posts

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

#201

Post by sidlls »

jacquesm wrote: post #189
sidlls wrote: post #177

Earlier quoted context omitted.

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.

It's actually harming Rust. And not just a little bit.

The official Rust community isn't helping itself, either, here. If they were even a little bit as eager to step on lazy "C is bad" comments as to point out how safe Rust is it might help. Lazy reasoning about competitor languages isn't helpful because it inhibits the ability to effectively tout Rust's benefits.

But I've basically stopped commenting in Rust threads. There's too much "not even wrong" as regards C and C++ to be bothered with.

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

#202

Post by rbehrends »

naasking wrote: post #199
rbehrends wrote: post #156

Earlier quoted context omitted.

Rather than answering this question directly, let me perhaps explain why Rust is getting so much pushback. With the exception of dynamic memory, virtually all high-level languages that aren't called C/C++ are memory-safe. Memory-safety is not a new feature. Inherent memory- unsafety was a "feature" introduced by C and its immediate ancestors (and later perpetuated by C++) in order to deal with the performance limitat…

> So, in our experience, Rust doesn't really offer us much except an alternative to automatic memory management that imposes a significant cognitive burden. And zero runtime overhead. > If you have this kind of programming background, the tradeoffs that Rust offers are not at all attractive. I think you underestimate the attractiveness of zero overhead abstractions.

> And zero runtime overhead.

Please show me an implementation of binary decision diagrams [1] (ideally multi-threaded) where Rust has zero runtime overhead.

Rust has zero runtime overhead only in some cases.

[1] https://en.wikipedia.org/wiki/Binary_decision_diagram

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

#203

Post by cyphar »

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…

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 issues. Rust does solve many of these problems, and you can prove it does so mathematically.

I understand why people don't like the use of the term "safe" because it feels like a value judgement. But I think people's egos really should be a bit less fragile when discussing language choices.

> Then just delete your entire OS or at least your browser, don't force yourself to use C and C++ software.

With RedoxOS you actually could do that in the near future once it supports some more hardware. The kernel and entire userland (with graphics) is written in Rust. And they did it in 2 years. If nothing else you have to admit that there are some very talented engineers using Rust.

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

#204

Post by Const-me »

Writing manually-vectorized SIMD code is the only way to approach advertised performance on any modern CPU.

While there’s _some_ SIMD support in Rust nightly builds (but not in Rust stable), it’s just not good enough. For one thing, Intel only supports their intrinsics for C (C++ also gets that ‘coz compatibility) and Fortran. Another thing, Rust strong type-safety concept complicates SIMD code, especially when the code does integer math. These __m128i / __m256i / __m512i registers are often treated as different data types by even consecutive instructions.

While Rust might be good enough for some areas, performance critical CPU bound code is not one of them.

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

#205

Post by steveklabnik »

Const-me wrote: post #204

Writing manually-vectorized SIMD code is the only way to approach advertised performance on any modern CPU. While there’s _some_ SIMD support in Rust nightly builds (but not in Rust stable), it’s just not good enough. For one thing, Intel only supports their intrinsics for C (C++ also gets that ‘coz compatibility) and Fortran. Another thing, Rust strong type-safety concept complicates SIMD code, especially when the c…

Yeah, SIMD is being very actively worked on; until then, you can link in an external assembly file, but that's not exactly the best UX.

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

#206

Post by pcwalton »

blub wrote: post #181
pcwalton wrote: post #137

Earlier quoted context omitted.

I actually feel that C++ memory management is less safe than that of C, because smart pointers provide the same opportunity for use-after-free while being much more opaque about when the destruction occurs. The rules about when destructors of temporaries are called in the evaluation of expressions are subtle.

I'd be happy to discuss an example, because right now the idea that smart pointers are opaque about destruction is unfortunately too abstract for me to give a helpful reply to.

Consider situations like this: https://stackoverflow.com/questions/17362673/temporary-lifet...

It's undefined behavior, despite not calling free anywhere. Replace with std::string and it could be use after free. In C, UAF wouldn't happen that silently for heap memory.

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

#207

Post by pcwalton »

nine_k wrote: post #191
pcwalton wrote: post #137

Earlier quoted context omitted.

I actually feel that C++ memory management is less safe than that of C, because smart pointers provide the same opportunity for use-after-free while being much more opaque about when the destruction occurs. The rules about when destructors of temporaries are called in the evaluation of expressions are subtle.

Do you even explicitly free() a RAII-managed pointer? If yes, why?

No, and that's the problem. Free can effectively be called invisibly, causing UAF.

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

#208

Post by jeffdavis »

falcolas wrote: post #19

Sigh. This again. Not all security vulnerabilities are due to pointer arithmetic or out of bounds execution or pick-your-rust-is-better-idiom. Heartbleed is a great example. It wasn't caused by an error with how C handles memory or strings or anything else. It was caused by failing to validate untrusted input. Rust isn't going to help you with that. Could the affected parts be re-written in a way where the boundary c…

Haskell (and any other GC language) has big runtime requirements that rust does not. It's not just about the ABI.

Your argument does apply to Ada, but freeing from the heap in Ada is unsafe, which has made it difficult to use in a safe way for a lot of cases.

Rust really does make an advance in this regard: safety, and no significant runtime requirements.

D and modern C++ might work for disciplined teams, but seem a few steps behind rust safety-wise.

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

#209

Post by steveklabnik »

cyphar wrote: post #198
steveklabnik wrote: post #91

Earlier quoted context omitted.

> As far as I can tell there's no major package manager accepting or even ready to accept programs written in Rust yet. Am I misinformed? At least Debian, Fedora, Arch, and Gentoo have rustc and cargo in their repositories. Oh and Alpine, recently. FreeBSD (IIRC) has it in ports. In the not-too-distant future, there's a pretty important package that will require Rust: Firefox. HEAD already does today.

But you do realise that pressuring distributions in that way (when there are still issues with integrating cargo and crates into our existing build systems) won't result in Rust being properly supported right? There will be some hack to get Rust to work "well enough" to build Firefox, and if someone wants to start packaging more Rust stuff then all of the work would either need to be redone or started from scratch. I…

All I can really say is, we're interested, willing, and actively working with distro maintainers on fixing their issues. It's something we care about.

It is just one of many things on our plate, though.

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

#210

Post by naasking »

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

> Some badass below even just said that "writing C++ code longer than a few lines without UB is humanly impossible". Apparently all these FUBAR C/C++ systems (Linux and Windows kernels, all? web browsers, LLVM that the dear rust uses, device drivers, web servers, router software, VMs of Lua, Python, C#, Java, ..., etc.) work well enough to transfer that kind of garbage to me.

Yes, they work well enough, until they don't, because realistically, they are rife with dependencies on undefined behaviour. Linux can only be compiled with gcc last I checked.

Post reply on HN