Matt Godbolt sold me on Rust by showing me C++ • Hacker News Board

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

#371

Post by monkeyelite » Wed, May 07, 2025, 9:50 AM UTC

tsimionescu wrote: post #361

monkeyelite wrote: post #352

Earlier quoted context omitted.

> I probably really would prefer only that request to abort, not for the entire process to be torn down, This is a sign you are writing an operating system instead of using one. Your web server should be handling requests from a pool of processes - so that you get real memory isolation and can crash when there is a problem.

Even if you used a pool of processes, that's still not one process per request, and you still don't want one request crashing to tear down unrelated requests.

I question both things. I would first of all handle each request in its own process.

If there was a special case that would not work, then the design dictates that requests are not independent and there must be risk of interference (they are in the same process!)

What I definitely do not want is a bug ridden “crashable async sub task” system built in my web program.

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

#372

Post by fooker » Wed, May 07, 2025, 9:50 AM UTC

dvratil wrote: post #8

The one thing that sold me on Rust (going from C++) was that there is a single way errors are propagated: the Result type. No need to bother with exceptions, functions returning bool, functions returning 0 on success, functions returning 0 on error, functions returning -1 on error, functions returning negative errno on error, functions taking optional pointer to bool to indicate error (optionally), functions taking r…

One of the strengths of C++ is the ability to build features like this as a library, and not hardcode it into the language design.

Unless you specifically want the ‘?’ operator, you can get pretty close to this with some clever use of templates and operator overloading.

If universal function call syntax becomes standardized, this will look even more functional and elegant.

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

#373

Post by tialaramex » Wed, May 07, 2025, 9:55 AM UTC

codedokode wrote: post #141

lytedev wrote: post #101

Earlier quoted context omitted.

I'm not sure if this is what you mean, exactly, but Rust indeed catches this at compile time. https://play.rust-lang.org/?version=stable&mode=debug&editio... https://play.rust-lang.org/?version=stable&mode=debug&editio...

I meant panic if during any addition (including in runtime) an overflow occurs.

Why do you want a panic? Shift left. Overflow can be rejected at compile time for a price that you might be able to afford - generality.

Just insist that the programmer prove that overflow can't occur, and reject programs where the programmer couldn't or wouldn't do this.

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

#374

Post by pjmlp » Wed, May 07, 2025, 9:55 AM UTC

timschmidt wrote: post #368

pjmlp wrote: post #360

Earlier quoted context omitted.

Because it is counting since CFront 2.0, the first official release with industry use in UNIX systems. So that would be Rust 1.0, released in 2015, not 2006, putting it down to a decade. And the point still stands when looking at any long enough ecosystem still in use, with strong backwards compatibility, not only the language, the whole ecosystem, eventually editions alone won't make it, and just like those language…

Fair enough. I can cop to getting the CFront date wrong. Still, a decade since 1.0 is non-trivial. > eventually editions alone won't make it, and just like those languages, Rust will gain its own warts. That's possible. Though C++ hasn't had editions, or the HLIR / MIR separation, the increased strictness, wonderful tooling, or the benefit of learning from the mistakes made with C++. Noting that, it seems reasonable…

C++ editions are -std=something, people keep forgeting Rust editions are quite limited in what they actually allow in grammar and semantic changes across versions, and they don't cover standard library changes.

IDEs are wonderful tooling, maybe people should get their heads outside UNIX CLIs and MS-DOS like TUIs.

Then there is the whole ecosystem of libraries, books, SDKs and industry standards.

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

#375

Post by tsimionescu » Wed, May 07, 2025, 9:56 AM UTC

monkeyelite wrote: post #371

tsimionescu wrote: post #361

Earlier quoted context omitted.

Even if you used a pool of processes, that's still not one process per request, and you still don't want one request crashing to tear down unrelated requests.

I question both things. I would first of all handle each request in its own process. If there was a special case that would not work, then the design dictates that requests are not independent and there must be risk of interference (they are in the same process!) What I definitely do not want is a bug ridden “crashable async sub task” system built in my web program.

This is simply a wrong idea about how to write web servers. You're giving up scalability massively, only to gain a minor amount of safety - one that is virtually irrelevant in a memory safe language, which you should anyway use. The overhead of process-per-request, or even thread-per-request, is absurd if you're already using a memory safe language.

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

#376

Post by rq1 » Wed, May 07, 2025, 9:56 AM UTC

jpc0 wrote: post #244

rq1 wrote: post #154

Earlier quoted context omitted.

