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

601–610 of 675 posts

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

#601

Post by pjmlp »

simonask wrote: post #319
const_cast wrote: post #267

Earlier quoted context omitted.

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

Try to use cargo in a polyglot build and you will get into shenanigans as well, and I have already seen enough clever build.rs files.

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

#602

Post by pjmlp »

simonask wrote: post #320
tdiff wrote: post #273

Earlier quoted context omitted.

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.

For starters it works for Rust, given that its compiler depends on LLVM, and eventually GCC as well.

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

#603

Post by pjmlp »

bunderbunder wrote: post #477

This is actually the point where Rust starts to frustrate me a little bit. Not because Rust is doing anything wrong here, but because the first well-known language to really get some of these things right also happens to be a fairly low-level systems language with manual memory management. A lot of my colleagues seem to primarily be falling in love with Rust because it's doing a good job at some basic things that hav…

Personally I am more of an D, Delphi, Modula-3, Oberon kind of systems language kind of person, and currently I would say C# with Native AOT is good enough for me.

Eventually Java with Valhala + GraalVM, if it ever comes to be.

I would already be happy with Go, if it wasn't for their anti-intelectual attitude regarding programming language design.

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

#604

Post by zelphirkalt »

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…

C++ is _getting_ modules now? You must be kidding. How can this language, that adds more and more and more features every couple of years _still_ not have one of the most fundamental way to modularize code, splitting it into semantic units? Like ... what?! I did not think C++ would be that bad when it comes to foundational aspects of a programming language. This must be the result of silly obsession with OOP. The typical misuse of "we have classes, we don't need modules!". What other explanation could there possibly be for lacking such basic means of code organization.

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

#605

Post by gpderetta »

alpaca128 wrote: post #544
gpderetta wrote: post #175

Earlier quoted context omitted.

Are there rust projects that are within orders of magnitude of Chromium?

Almost a quarter of Firefox' compiled code is Rust: https://4e6.github.io/firefox-lang-stats/

Nice. That's more than I expected. What's the compilation time compared to, say, the c++ portion?

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

#606

Post by nextaccountic »

monkeyelite wrote: post #353
nextaccountic wrote: post #246

Earlier quoted context omitted.

Obviously yes. For the same reason it's acceptable that myvec[i] panics (it will panic if i is out of bounds - but you already figured out that i is in bounds) and a / b panic for a and b integers (it will panic if b is zero, but if your code is not buggy you already tested if b is zero prior to dividing right?) Panic is absolutely fine for bugs, and it's indeed what should happen when code is buggy. That's because b…

> Note that if panic=unwind you have the opportunity to catch the panic. And now your language has exceptions - which break control flow and make reasoning about a program very difficult - and hard to optimize for a compiler.

Yeah, but this isn't the only bad thing about unwinding. Much worse than just catching panics is the fact that a panic in a thread takes down only that thread (except if it is in the main thread). If your program is multithreaded, panic=unwind makes it much harder to understand how it reacts to errors, unless you take measures to shut down the program if any thread panic (which again, requires catch_unwind if you have unwinding). Also: that's why locks in Rust have poisoning, they exist so that panics propagate between threads: if a thread panics while holding a lock, any other thread attempting to acquire this lock will panic too (which is better than a deadlock for sure)

And that's why my programs get compiled with panic=abort, that makes panics just quit the program, with no ability to catch them, and no programs in zombie states where some threads panicked and others keep going on.

But see, catch_panic is an escape hatch. It's not meant to be used as a general error handling mechanism and even when doing FFI, Rust code typically converts exceptions in other languages into Results (at a performance cost, but who cares). But Rust needs a escape right, it is a low level language.

And there is at least one case where the catch_unwind is fully warranted: when you have an async web server with multiple concurrent requests and you need panics to take down only a single request, and not the whole server (that would be a DoS vector). If that weren't possible, then async Rust couldn't have feature parity with sync Rust (which uses a thread-per-request model, and where panics kill the thread corresponding to the request)

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

#607

Post by int_19h »

simonask wrote: post #595
int_19h wrote: post #569

Earlier quoted context omitted.

I think that explicit casts really ought to be discounted, since if you're writing one, you are simply getting what you have asked for. This would be like saying that e.g. Modula-2 is weakly typed because it has bitcast. That aside, the only remaining footgun in C++ is the implicit numeric conversions. What else did you have in mind?

I mean, the default behavior of single-argument constructors in C++ is implicit conversion. You have to opt into explicit conversions using the `explicit` keyword on constructors and assignment operators. Then you have all the shenanigans around placement-new and vtables. If it isn't downright weak, it's also not particularly strong.

The issue with constructors is a real one, yeah. Although forcing `explicit` on single-argument constructors is a single linter rule (which is a good idea for this exact reason...).

OTOH placement-new is pretty much impossible to use by accident. If used intentionally, I don't see it as being any different from an explicit cast - again, you get what you signed up for.

Interestingly in some ways C++ is arguably more typesafe than languages like Java or C#, given how it handles dynamic type of object during construction & destruction...

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

#608

Post by divan »

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…

Convention-wise Go is even better. On the one hand, there is zero magic in error handling ("Errors are values" and interface type 'error' is nothing special), on the other hand it's kind of a convention (slightly enforced by linters) that functions that return errors use this type and it's the last return parameter.

Nothing prevents people from doing their own way (error int codes, bool handling, Result types, etc, panic), but it's just an easiest way that handles well 99% of the error handling cases, so it sticks and gives a nice feeling of predictability of error handling patterns in Go codebases.

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

#609

Post by juliangmp »

> No luck! Both clang 19 and gcc 14 will take that and not complain - even with -std=c++23 -Wall -Wextra -Wpedantic, which I use for all of the C++ code in this article!

I keep a list of "additional" error codes for my work with GCC and its at least two dozen parameters. The fact that some of these aren't the default is outrageous to me. And Wconversion is one of those things that seemingly no one uses so every open source library I include gives me those errors.

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

#610

Post by juliangmp »

thawawaycold wrote: post #435
juliangmp wrote: post #90

Earlier quoted context omitted.

I can't speak for a bigger rust project, but my experience with C++ (mostly with cmake) is so awful that I don't think it can get any worse. Like with any bigger C++ project there's like 3 build tools, two different packaging systems and likely one or even multiple code generators.

that does not answer at all OP's question.

"It can't get any worse than C++" That's my response. So just use rust. In the long run you'll save time as well.
Post reply on HN