Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Switching from C++ to Rust

laplab.me

Post reply on HN
Print view View original

91–100 of 289 posts

Re: Switching from C++ to Rust

#91

Post by celeritascelery »

unwrap_abuse wrote: post #81

So the problem with rust you will find is the abuse of unwrap in ecosystem, so your code will need to be panic-safe. We wanted to get rid of C++ exceptions but traded it for panic hell.

An important distinction is that rust doesn’t use exceptions for recoverable errors. You don’t have try/catch like you do in C++. Instead you use the Result type to propagate errors. This has the advantage of avoiding many of the downsides of exceptions (like leaving your program in a bad state) while making error handling more explicit.

Re: Switching from C++ to Rust

#92

Post by zabzonk »

mgsloan2 wrote: post #66
zabzonk wrote: post #19

Earlier quoted context omitted.

so, um, unions? i have to say that in many years of programming, i have almost never needed to use such types.

In my experience with languages that lack concise sum types and pattern matching, you end up with data types that have lots of implicit invariants. If you find yourself writing docs or thinking in your head things like "Field X is only set if field Y is true" or "If field X is non-null then field Y must be null and vice-versa", then these are indications that sum types would model the data better. Then these invarian…

i agree with your first point, but if your type-system is sufficently strong to express this, i'd like to see an example.

i agree completely with your second point - passing around or storing booleans is usually horrible.

Re: Switching from C++ to Rust

#93

Post by andrewflnr »

unclad5968 wrote: post #71
howinteresting wrote: post #51

Earlier quoted context omitted.

I'm going to make the even stronger claim that a general-purpose statically typed language that doesn't support sum types and exhaustive pattern matching to at least the extent that Rust does is unfit for general use, just like a language that doesn't have product types is unfit for general use. Dynamically-typed languages often have adhoc sum types.

Well that's obviously not true given all the successful apps written in languages that don't support sum types.

A lot of successful apps were written with GOTO. That doesn't mean it's a good idea now.

Re: Switching from C++ to Rust

#94

Post by MathMonkeyMan »

burntsushi wrote: post #3

The call out to sum types is something I feel. I've been using Rust daily for almost 10 years now, and sum types are absolutely still one of the things I love most about it. It's easily one of the things I miss the most in other languages that don't have them. I'm usually a proponent of "using languages as they're intended," but I missed exhaustiveness checking so much that I ported a version of it to Go[1] as a sort…

Until very recently, all of the C++ code I wrote was in the 1998 style or in the 2014 style.

Since 2017, there is std::variant, which is a sum type template that _technically_ allows for language-level exhaustiveness checking via std::visit. It's not pretty, but it gets you there without requiring compiler support.

Rust's version looks way better.

Re: Switching from C++ to Rust

#96

Post by bluGill »

turtledragonfly wrote: post #30
zabzonk wrote: post #21

Earlier quoted context omitted.

> for an experienced C++ programmer who is used to managing memory by hand nobody with an inch of nous does that anymore.

I suppose it comes down to your definition of "by hand," but creating custom allocators for your application and arranging your memory layout carefully can still absolutely be a worthwhile endeavor. Especially when performance matters (eg: high frequency trading systems, video games, constrained embedded systems, and more), the improved locality that you can get from custom memory management can be worth it all on it…

Sure, but those are still carefully controlled places and the majority of code isn't doing it by hand. Not like some old code I've seen where there were many different code paths memory could get ownership transferred to.

Re: Switching from C++ to Rust

#97

Post by bluGill »

girvo wrote: post #32
jesse__ wrote: post #2

Nice to see some level-headed anecdotes on the experiences of actually _using_ each language, as opposed to the usual "z0mg rustc fixez all yur mem0ry bUgz!!111one" And, as someone who's spelunking in the depths of a large CMake project right now, cargo sounds pretty nice.

Gosh I despise CMake. I despise it so much, I'm halfway through the process of extricating ESP-IDF from it.

I hate it too, but every alternative can't handle some dark corner of my build that just works in cmake.

Re: Switching from C++ to Rust

#99

Post by johnny22 »

mikebenfield wrote: post #86
howinteresting wrote: post #51

Earlier quoted context omitted.

I'm going to make the even stronger claim that a general-purpose statically typed language that doesn't support sum types and exhaustive pattern matching to at least the extent that Rust does is unfit for general use, just like a language that doesn't have product types is unfit for general use. Dynamically-typed languages often have adhoc sum types.

I know your claim will strike some people as absurd, but I agree. I am honestly flabbergasted that any general purpose language created in the last 20 years doesn't have sum types and pattern matching. To me they are very nearly as fundamental as aggregate types (aka structs or product types).

even php has some level of pattern matching now.

Re: Switching from C++ to Rust

#100

Post by Rusky »

celeritascelery wrote: post #91
unwrap_abuse wrote: post #81

So the problem with rust you will find is the abuse of unwrap in ecosystem, so your code will need to be panic-safe. We wanted to get rid of C++ exceptions but traded it for panic hell.

An important distinction is that rust doesn’t use exceptions for recoverable errors. You don’t have try/catch like you do in C++. Instead you use the Result type to propagate errors. This has the advantage of avoiding many of the downsides of exceptions (like leaving your program in a bad state) while making error handling more explicit.

This doesn't mean you don't still have to be panic-safe, though. This is mainly important for unsafe code, because it has to preserve memory safety even in the presence of panics. But it can also be important for safe code in an application that recovers from panics.
Post reply on HN