[flagged]
Matt Godbolt sold me on Rust by showing me C++
81–90 of 675 posts
Re: Matt Godbolt sold me on Rust by showing me C++
#82Earlier 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!).
How much of what Rust the language checks is actually linter checks implemented in the compiler?
Conversions may be fine and even useful in many cases, in this case it isn’t. Converting to std::variant or std::optional are some of those cases that are really nice.
Re: Matt Godbolt sold me on Rust by showing me C++
#83The 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…
Generally, I agree the situation with errors is much better in Rust in the ways you describe. But, there are also panics which you can catch_unwind[1], set_hook[2] for, define a #[panic_handler][3] for, etc. [1] https://doc.rust-lang.org/std/panic/fn.catch_unwind.html [2] https://doc.rust-lang.org/std/panic/fn.set_hook.html [3] https://doc.rust-lang.org/nomicon/panic-handler.html
Yeah, in anything but heavily multi-threaded servers, it's usually best to immediately crash on a panic. Panics don't mean "a normal error occurred", they mean, "This program is cursed and our fundamental assumptions are wrong." So it's normal for a unit test harness to catch panics. And you may occasionally catch them and kill an entire client connection, sort of the way Erlang handles major failures. But most programs should just exit immediately.
Re: Matt Godbolt sold me on Rust by showing me C++
#84This seems a big silly. This is not a language issue. You can have a C++ library that does exactly all the things being shown here so that the application developer doesn't worry about. There would no C++ language features missing that would accomplish what you're able to do on the Rust side.
So is this really a language comparison, or what libraries are available for each language platform? If the latter, that's fine. But let's be clear about what the issue is. It's not the language, it's what libraries are included out of the box.
Re: Matt Godbolt sold me on Rust by showing me C++
#85Earlier quoted context omitted.
I like so much about Rust. But I hear compiling is too slow. Is it a serious problem in practice?
People who say "Rust compiling is so slow" have never experienced what building large projects was like in the mid-1990s or so. It's totally fine. Besides, there's also https://xkcd.com/303/
Or maybe they have experienced what it was like and they don't want to go back.
Re: Matt Godbolt sold me on Rust by showing me C++
#86What if we have a C that removes the quirks without adding too much brain drain? So no implicit type conversions, safer strings, etc.
Because it's easier to add a warning or error. Don't like implicit conversions? Add a compiler flag, and the issue is basically gone.
Safer strings is harder, as it gets into the general memory safety problem, but people have tried adding safer variants of all the classic functions, and warnings around them.
Re: Matt Godbolt sold me on Rust by showing me C++
#87Earlier quoted context omitted.
> the `anyhow` crate is basically mandatory from an ergonomics standpoint in every Rust project I start If you use `anyhow`, then all you know is that the function may `Err`, but you do not know how - this is no better than calling a function that may `throw` any kind of `Throwable`. Not saying it's bad, it is just not that much different from the error handling in Kotlin or C#.
Yes. I prefer ‘snafu’ but there are a few, and you could always roll your own.
Yeah, with SNAFU I try to encourage people going all-in on very fine-grained error types. I love it (unsurprisingly).
Re: Matt Godbolt sold me on Rust by showing me C++
#88Coming from python (or Common Lisp, or...), I wasn't too impressed. In Python I normally make args for any function with more than a couple be keyword arguments, which guarantees that you are aware of how the arguments are being mapped to inputs. Even Rust's types aren't going to help you if two arguments simply have the same types.
Just create dummy wrappers to make a type level distinction. A Height and a a Width can be two separate types even if they’re only floats basically. Or another (dummy) example transfer(accountA, accountB). Make two types that wrap the same type but one being a TargetAccount and the other SourceAccount. Use the type system to help you, don’t fight it.
Do you really want width and height or do you actually want dimensions or size? Same with transfer, maybe you wanted a transaction that gets executed. Worst case here use a builder with explicit function names.
Re: Matt Godbolt sold me on Rust by showing me C++
#89The 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…
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 exception objects or anything awkward like that, it can work with arbitrary error types just like Result. Unfortunately, it's so horrifically late to the party that I'm not sure if C++23 will make it to critical adoption quickly enough for any major C++ library to actually adopt it, unless C++ has another massive resurgence like it did after C++11. That said, if you're writing C++ code and you want a "standard" mechanism like the Result type, it's probably the closest thing there will ever be.
Re: Matt Godbolt sold me on Rust by showing me C++
#90The 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…
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.