I don’t really understand your point there. Sound type systems are equivalent to proof systems. You can use them to design data structures where their mere eventual existence guarantee the coherence and validity of your program’s state. The basic example is “Fin n” that carries at compile time the proof that you made the necessary bounds checks at runtime or by construction that you never exceeded some bound. Some la…

My point is a Width type is usually not the sound type you are looking for. What probably wanted was a size type which is width and height. Or a dimensions type which is width and height. The problem was maybe not two arguments being confused but in reality a single thing with two elements…

Ah I see, it’s a solution too!

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

#377

Post by timschmidt » Wed, May 07, 2025, 9:58 AM UTC

d_tr wrote: post #369

timschmidt wrote: post #329

Earlier quoted context omitted.

36 years is counting from the first CFront release. Counting the same way for Rust, it's been around since 2006. It's got almost 20 years under it's belt already. edit: what's with people downvoting a straight fact?

Rust 0.1, the first public release, came out in January 2012. CFront 1.0, the first commercial release, came out in 1985. The public existence of Rust is 13 years, during which computing has not changed that much to be honest. Now compare this to the prehistory that is 1985, when CFront came out, already made for backwards compatibility with C.

I grew up with all the classic 8 bit micros, and to be honest, it doesn't feel like computing has changed at all since 1985. My workstation, while a billion times faster, is still code compatible with a Datapoint 2200 from 1970.

The memory model, interrupt model, packetized networking, digital storage, all function more or less identically.

In embedded, I still see Z80s and M68ks like nothing's changed.

I'd love to see more concrete implementations of adiabatic circuits, weird architectures like the mill, integrated FPGAs, etc. HP's The Machine effort was a rare exciting new thing until they walked back all the exciting parts. CXL seems like about the most interesting new thing in a bit.

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

#378

Post by nerpaskteipntei » Wed, May 07, 2025, 10:01 AM UTC

roelschroeven wrote: post #194

writebetterc wrote: post #4

Yes, Rust is better. Implicit numeric conversion is terrible. However, don't use atoi if you're writing C++ :-). The STL has conversion functions that will throw, so separate problem.

The numeric conversion functions in the STL are terrible. They will happily accept strings with non-numeric characters in them: they will convert "123abc" to 123 without giving an error. The std::sto* functions will also ignore leading whitespace. Yes, you can ask the std::sto* functions for the position where they stopped because of invalid characters and see if that position is the end of the string, but that is mu…

Now there is also std::from_chars function

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

#379

Post by Spivak » Wed, May 07, 2025, 10:02 AM UTC

Ygg2 wrote: post #150

jsat wrote: post #64

Earlier quoted context omitted.

Had the same thought... It's backwards that any language isn't using named parameters at this point.

Named parameters do come with a large footgun. Renaming your parameters is a breaking change. Especially if you're coming from different langs.

I guess but you're changing your user-visible API so it should be a breaking change. In languages that don't have this type/arity is all that matters and the name is just nice sugar for the implementor who doesn't have to bind them to useful names.

Even if you don't use keyword args your parameter names are still part of your API surface in Python because callers can directly name positional args. Only recently have you been able enforce unnamed positional only args as well as the opposite.

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

#380

Post by timschmidt » Wed, May 07, 2025, 10:02 AM UTC

pjmlp wrote: post #374

timschmidt wrote: post #368

Earlier quoted context omitted.

Fair enough. I can cop to getting the CFront date wrong. Still, a decade since 1.0 is non-trivial. > eventually editions alone won't make it, and just like those languages, Rust will gain its own warts. That's possible. Though C++ hasn't had editions, or the HLIR / MIR separation, the increased strictness, wonderful tooling, or the benefit of learning from the mistakes made with C++. Noting that, it seems reasonable…

C++ editions are -std=something, people keep forgeting Rust editions are quite limited in what they actually allow in grammar and semantic changes across versions, and they don't cover standard library changes. IDEs are wonderful tooling, maybe people should get their heads outside UNIX CLIs and MS-DOS like TUIs. Then there is the whole ecosystem of libraries, books, SDKs and industry standards.

I'm not sure who in your mind is forgetting that, or what the rest of your comment means to communicate.

Who are you speaking to who hasn't explored all those things in depth?

I see Rust's restrictions as a huge advantage over C++ here. Even with respect to editions. Rust has always given me the impression of a language designed from the start to be approximately what C++ is today, without the cruft, in which safety is opt-out, not opt-in. And the restrictions seem more likely to preserve that than not.

C/C++ folks seem to see Rust's restrictions as anti-features without realizing that C/C++'s lack of restriction resulted in the situation they have today.

I only maintain a few projects in each language, so I haven't run into every sort of issue for either, but that's very much how it feels to me still, several years and several projects in.