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

Matt Godbolt sold me on Rust by showing me C++

collabora.com

Post reply on HN
Print view View original

551–560 of 675 posts

Re: Matt Godbolt sold me on Rust by showing me C++

#551

Post by steveklabnik »

spyrja wrote: post #546
pjmlp wrote: post #285

Earlier quoted context omitted.

Yes, from safety point of view Rust is much better option, however from the ecosystems I care about (language runtimes and GPU coding), both professionally and as hobby, C++ is the systems language to go, using Rust in such contexts would require me to introduce extra layers and do yak shaving instead of the actual problem that I want to code for.

Well, precisely. Such is the price of "general-purpose safety". The biggest irony IMO is that the security features of Rust are so often skirted in the name of speed, efficiency, etc, with the end result being a program which isn't much more secure than its C++ equivalent. ¯\_(ツ)_/¯

> The biggest irony IMO is that the security features of Rust are so often skirted in the name of speed, efficiency, etc, with the end result being a program which isn't much more secure than its C++ equivalent.

Citation needed. The empiric evidence I’ve seen has shown the opposite.

Re: Matt Godbolt sold me on Rust by showing me C++

#552

Post by ordu »

monkeyelite wrote: post #547
ordu wrote: post #530

Earlier quoted context omitted.

> Threads and processes do the same amount of context switching. Yes, therefore real webservers use a limited amount of threads/processes (in the same ballpark as a number of CPU cores). Modern approach is to use green threads which are really cheap to switch, it is like store registers, read registers and jmp. > The main cost is memory. The main cost is scheduling, not switching per se. Preemptive multitasking needs…

> The main cost is scheduling, not switching per se. Preemptive multitasking needs to deal with priorities to not waste time, and algorithms that do it The person I am having a conversation with is advocating for threads instead of processes. How do you think threads work? > Modern approach is to use green threads which are really cheap to switch, it is like store registers, read registers and jmp. That’s certainly t…

> The person I am having a conversation with is advocating for threads instead of processes. How do you think threads work?

Are they? I looked back and I've found this quote of them: "The overhead of process-per-request, or even thread-per-request, is absurd if you're already using a memory safe language." Doesn't seem as an advocacy for thread-per-request to me.

> As I said at the beginning this approach is making a mini operating system with more bugs and less security rather than leveraging the capabilities of your operating system.

Lets look at Apache for example. It starts a few processes and/or threads, but then each thread deals with a lot of connections. The threads Apache starts are for spreading work over several CPUs and maybe to overcome some limits of select/poll/epoll. The main approach is to track a state of a connection, and when something happens on a socket, Apache find the state of the connection and deals with events on the socket. Then it stores the new state and moves to deal with other sockets in the same manner.

It is like green threads but without green threads. Green threads streamlines all this state keeping by allowing each connection to have it's own stack. And I'd say it is easier to do right than to write a finite automata for HTTP/HTTPS.

> Once again, im waiting to here about your experience of maxing out processes and after that having to switch to green threads.

Oh, I didn't. A long long time ago I was reading stuff on networking. All of it was in one opinion: 10k kernel tasks maybe a tolerable solution, but 100k is bad. IIRC Apache had a document describing its internal architecture and explaining why it is as it is.

So I wouldn't even try to start thousands of threads. I mean I tried to start 1000s of processes when I was young and learned about fork-bombs, and this experience confirmed it for me, that 1000s of processes is not a really good idea.

Moreover I completely agree with them: if you use a memory-safe language, then it is strange to pay costs for preemptive multitasking just to have separate virtual address spaces. I mean, it will be better to get a virtual machine with JIT compiler, and run code for different connection on different instances of a virtual machine. O(1) complexity of cooperative switching will beat O(N) complexity of preemptive switching. To my mind hardware memory management is overrated.

Re: Matt Godbolt sold me on Rust by showing me C++

#553

Post by spyrja »

steveklabnik wrote: post #551
spyrja wrote: post #546

Earlier quoted context omitted.

Well, precisely. Such is the price of "general-purpose safety". The biggest irony IMO is that the security features of Rust are so often skirted in the name of speed, efficiency, etc, with the end result being a program which isn't much more secure than its C++ equivalent. ¯\_(ツ)_/¯

