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

311–320 of 675 posts

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

#311

Post by Ygg2 »

const_cast wrote: post #268
Ygg2 wrote: post #150

Earlier quoted context omitted.

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

This only really applies to languages that don't check this at compile-time. I don't consider compile-time errors a foot gun. I mean, it should be impossible for that kind of bad code to ever get merged in most reasonable CI/CD processes.

No? This happens in any language that has keyword args.

If I delete/rename a field of a class in any statically checked language, it's going to report a compile error, and it's still a breaking change. Same thing with named arguments.

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

#313

Post by simonask »

Arnavion wrote: post #257
kllrnohj wrote: post #247

Earlier quoted context omitted.

> Rust unfortunately picked the wrong default here for the sake of convenience, along with the default of assuming a global allocator. [...] Zig for example does it right by having explicit allocators from the start Rust picked the right default for applications that run in an OS whereas Zig picked the right default for embedded. Both are good for their respective domains, neither is good at both domains. Zig's choic…

Various kind of "desktop" applications like databases and video games use custom non-global allocators - per-thread, per arena, etc - because they have specific memory allocation and usage patterns that a generic allocator does not handle as well as targeted ones can. My current $dayjob involves a "server" application that needs to run in a strict memory limit. We had to write our own allocator and collections becaus…

I don't see why you would have to write your own - there are plenty of options in the crate ecosystem, but perhaps you found them insufficient?

As a video game developer, I've found the case for custom general-purpose allocators pretty weak in practice. It's exceedingly rare that you really want complicated nonlinear data structures, such as hash maps, to use a bump-allocator. One rehash and your fixed size arena blows up completely.

95% of use cases are covered by reusing flat data structures (`Vec`, `BinaryHeap`, etc.) between frames.

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

#314

Post by mgaunard »

jchw wrote: post #209
CJefferson wrote: post #206

Earlier quoted context omitted.

I had a look. In classic C++ style, if you use *x to get the ‘expected’ value, when it’s an error object (you forgot to check first and return the error), it’s undefined behaviour! Messing up error handling isn’t hard to do, so putting undefined behaviour here feels very dangerous to me, but it is the C++ way.

The reason it works this way is there's legitimately no easy way around it. You're not guaranteed a reasonable zero value for any type, so you can't do the slightly better Go thing (defined behavior but still wrong... Not great.) and you certainly can't do the Rust thing, because... There's no pattern matching. You can't conditionally enter a branch based on the presence of a value. There really is no reasonable work…

Of course you can do the Rust thing, it's just taking a function object.

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

#315

Post by renox »

titzer wrote: post #18
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.

> Implicit numeric conversion is terrible. It's bad if it alters values (e.g. rounding). Promotion from one number representation to another (as long as it preserves values) isn't bad. This is trickier than it might seem, but Virgil has a good take on this ( https://github.com/titzer/virgil/blob/master/doc/tutorial/Nu... ). Essentially, it only implicitly promotes values in ways that don't lose numeric information an…

I disagree: when you use floats, you implicitly accept the precision loss/roundings that comes with using floats.. IMHO int to float implicit conversion is fine as long as you have explicit float to int conversion.

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

#316

Post by mgaunard »

jll29 wrote: post #252
jeroenhd wrote: post #32

Earlier quoted context omitted.

The result type does make for some great API design, but SerenityOS shows that this same paradigm also works fine in C++. That includes something similar to the ? operator, though it's closer to a raw function call. SerenityOS is the first functional OS (as in "boots on actual hardware and has a GUI") I've seen that dares question the 1970s int main() using modern C++ constructs instead, and the API is simply a lot b…

> I think c++, the language, is ready for the modern world. However, c++, the community, seems to be struck at least 20 years in the past. Good point. A language that gets updated by adding a lot of features is DIVERGING from a community that has mostly people that still use a lot of the C baggage in C++, and only a few folks that use a lot of template abstraction at the other end of the spectrum. Since in larger sys…

A lot of people using C++ don't actually use any libraries. I've observed the opposite with Rust.

People choose C++ because it's a flexible language that lets you do whatever you want. Meanwhile Rust is a constrained and opinionated thing that only works if you do things "the right way".

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

#317

Post by eptcyka »

aw1621107 wrote: post #287
socalgal2 wrote: post #256

I already hated C++ (having written 100s of thousands of lines of it in games and at FAANG) I'd be curious to know what if any true fixes are coming down the line. This talk: "To Int or to Uint, This is the Question - Alex Dathskovsky - CppCon 2024" https://www.youtube.com/watch?v=pnaZ0x9Mmm0 Seems to make it clear C++ is just broken. That said, and I wish he'd covered this, he didn't mention if the flags he brings u…

> speaking of which, according to another C++ talk, something like 60% of rust crates are dependent on unsafe rust. It's probably not the source of the stats you had in mind since it's discussing something slightly different, but the Rust Foundation built a tool called Painter [0] for this kind of analysis. According to that [1]: > As of May 2024, there are about 145,000 crates; of which, approximately 127,000 contai…

Memory allocation is unsafe, so any container in the stdlib end up using unsafe at some point. This does not mean that safe Rust is useless without unsafe - the utility of Rust is that it allows one to create sage interfaces around an unsafe construct.

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

#318

Post by eptcyka »

Ygg2 wrote: post #307
choeger wrote: post #295

All this has been known in the PL design community for decades if not half a century by now. Two things are incredibly frustrating when it comes to safety in software engineering: 1. The arrogance that "practitioners" have against "theorists" (everyone with a PhD in programming languages) 2. The slowness of the adoption of well-tested and thoroughly researched language concepts (think of Haskell type classes, aka, Ru…

> I like that Rust can pick good concepts and design coherent language from them without inventing its own "pragmatic" solution that breaks horribly in some use cases that some "practitioners" deem "too theoretical." I've thought Rust picked some pretty nifty middle ground. On one side, it's not mindfucking unsafe like C. It picked to remove a set of problems like memory safety. On the other side, Rust didn't go for…

As per the article, Rust has benefits beyond the ones afforded by the borrow checker.

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

#319

Post by simonask »

const_cast wrote: post #267
cratermoon wrote: post #255

Earlier quoted context omitted.

How can you simultaneously call cpp a mature language with mature tooling and acknowledge that there's no working package manager used by any "serious" project?

Package managers per language are a (relatively) new endeavor. The oldest language I can think of that widely adopted it was Perl. Although, perl was quite ahead of it's time in a lot of ways, and php undid some the work of perl and went back to popularizing include type dependencies instead of formal modules with a package manager. C++ "gets away" with it because of templates. Many (most?) libraries are mostly templ…

It's a relatively new endeavor, but it's also a requirement in 2025 if you want to be portable. The Linux ecosystem was focusing on installing dependencies system-wide for decades (that's how traditional `./configure.sh` expects things to work), and this approach is just inferior in so many ways.

The shenanigans people get into with CMake, Conan, vcpkg, and so on is a patchwork of nightmares and a huge time sink compared to superior solutions that people have gotten used to in other languages, including Rust.

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

#320

Post by simonask »

tdiff wrote: post #273
cratermoon wrote: post #255

Earlier quoted context omitted.

How can you simultaneously call cpp a mature language with mature tooling and acknowledge that there's no working package manager used by any "serious" project?

Because cpp is not meant for "rapid prototyping" involving importing half of github with single command. And the reality is that it works.

Works for whom?

C++ build systems are notoriously brittle. When porting a project to a new platform, you're never just porting the code, you are also porting your build system. Every single project is bespoke in some way, sometimes because of taste, but most of the time because of necessity.

It works because people spend a huge amount of time to make it work.

Post reply on HN