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

211–220 of 675 posts

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

#211

Post by thesuperbigfrog »

im3w1l wrote: post #205
writebetterc wrote: post #4

Yes, Rust is better. Implicit numeric conversion is terrible. However, don't use atoi if you're writing C++ :-). The STL has conversion functions that will throw, so separate problem.

Forcing people to explicitly casts everything all the time means that dangerous casts don't stand out as much. That's an L for rust imo.

The idiomatic Rust way to do conversions is using the From and TryFrom traits:

https://doc.rust-lang.org/stable/rust-by-example/conversion/...

https://doc.rust-lang.org/stable/rust-by-example/conversion/...

If the conversion will always succeed (for example an 8-bit unsigned integer to a 32-bit unsigned integer), the From trait would be used to allow the conversion to feel implicit.

If the conversion could fail (for example a 32-bit unsigned integer to an 8-bit unsigned integer), the TryFrom trait would be used so that an appropriate error could be returned in the Result.

These traits prevent errors when converting between types and clearly mark conversions that might fail since they return Result instead of the output type.

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

#212

Post by josephg »

kbolino wrote: post #118
zozbot234 wrote: post #44

Earlier quoted context omitted.

That's a neat hack, but it would be a lot nicer to have explicit support as part of the language.

That's going to be difficult because the language itself requires panic support to properly implement indexing, slicing, and integer division. There are checked methods that can be used instead, but to truly eliminate panics, the ordinary operators would have to be banned when used with non-const arguments, and this restriction would have to propagate to all dependencies as well.

Yes that’s right. The feature really wants compiler support for that reason. The simplest version wouldn’t be too hard to implement. Every function just exports a flag on whether or not it (or any callees) can panic. Then we have a nopanic keyword which emits a compiler error if the function (or any callee) panics.

It would be annoying to use - as you say, you couldn’t even add regular numbers together or index into an array in nopanic code. But there are ways to work around it (like the wrapping types).

One problem is that implicit nopanic would add a new way to break semver compatibility in APIs. Eg, imagine a public api that just happens to not be able to panic. If the code is changed subtly, it could easily start panicing again. That could break callers, so it has to be a major version bump. You’d probably have to require explicit nopanic at api boundaries. (Else assume all public functions from other crates can panic). And because of that, public APIs like std would need to be plastered with nopanic markers everywhere. It’s also not clear how that works through trait impls.

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

#213

Post by simpaticoder »

I don't get it. Isn't this a runtime problem and not a compile-time problem? buy() or sell() is going to be called with dynamic parameters at runtime, in general. That is, calls with concrete values are NOT going to be hard-coded into your program. I would write the function to assert() invariants within the function, and avoid chasing compile-time safety entirely. If parameter order was a concern, then I'd modify the function to take a struct, or similar.

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

#214

Post by neonsunset »

kelnos wrote: post #148
_mlbt wrote: post #19

Earlier quoted context omitted.

Swift is really great these days and supports Windows and Linux. It almost feels like a scripting language other than the compile time of course.

I still have a hard time adopting a language/ecosystem that was originally tied to a particular platform, and is still "owned" by the owners of that platform. Sun actually did it right with Java, recognizing that if they mainly targeted SunOS/Solaris, no one would use it. And even though Oracle owns it now, it's not really feasible for them to make it proprietary. Apple didn't care about other platforms (as usual) fo…

> Microsoft was for years actively hostile toward attempts to run .NET programs on platforms other than Windows

It's been 10 years. Even before that, no action was ever taken against Mono nor any restriction put or anything else. FWIW Swift shares a similar story, except Apple started to care only quite recently about it working anywhere else beyond their platforms.

Oh, and by the way, you need to look at these metrics: https://dotnet.microsoft.com/en-us/platform/telemetry

Maybe take off the conspiracy hat?

> There are too many other great choices with broad platform and community support

:) No, thanks, I'm good. You know why I stayed in .NET land and didn't switch to, say, Go? It's not that it's so good, it's because most alternatives are so bad in one or another area (often many at the same time).

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

#216

Post by im3w1l »

thesuperbigfrog wrote: post #211
im3w1l wrote: post #205

Earlier quoted context omitted.

Forcing people to explicitly casts everything all the time means that dangerous casts don't stand out as much. That's an L for rust imo.

The idiomatic Rust way to do conversions is using the From and TryFrom traits: https://doc.rust-lang.org/stable/rust-by-example/conversion/... https://doc.rust-lang.org/stable/rust-by-example/conversion/... If the conversion will always succeed (for example an 8-bit unsigned integer to a 32-bit unsigned integer), the From trait would be used to allow the conversion to feel implicit. If the conversion could fail (for…

Thanks yeah I probably misremembered or misunderstood.

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

#217

Post by josephg »

singingboyo wrote: post #69
dvt wrote: post #15

Earlier quoted context omitted.

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,…

There's some space for improvement, but really... not a lot? Result is a pretty basic type, sure, but needing to choose a dependency to get a nicer abstraction is not generally considered a problem for Rust. The stdlib is not really batteries included. Doing error handling properly is hard, but it's a lot harder when error types lose information (integer/bool returns) or you can't really tell what errors you might ge…

I agree with you, but it’s definitely inconvenient. Result also doesn’t capture a stack trace. I spent a long time tracking down bugs in some custom binary parsing code awhile ago because I had no idea which stack trace my Result::Err’s were coming from. I could have switched to another library - but I didn’t want to inflict extra dependencies on people using my crate.

As you say, it’s not “batteries included”. I think that’s a fine answer given rust is a systems language. But in application code I want batteries to be included. I don’t want to need to opt in to the right 3rd party library.

I think rust could learn a thing or two from Swift here. Swift’s equivalent is better thought through. Result is more part of the language, and less just bolted on:

https://docs.swift.org/swift-book/documentation/the-swift-pr...

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

#218

Post by thesuperbigfrog »

codedokode wrote: post #96

What about catching integer overflow? Free open-source languages still cannot do it unlike they commercial competitors like Swift?

Ada has had overflow checks for decades:

https://learn.adacore.com/courses/intro-to-ada/chapters/stro...

And there is an Ada implementation that is part of GCC:

https://www.gnu.org/software/gnat/

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

#219

Post by brundolf »

simpaticoder wrote: post #213

I don't get it. Isn't this a runtime problem and not a compile-time problem? buy() or sell() is going to be called with dynamic parameters at runtime, in general. That is, calls with concrete values are NOT going to be hard-coded into your program. I would write the function to assert() invariants within the function, and avoid chasing compile-time safety entirely. If parameter order was a concern, then I'd modify th…

> Isn't this a runtime problem and not a compile-time problem? buy() or sell() is going to be called with dynamic parameters at runtime, in general.

Yes, but the strength of Rust's type system means you're forced to handle those bad dynamic values up front (or get a crash, if you don't). That means the rest of your code can rest safe, knowing exactly what it's working with. You can see this in OP's parsing example, but it also applies to database clients and such

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

#220

Post by johnisgood »

Arnavion wrote: post #121
codedokode wrote: post #103

Earlier quoted context omitted.

It's pretty difficult to have no panics, because many functions allocate memory and what are they supposed to do when there is no memory left? Also many functions use addition and what is one supposed to do in case of overflow?

>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,…

> Zig for example does it right by having explicit allocators from the start

Odin has them, too, optionally (and usually).

Post reply on HN