> The biggest irony IMO is that the security features of Rust are so often skirted in the name of speed, efficiency, etc, with the end result being a program which isn't much more secure than its C++ equivalent. Citation needed. The empiric evidence I’ve seen has shown the opposite.

Overall it does indeed seem to be the case for roughly 25% of Rust crates:

https://rustfoundation.org/media/unsafe-rust-in-the-wild-not...

https://thenewstack.io/unsafe-rust-in-the-wild/

https://github.com/sslab-gatech/Rudra/blob/master/rudra-sosp...

https://internals.rust-lang.org/t/canvas-unsafe-code-in-the-...

Again, not a criticism of the language itself per se, and certainly not trying to imply that all Rust programmers go around writing unsafe code all day long. It's just kind of funny to me that it is touted as being so much more safe than C++ when the reality is that at least some of those features are in fact disabled for one reason or another in real-world programs.

Re: Matt Godbolt sold me on Rust by showing me C++

#554

Post by uecker »

bigstrat2003 wrote: post #504
uecker wrote: post #304

Earlier quoted context omitted.

It is fine, there is just not much Rust safety advantage left then. Also in C/C++ the errors do not usually occur when using a nicely defined API, but when doing the low-level gnarly stuff and getting it wrong. As said before, I think there is some advantage of Rust having a safe and unsafe subset, but is is nowhere as big as people claim it is.

> It is fine, there is just not much Rust safety advantage left then. There's exactly as much as there was before though. The entire point of the Rust safety paradigm is that you can guarantee that unsafe code is confined to only where it is needed. Nobody ever promised "you will never have to write unsafe code", because that would be clearly unfeasible for the systems programming domain Rust is trying to work in. I…

The fallacy is believing that C / C++ code is 100% unsafe. Yes, Rust propaganda repeats this over and over but a good abstraction in C / C++ will also give you good safety properties. The safe Rust code over gnarly unsafe Rust code is only a little bit better than a nice C / C++ abstraction over gnarly code.

Re: Matt Godbolt sold me on Rust by showing me C++

#555

Post by steveklabnik »

spyrja wrote: post #553
steveklabnik wrote: post #551

Earlier quoted context omitted.

> The biggest irony IMO is that the security features of Rust are so often skirted in the name of speed, efficiency, etc, with the end result being a program which isn't much more secure than its C++ equivalent. Citation needed. The empiric evidence I’ve seen has shown the opposite.

Overall it does indeed seem to be the case for roughly 25% of Rust crates: https://rustfoundation.org/media/unsafe-rust-in-the-wild-not... https://thenewstack.io/unsafe-rust-in-the-wild/ https://github.com/sslab-gatech/Rudra/blob/master/rudra-sosp... https://internals.rust-lang.org/t/canvas-unsafe-code-in-the-... Again, not a criticism of the language itself per se, and certainly not trying to imply that all Rust pro…

> Most of these Unsafe Rust uses are calls into existing third-party non-Rust language code or libraries

This is very different than

> in the name of speed, efficiency, etc

And also does not demonstrate that

> the end result being a program which isn't much more secure than its C++ equivalent.

At all.

Re: Matt Godbolt sold me on Rust by showing me C++

#556

Post by uecker »

sunshowers wrote: post #508
uecker wrote: post #304

Earlier quoted context omitted.

It is fine, there is just not much Rust safety advantage left then. Also in C/C++ the errors do not usually occur when using a nicely defined API, but when doing the low-level gnarly stuff and getting it wrong. As said before, I think there is some advantage of Rust having a safe and unsafe subset, but is is nowhere as big as people claim it is.

Is there a safety advantage to using Java given that the HotSpot JVM is written in C++? All safe code is built on a foundation of unsafe code.

Sure, but the point is that you can also build reasonably safe abstractions in C / C++.

Re: Matt Godbolt sold me on Rust by showing me C++

#557

Post by zelphirkalt »

tmoertel wrote: post #427
andrepd wrote: post #381

Earlier quoted context omitted.

