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

431–440 of 675 posts

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

#431

Post by mazurnification »

timschmidt wrote: post #377
d_tr wrote: 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…

Does GPU thingy count as something that has changed with computing?

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

#432

Post by affyboi »

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.

> Works for whom?

FAANG, hedge funds/HFT, game studios

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

#433

Post by skywhopper »

sophacles wrote: post #173
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.

So those editors could just insert the names for you. The bytes in the source file are not a serious concern, are they?

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

#434

Post by bionhoward »

zozbot234 wrote: post #40
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 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 This isn't really true since Rust has panics. It would be nice to have out-of-the-box support for a "no panics" subset of Rust, which would also make it easier to properly support linear (no auto-drop) types.

This is already a thing, I do this right now. You configure the linter to forbid panics, unwraps, and even arithmetic side effects at compile time.

You can configure your lints in your workspace-level Cargo.toml (the folder of crates)

“””

[workspace.lints.clippy]

pedantic = { level = "warn", priority = -1 }

# arithmetic_side_effects = "deny"

unwrap_used = "deny"

expect_used = "deny"

panic = "deny"

“””

then in your crate Cargo.toml “””

[lints]

workspace = true

“””

Then you can’t even compile the code without proper error handling. Combine that with thiserror or anyhow with the backtrace feature and you can yeet errors with “?” operators or match on em, map_err, map_or_else, ignore them, etc

[1] https://rust-lang.github.io/rust-clippy/master/index.html#un...

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

#435

Post by thawawaycold »

juliangmp wrote: post #90
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 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.

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

#436

Post by timschmidt »

mazurnification wrote: post #431
timschmidt wrote: post #377

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…

Does GPU thingy count as something that has changed with computing?

Yeah, I almost called that out. Probably should have. GPU/NPU feels new (at least for us folks who could never afford a Cray). Probably the biggest change in the last 20 years, especially if you classify it with other multi-core development.

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

#437

Post by AndrewStephens »

moomin wrote: post #335
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’ve seen it argued that, in practice, there’s two C++ communities. One is fundamentally OK with constantly upgrading their code (those with enterprise refactoring tools are obviously in this camp, but it’s more a matter of attitude than technology) and those that aren’t. C++ is fundamentally caught between those two.

This is the truth. I interview a lot of C++ programmers and it amazes me how many have gone their whole careers barely touching C++11 let alone anything later. The extreme reach of C++ software (embedded, UIs, apps, high-speed networking, services, gaming) is both a blessing and a curse and I understand why the committee is hesitant to introduce breaking changes at the expense of slow progress on things like reflection.

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

#438

Post by timschmidt »

pjmlp wrote: post #426
timschmidt wrote: post #380

Earlier quoted context omitted.

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…

Many of the members of the Rust Evangelism Strike Force, as main audience. That is to whom it is targeted for, given the usual kind of content that some write about. I agree that Rust is designed to be like C++ is today, without the cruft, except all languages if they survive long enough in the market, beyond the adoption curve, they will eventually get their own cruft. Not realizing this, will only make that 30 year…

> Many of the members of the Rust Evangelism Strike Force, as main audience.

Well I'm not them. I'm just a regular old software developer.

> The strength of C++ code today is on the ecosystem

Ecosystem is why I jumped ship from C++ to Rust. The difference in difficulty integrating a random library into my project is night and day. What might take a week or a month in C++ (integrating disparate build systems, establishing types and lifetimes of library objects and function calls, etc) takes me 20 minutes in Rust. And in general I find the libraries to be much smaller, more modular, and easier to consume piecemeal rather than a whole BOOST or QT at a time.

And while the Rust libraries are younger, I find them to be more stable, and often more featureful and with better code coverage. The language seems to lend itself to completionism.

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

#439

Post by kllrnohj »

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…

> Thinking that only "embedded" cares about custom allocators is just naive.

I said absolutely no such thing? In my $dayjob working on graphics I, too, have used custom allocators for various things, primarily in C++ though, not Rust. But that in no way makes the default of a global allocator wrong, and often those custom allocators have specialized constraints that you can exploit with custom containers, too, so it's not like you'd be reaching for the stdlib versions probably anyway.

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

#440

Post by ziml77 »

Cloudef wrote: post #279
jasonjmcghee wrote: post #12

Earlier quoted context omitted.

unfortunately it's not so simple. that's the convention. depending on the library you're using it might be a special type of Error, or special type of Result, something needs to be transformed, `?` might not work in that case (unless you transform/map it), etc. I like rust, but its not as clean in practice, as you describe

You can use anyhow, but yeah zig generally does errors better IMO

Errors are where I find zig severely lacking. They can't carry context. Like if you're parsing a JSON file and it fails, you can know that it failed but not where it failed within the file. Their solution in the standard library for cases like this was to handle printing to stderr internally, but that is incredibly hacky.
Post reply on HN