This article compares onlye one specific feature of C++ with Rust - integral type conversions.
Matt Godbolt sold me on Rust by showing me C++
351–360 of 675 posts
Re: Matt Godbolt sold me on Rust by showing me C++
#352Earlier quoted context omitted.
> 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.
I wish more people (and crate authors) would treat panic!() as it really should be treated: only for absolutely unrecoverable errors that indicate that some sort of state is corrupted and that continuing wouldn't be safe from a data- or program-integrity perspective. Even then, though, I do see a need to catch panics in some situations: if I'm writing some sort of API or web service, and there's some inconsistency in…
> I probably really would prefer only that request to abort, not for the entire process to be torn down,
This is a sign you are writing an operating system instead of using one. Your web server should be handling requests from a pool of processes - so that you get real memory isolation and can crash when there is a problem.
Re: Matt Godbolt sold me on Rust by showing me C++
#353Earlier quoted context omitted.
would you consider panics acceptable when you think it cannot panic in practice? e.g. unwraping/expecting a value for a key in a map when you inserted that value before and know it hasn't been removed? you could have a panic though, if you wrongly make assumptions
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.
Re: Matt Godbolt sold me on Rust by showing me C++
#354Earlier quoted context omitted.
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…
I don't see why you would have to write your own - there are plenty of options in the crate ecosystem, but perhaps you found them insufficient? As a video game developer, I've found the case for custom general-purpose allocators pretty weak in practice. It's exceedingly rare that you really want complicated nonlinear data structures, such as hash maps, to use a bump-allocator. One rehash and your fixed size arena blo…
> there are plenty of options in the crate ecosystem
Who writes the crates?
Re: Matt Godbolt sold me on Rust by showing me C++
#355What about catching integer overflow? Free open-source languages still cannot do it unlike they commercial competitors like Swift?
Rust is the only language I can easily control how integer overflow should behave. I can use `var1.wrapping_add(var2)` if I want the result to be wrapped or `var1.checked_add(var2)` if I don't want it to overflow.
The functions are so verbose and inconvenient that even Rust developers themselves do not use them. For example, in this code [1] they used a wrapping addition instead of "checked_add" because it is faster to write.
For comparison, Swift uses "+" for checked addition and as a result, majority of developers use checked addition by default. And in Rust due to its poor design choices most developers use wrapping addition even where a checked addition should be used.
[1] https://doc.rust-lang.org/src/alloc/vec/mod.rs.html#2010
Re: Matt Godbolt sold me on Rust by showing me C++
#356Earlier quoted context omitted.
I meant panic if during any addition (including in runtime) an overflow occurs.
If you obscure the implementation a bit, you can change GP's example to a runtime overflow [0]. Note that by default the checks will only occur when using the unoptimized development profile. If you want your optimized release build to also have checks, you can put 'overflow-checks = true' in the '[profile.release]' section of your cargo.toml file [1]. [0]: https://play.rust-lang.org/?version=stable&mode=debug&editio…
This is bad because the program behaves different depending on build flags. What's the point of having "use unsafe addition" flag, and having it enabled by default?
Rust developers made a poor choice. They should have made a special function for unchecked addition and have "+" operator always panic on overflow.
Re: Matt Godbolt sold me on Rust by showing me C++
#357Earlier quoted context omitted.
> I like that Rust can pick good concepts and design coherent language from them without inventing its own "pragmatic" solution that breaks horribly in some use cases that some "practitioners" deem "too theoretical." I've thought Rust picked some pretty nifty middle ground. On one side, it's not mindfucking unsafe like C. It picked to remove a set of problems like memory safety. On the other side, Rust didn't go for…
As per the article, Rust has benefits beyond the ones afforded by the borrow checker.
Sure, but it is pragmatic in other ways as well :)
It takes ADT, but not function currying, and so on.
Re: Matt Godbolt sold me on Rust by showing me C++
#358Earlier quoted context omitted.
I meant panic if during any addition (including in runtime) an overflow occurs.
You can set a flag for that: https://doc.rust-lang.org/rustc/codegen-options/index.html#o... By default, they're on during debug mode and off in release mode.
The choice doesn't make sense because you want the program to always behave correctly and not only during development.
Re: Matt Godbolt sold me on Rust by showing me C++
#359What about catching integer overflow? Free open-source languages still cannot do it unlike they commercial competitors like Swift?
Rust does have checked arithmetic operations (that return Result), but you have to explicitly opt in to them, of course, and they're not as ergonomic to use as regular arithmetic.
As a result, Rust developers themselves use wrapping addition where a checked addition should be used: https://doc.rust-lang.org/src/alloc/vec/mod.rs.html#2010
Re: Matt Godbolt sold me on Rust by showing me C++
#360Earlier quoted context omitted.
Just give Rust 36 years of field use, to see how it goes.
36 years is counting from the first CFront release. Counting the same way for Rust, it's been around since 2006. It's got almost 20 years under it's belt already. edit: what's with people downvoting a straight fact?
Because it is counting since CFront 2.0, the first official release with industry use in UNIX systems.
So that would be Rust 1.0, released in 2015, not 2006, putting it down to a decade.
And the point still stands when looking at any long enough ecosystem still in use, with strong backwards compatibility, not only the language, the whole ecosystem, eventually editions alone won't make it, and just like those languages, Rust will gain its own warts.