I don't think currying is that big a deal, it's just syntactic sugar that might or might not make things easier to read, unlike ADTs or closures which are important core concepts. I'd love to have a syntax like { foo(%1, bar) } standing for |x| { foo(x, bar) } though. I'm not aware of any language that has this!

Mathematica has this: In[1]: Map((1 + #1)&, {a, b, c}) Out[1]: {a + 1, b + 1, c + 1} See https://reference.wolfram.com/language/ref/Function.html.en for the full story.

What is that & doing there? I thought it looks neat, but then that & ...

Re: Matt Godbolt sold me on Rust by showing me C++

#558

Post by spyrja »

steveklabnik wrote: post #555
spyrja wrote: post #553

Earlier quoted context omitted.

Overall it does indeed seem to be the case for roughly 25% of Rust crates: https://rustfoundation.org/media/unsafe-rust-in-the-wild-not... https://thenewstack.io/unsafe-rust-in-the-wild/ https://github.com/sslab-gatech/Rudra/blob/master/rudra-sosp... https://internals.rust-lang.org/t/canvas-unsafe-code-in-the-... Again, not a criticism of the language itself per se, and certainly not trying to imply that all Rust pro…

> Most of these Unsafe Rust uses are calls into existing third-party non-Rust language code or libraries This is very different than > in the name of speed, efficiency, etc And also does not demonstrate that > the end result being a program which isn't much more secure than its C++ equivalent. At all.

What are you trying to say? C++ can be just as safe as Rust. The latter is just easier to use, especially in terms of working as a team of developers insomuch as the safety-nets are by default in place. Once again, C++ is powerful but comes with just as many footguns as C (in fact, more) and so requires a bit more finesse, experience, and skill to work with safely. Otherwise it can encapsulate pretty much any functionality you could possibly imagine, and that includes safety features. Checked memory accesses, managed memory, well-behaved arithmetic, all of that and more can be codified as a set of objects and interfaces. I started out in assembler, worked up to C, then finally on to C++ where I actually found it quite easy to write safe programs by just sticking to a strict set of guidelines. And that works. I have code that has been running almost continuously for over a decade without a hitch, and I credit that to good programming practices.

Re: Matt Godbolt sold me on Rust by showing me C++

#559

Post by int_19h »

patrick451 wrote: post #543
jchw wrote: post #520

Earlier quoted context omitted.

> Divide by zero must be undefined behavior in any performant language. On x86 you either have a if before running the divide (which of course in some cases the compiler can optimize out, but only if it can determine the value is not zero); or you the CPU will trap into the OS - different OSes handle this in different ways, but most not in a while that makes it possible to figure out where you were and thus do someth…

> What if you really do need "unsafe" division? Well, that is possible, with unchecked_div. Most people do not need unchecked_div. If you think you do but you haven't benchmarked yet, you do not. It doesn't get any simpler than that. This attitude is why modern software is dogshit slow. People make this "if you haven't benchmarked, it doesn't matter" argument thousands of times and the result is that every program I…

Modern software is dogshit slow because it's a pile of JS dependencies twenty layers deep.

Checked arithmetic is plenty fast. And as for safety vs performance, quickly computing the incorrect result is strictly less useful than slowly computing the correct one.

Re: Matt Godbolt sold me on Rust by showing me C++

#560

Post by int_19h »

pdimitar wrote: post #107
tcfhgj wrote: post #91

Earlier quoted context omitted.

would you consider panics acceptable when you think it cannot panic in practice? e.g. unwraping/expecting a value for a key in a map when you inserted that value before and know it hasn't been removed? you could have a panic though, if you wrongly make assumptions

I don't speak for anyone else but I'm not using `unwrap` and `expect`. I understand the scenario you outlined but I've accepted it as a compromise and will `match` on a map's fetching function and will have an `Err` branch. I will fight against program aborts as hard as I possibly can. I don't mind boilerplate to be the price paid and will provide detailed error messages even in such obscure error branches. Again, sp…

So what do you do in the error branch if something like out-of-bounds index happens? Wrap and propagate the error to the caller?
Post reply on HN