Live data from Hacker News

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

collabora.com

401–410 of 675 posts

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

#401

I always enjoy reading articles like this. But the truth is, having written several 100s of KLOC in C++ (i.e., not an enormous amount but certainly my fair share) I just almost never have problems with this sort accidental conversion in practice. Perhaps it might trip me up occasionally, but will be noticed by literally just running the code once. Yes, that is an extra hurdle to trip over and resolve but that is triv…

I had a friend who noticed that people were often mixing up the arguments to some std constructor (I think it was string with a char and other integer argument getting swapped.) He searched across Google's codebase and found many (I don't remember the exact number) cases of this, many that he could confirm to be real bugs. He spent months fixing them and I think eventually got some check added to prevent this in the future.

So this definitely isn't some theoretical problem. I wouldn't even be surprised if you had made this mistake just hadn't noticed.

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

#402
post #369

Earlier quoted context omitted.

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

Today a byte is 8 bits. That was not always the case back then, for example.

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

#403

Earlier quoted context omitted.

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.

> You're giving up scalability massively you’re vastly over estimating the overhead of processes and number of simultaneous web connections. > only to gain a minor amount of safety What you’re telling me is performance (memory?) is such a high priority you’re willing to make correctness and security tradeoffs. And I’m saying thats ok, one of those is crashing might bring down more than one request. > one that is virt…

Please find one web server being actively developed using one process per request.

Handling thousands of concurrent requests is table stakes for a simple web server. Handling thousands of concurrent processes is beyond most OSs. The context switching overhead alone would consume much of the CPU of the system. Even hundreds of processes will mean a good fraction of the CPU being spent solely on context switching - which is a terrible place to be.

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

#404
post #51

It's a shame Rust doesn't have keyword arguments or named tuples to make handling some of these things easier without Args/Options structs boilerplate.

I work all day in Swift (which makes you go out of your way to omit argument labels) and I'm surprised they aren't more common.

Yeah, this is one of the few things that I love about Swift. I think it gets it exactly right that keyword arguments should be the default and you can opt out in cases where the keyword is really unnecessary.

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

#405
post #402

Earlier quoted context omitted.

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

Today a byte is 8 bits. That was not always the case back then, for example.

> I grew up with all the classic 8 bit micros

Meaning that all the machines I've ever cared about have had 8 bit bytes. The TI-99/4A, TRS-80, Commodore 64 and 128, Tandy 1000 8088, Apple ][, Macintosh Classic, etc.

Many were launched in the late 70s. By 1985 we were well into the era of PC compatibles.

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

#406
post #357

Earlier quoted context omitted.

Sure, but it is pragmatic in other ways as well :) It takes ADT, but not function currying, and so on.

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!

Powershell has this, why do you like this?

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

#407
The implicit problem here (pun intended) in the given examples are implicitness vs. explicitness.

Rust chose (intentionally or otherwise) to do the opposite of the many things that C++ does, because C++ does it wrong. And C++ does it wrong because we didn't know any better at the time, and the world, pre-internet, was much less connected. Someone had to do it first (or first-ish).

The main thing I like about Rust is the tooling. C++ is death by a thousand build systems and sanitizers.

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

#408
post #24
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…

And panics?

Those are generally used as asserts, not control flow / error handling.

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

#409

Earlier quoted context omitted.

Absolutely, the compile times are the biggest drawback IMO. Everywhere I've been that built large systems in Rust eventually ends up spending a good amount of dev time trying to get CI/CD pipeline times to something sane. Besides developer productivity it can be an issue when you need a critical fix to go out quickly and your pipelines take 60+ minutes.

If you have the money to throw at it, you can get a long way optimising CI pipelines just by throwing faster hardware at it. The sort of server you could rent for ~$150/month might easily be ~5x faster than your typical Github Actions hosted runner.

Besides faster hardware, one of the main features (and drawbacks) you get with self-hosted runners is the option to break through build isolation, and have performant caches between builds.

With many other build systems I'd be hesitant to do that, but since Cargo is very good about what to rebuild for incremental builds, keeping the cache around is a huge speed boost.

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

#410

I always enjoy reading articles like this. But the truth is, having written several 100s of KLOC in C++ (i.e., not an enormous amount but certainly my fair share) I just almost never have problems with this sort accidental conversion in practice. Perhaps it might trip me up occasionally, but will be noticed by literally just running the code once. Yes, that is an extra hurdle to trip over and resolve but that is triv…

I had a friend who noticed that people were often mixing up the arguments to some std constructor (I think it was string with a char and other integer argument getting swapped.) He searched across Google's codebase and found many (I don't remember the exact number) cases of this, many that he could confirm to be real bugs. He spent months fixing them and I think eventually got some check added to prevent this in the…

I understand this concern, but at the same time it's not hard to write clang-query statements for the ones you care about. Sometimes it is even a regex! And it's not too expensive to upstream universally relevant checks to clang-tidy.

The main problem is that too many C++ engineers don't do any of that. They have some sort of learned helplessness when it comes to tooling. Rust for now seems to have core engineers in place that will do this sort of on behalf of everyone else. Language design aside, if it can find a way to sustain that kind of solid engineering, it will be hard to argue against.

Post reply on HN