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

621–630 of 675 posts

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

#621

Post by burntsushi »

0x457 wrote: post #527
burntsushi wrote: post #481

Earlier quoted context omitted.

Example docs for `foo() -> Result `: # Errors `foo` returns an error called `UnspecifiedError`, but this only happens when an anticipated bug in the implementation occurs. Since there are no known such bugs, this API never returns an error. If an error is ever returned, then that is proof that there is a bug in the implementation. This error should be rendered differently to end users to make it clear they've hit a b…

Funny that as a user of this library, I would just unwrap this, and it results in the same outcome as if library panicked.

Yes. A panic is the right thing to do, and it's just fine if the library does it for you.

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

#622

Post by burntsushi »

stouset wrote: post #589
burntsushi wrote: post #481

Earlier quoted context omitted.

Example docs for `foo() -> Result `: # Errors `foo` returns an error called `UnspecifiedError`, but this only happens when an anticipated bug in the implementation occurs. Since there are no known such bugs, this API never returns an error. If an error is ever returned, then that is proof that there is a bug in the implementation. This error should be rendered differently to end users to make it clear they've hit a b…

My main issue with panics is poor interop across FFI boundaries.

This is like saying, "my main issue with bugs is that they result in undesirable behavior."

Panicking should always be treated as a bug. They are assertions.

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

#623

Post by bunderbunder »

int_19h wrote: post #571
sn9 wrote: post #522

Earlier quoted context omitted.

Can I interest you in some Moonbit? https://www.moonbitlang.com/blog/first-announce

With any new language, the first question one has to ask is, "what are the guarantees that it'll still be around in 5 years?".

For paid work, sure. But if it's for hobbies or even side hustles then I don't see any harm in prioritizing fun.

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

#624

Post by Ygg2 »

kragen wrote: post #577
Ygg2 wrote: post #459

Earlier quoted context omitted.

I think the best summary is this: https://fasterthanli.me/articles/the-rustconf-keynote-fiasco... > On the surface it sounds like a community with such deep pathology First what sort of pathology? You're confusing community with leadership. The community didn't want this, and leadership was doing a restructuring due to change from Foundation and Project. Welcome to OSS projects. Second as opposed to what? A community…

Thank you! I can try to answer your questions if they are important to you, but it will require some significant effort, so I'd like to be sure they aren't rhetorical first.

Honestly, I'm wondering what kind of pathology do you see that isn't just a community stereotype, and that won't change with the influx of new programmers?

And how does it differ from the average Open-Source Project?

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

#625

Post by affyboi »

jchw wrote: post #510
affyboi wrote: post #430

Earlier quoted context omitted.

> but why not just enforce that as standard I don’t think people want that as standard. The whole point of using C++ tends to be because you can do whatever you need to for the sake of performance. The language is also heavily driven by firms that need extreme performance (because otherwise why not use a higher level language) There are knobs like stdlib assertions and ubsan, but that’s opt-in because there’s a cost…

There does not need to be an additional cost for this. Most users will do this: 1. Check if there is a value 2. Get the value There is nothing theoretically preventing the compiler from enforcing that step 1 happens before step 2, especially if the compiler is able to combine the control flow branch with the process of conditionally getting the value. The practical issue is that there's no way to express this in C++…

I might have misinterpreted what you mean as “standard” (I was originally thinking like you meant that the standard dictates all operations must be safe and doing things like the unsafe/unchecked option references would be outside the standard). I realized that you might mean it like it should be the default behavior, so correct me if I’m wrong there.

Yeah I agree that sane defaults would be nice and that things like unchecked accesses should be more explicit. Having linear types to properly enforce issues with things like use-after-move would also be awesome. I don’t know that anyone has ever accused C++ of being particularly ergonomic. Sum types and pattern matching would be awesome.

Nothing wrong with being a Rust fanboy :), I have written some (https://github.com/afnanenayet/diffsitter).

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

#626

Post by ziml77 »

Cloudef wrote: post #582
ziml77 wrote: post #440

Earlier quoted context omitted.

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.

The std has diagnostics struct you can give to the json parser. Zig is manually memory managed language so it doesnt have payloads in errors for a good reason.

Manual memory management is not a reason Zig couldn't have supported sum types for error returns. You don't need an allocator involved at all to return a discriminated union like Rust uses.

I actually find Zig quite a pleasant language other than my gripe with not handling more complex errors as cleanly.

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

#627

Post by affyboi »

benced wrote: post #519
tormeh wrote: post #429

Earlier quoted context omitted.

Maybe. But I wouldn't diss better languages, linters, and other tool inprovements. These systematically increase quality at very low cost. It boggles my mind that the whole industry is not falling over itself to continuously embrace better tools and technology.

The whole industry is, the C++ ecosystem is just not.

I don’t think that’s true. C++ just has a lot of baggage to deal with and people are doing the best they can with some ridiculous constraints. The sanitizers and things like clang-tidy, and better analysis in compilers seem to be really well received.

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

#628

Post by sagarm »

CJefferson wrote: post #206
jchw wrote: post #89

Earlier quoted context omitted.

Google has been doing a very similar, but definitely somewhat uglier, thing with StatusOr and Status (as seen in absl and protobuf) for quite some time. A long time ago, there was talk about a similar concept for C++ based on exception objects in a more "standard" way that could feasibly be added to the standard library, the expected class. And... in C++23, std::expected does exist[1], and you don't need to use excep…

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.

This is the idiomatic way in C++. I'm not even sure what your proposed alternative is -- as other commenters have noted, an exception or "panic" are not actual options.

Every pointer dereference, array access, and even integer truncation is UB in C++. This isn't rust.

A static analyzer can and does catch these errors and others internally. Typical usage of StatusOr is via macros like ASSIGN_OR_RETURN and RETURN_IF_ERROR; actually using the * operator would definitely draw my attention in code review.

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

#629

Post by ttfkam »

divan wrote: post #608
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, p…

It's also highly dependent upon the team's skill and diligence. You can easily ignore errors and skip error handling in Go with predictably hilarious results.

In Rust, you can't just skip error handling. You have to proactively do something generally unwise (and highly visible!) like call .unwrap() or you have to actually handle the error condition.

Go still relies on goodwill and a good night's sleep. The Rust compiler will guard against laziness and sleep deprivation, because ultimately programming languages are about people, not the computers.

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

#630

Post by ttfkam »

throw10920 wrote: post #583
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 is obviously insufficient for writing nontrivial programs, because nontrivial programs fail in nontrivial ways that need exceptional control flow. The result type does not work because you have to choose between immediate callers handling failures (they don't always have the context to do so because they're not aware of the context of callers higher up on the call stack) or between propagating all of…

The Result type works for an awful lot of people. Be careful with absolute statements like "does not work." When it works for many others, they might just assume it's a skill issue.
Post reply on HN