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

171–180 of 675 posts

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

#171

Post by skrtskrt »

dvt wrote: post #15
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…

Maybe contrarian, but imo the `Result` type, while kind of nice, still suffers from plenty of annoyances, including sometimes not working with the (manpages-approved) `dyn Error`, sometimes having to `into()` weird library errors that don't propagate properly, or worse: `map_err()` them; I mean, at this point, the `anyhow` crate is basically mandatory from an ergonomics standpoint in every Rust project I start. Also,…

A couple of those annoyances are just library developers being too lazy to give informative error types which is far from a Rust-specific problem

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

#172

Post by Arnavion »

smj-edison wrote: post #138
Arnavion wrote: post #121

Earlier quoted context omitted.

>many functions allocate memory and what are they supposed to do when there is no memory left? Return an AllocationError. Rust unfortunately picked the wrong default here for the sake of convenience, along with the default of assuming a global allocator. It's now trying to add in explicit allocators and allocation failure handling (A:Allocator type param) at the cost of splitting the ecosystem (all third-party code,…

> Rust unfortunately picked the wrong default here I partially disagree with this. Using Zig style allocators doesn't really fit with Rust ergonomics, as it would require pretty extensive lifetime annotations. With no_std, you absolutely can roll your own allocation styles, at the price of more manual lifetime annotations. I do hope though that some library comes along that allows for Zig style collections, with the…

Explicit allocators do work with Rust, as evidenced by them already working for libstd's types, as I said. The mistake was to not have them from day one which has caused most code to assume GlobalAlloc.

As long as the type is generic on the allocator, the lifetimes of the allocator don't appear in the type. So eg if your allocator is using a stack array in main then your allocator happens to be backed by `&'a [MaybeUninit]`, but things like Vec instantiated with A = YourAllocator don't need to be concerned with 'a themselves.

Eg: https://play.rust-lang.org/?version=nightly&mode=debug&editi... do_something_with doesn't need to have any lifetimes from the allocator.

If by Zig-style allocators you specifically mean type-erased allocators, as a way to not have to parameterize everything on A:Allocator, then yes the equivalent in Rust would be a &'a dyn Allocator that has an infectious 'a lifetime parameter instead. Given the choice between an infectious type parameter and infectious lifetime parameter I'd take the former.

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

#173

Post by sophacles »

jsat wrote: post #66

I see an article about how strict typing is better, but what would really be nice here is named parameters. I never want to go back to anonymous parameters.

Why? In 2025 we have tooling available for most every editor that will annotate that information into the display without needing them present in the file. When I autocomplete a function name, all the parameters are there for me to fill in, and annotated into the display afterwards. It seems like an unnecessary step to reify it and force the bytes to be present in the the saved file.

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

#174

Post by bluGill »

yodsanklai wrote: post #137
thrwyexecbrain wrote: post #132

The C++ code I write these days is actually pretty similar to Rust: everything is explicit, lots of strong types, very simple and clear lifetimes (arenas, pools), non-owning handles instead of pointers. The only difference in practice is that the build systems are different and that the Rust compiler is more helpful (both in catching bugs and reporting errors). Neither a huge deal if you have a proper build and testi…

> The C++ code I write these days Meaning you're in a context where you have control on the C++ code you get to write. In my company, lots of people get to update code without strict guidelines. As a result, the code is going to be complex. I'd rather have a simpler and more restrictive language and I'll always favor Rust projects to C++ ones.

That is easy to say today, but I guarantee in 30 year Rust will have rough edges too. People always want some new feature and eventually one comes in that cannot be accommodated nicely.

Of course it will probably not be as bad as C++, but still it will be complex and people will be looking for a simpler language.

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

#175

Post by gpderetta »

cmrdporcupine wrote: post #63
90s_dev wrote: post #53

Earlier quoted context omitted.

I like so much about Rust. But I hear compiling is too slow. Is it a serious problem in practice?

I worked in the chromium C++ source tree for years and compiling there was orders of magnitude slower than any Rust source tree I've worked in so far. Granted, there aren't any Rust projects that large yet, but I feel like compilation speeds are something that can be worked around with tooling (distributed build farms, etc.). C++'s lack of safety and a proclivity for "use after free" errors is harder to fix.

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

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

#176

Post by sophacles »

jpc0 wrote: post #93
ModernMech wrote: post #33

What sold me on Rust is that I'm a very bad programmer and I make a lot of mistakes. Given C++, I can't help but hold things wrong and shoot myself in the foot. My media C++ coding session is me writing code, getting a segfault immediately, and then spending time chasing down the reason for that happening, rinse and repeat. My median Rust coding session isn't much different, I also write code that doesn't work, but i…

Using your media example since I have a decent amount of experience there. Did you just use off the shelf libraries, because effectively all the libraries are written in or expose a C api. So now you not only need to deal with Rust, you need to also deal with rust ffi. There are some places I won’t be excited to use rust, and media heavy code is one of those places…

Given that the second paragraph starts with "my median rust..." i assume the "media C++" is actually a typo for "median C++".

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

#177

Post by noitpmeder »

codedokode wrote: post #110
jsat wrote: post #66

I see an article about how strict typing is better, but what would really be nice here is named parameters. I never want to go back to anonymous parameters.

When there are 3-4 parameters it is too much trouble to write the names.

Not OP, but I imagine he's arguing for something like python's optional named arguments.

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

#178

Post by throwaway76455 »

kelnos wrote: post #76
b5n wrote: post #54

Earlier quoted context omitted.

> -Wconversion ... assumes converting 1000.0 to 1000 is ok due to no loss in precision. Additionally, `clang-tidy` catches this via `bugprone-narrowing-conversions` and your linter will alert if properly configured.

My opinion is that if you need to run extra tools/linters in order to catch basic errors, the language & its compiler are not doing enough to protect me from correctness bugs. I do run clippy on my Rust projects, but that's a matter of style and readability, not correctness (for the most part!).

Setting up clang-tidy for your IDE isn't really any more trouble than setting up a LSP. If you want the compiler/linter/whatever to reject valid code to protect you from yourself, there are tools you can use for that. Dismissing them just because they aren't part of the language (what, do you expect ISO C++ to enforce clang-tidy usage?) is silly.

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

#179

Post by chucksmash »

penguin_booze wrote: post #71
badbart14 wrote: post #26

Earlier quoted context omitted.

+1, especially loved the episode from a couple months back about using AI tools in development. Really got me thinking differently about the role of AI in a developer's workflow and how software development will evolve.

I can't see the publish date on the episodes.

https://www.twoscomplement.org/#podcast/pair-programming-wit...

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

#180

Post by Rucadi »

jeroenhd wrote: post #32
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…

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 created a library "cpp-match" that tries to bring the "?" operator into C++, however it uses a gnu-specific feature (https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html), I did support msvc falling-back to using exceptions for the short-circuit mechanism.

However it seems like C++ wants to only provide this kind of pattern via monadic operations.

Post reply on HN