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

101–110 of 289 posts

Re: Switching from C++ to Rust

#101

Post by [deleted] »

raincole wrote: post #45
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…

> I've been using Rust daily for almost 10 years now, I'm just nitpicking but Rust is 7 years old and 7 doesn't feel almost 10... Edit: Rust hit 1.0 7 years ago. Now I feel silly.

[deleted]

Re: Switching from C++ to Rust

#102

Post by burntsushi »

jhatemyjob wrote: post #95

[flagged]

> C++ has a very long history (over 50 years) and to say he's some expert matter on the subject after a mere 4 years of "professional experience" is quite baffling to me.

It's understandable that you're baffled, especially given that the OP didn't claim to be an expert. The OP pretty clearly did not claim any authority, and instead went out of their way to clearly disclose not just the number of years of experience they have, but what they worked on.

> Waste of time

It's worse than a waste of time. Comments like yours make HN a worse place. Extrapolating some minor English writting buugs intto an asessment on how good they're code is? Man, what an absolute stinky pile of bullshit.

Re: Switching from C++ to Rust

#103

Post by gpderetta »

dilap wrote: post #74
nicoburns wrote: post #56

Earlier quoted context omitted.

A method on a union is much less useful when you can't match on the tag though. I suppose you could store tag inside the union. Is that common? I've always imagined C/C++ tagged unions would store tag outside the union.

i haven't done c++ in a million years, but huh, you can! can't have any types w/ non-trival copy constructors in a union, though, apparently, which is quite the restriction. https://gist.github.com/erinok/c823af95db408653c7e42ab189307...

You can have non trivial types in an union, but you need to explicitly define constructor in the union or the containing type (i.e. the default union copy constructor and assignment operator are disabled).

Re: Switching from C++ to Rust

#104

Post by noobermin »

burntsushi wrote: post #24
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.

Nope, not unions. Sum types. Sum types would be more analogous to tagged unions or discriminated unions. > i have almost never needed to use such types Well sure. When is an abstraction "needed"? Before Fortran, nobody "needed" a programming language either. So is a programming language necessary? That's the funny thing about the word "need." It has very narrow application, and it's precisely why I didn't mention the…

Can you explain the utility of them over unions then? Asking sincerely.

Re: Switching from C++ to Rust

#105

Post by cmrdporcupine »

xiphias2 wrote: post #5

The most fun thing reading this comparision is again that for an experienced C++ programmer who is used to managing memory by hand (and fixing segfaults), Rust's memory model doesn't seem that hard, because it makes sense, and he understands why the checks are important.

when I started moving from C++ to Rust I found the easiest initial way to make sense of the borrow checker was to basically imagine that almost every argument passed in a function call was wrapped in a std::move.

Re: Switching from C++ to Rust

#106

Post by celeritascelery »

Rusky wrote: post #100
celeritascelery wrote: post #91

Earlier quoted context omitted.

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.

You are correct that there are circumstances where you have to consider panic safety. But those are rare. Most code is not unsafe, and catching panics is usually bad practice in Rust (though I am sure there are circumstances where it is needed). In C++ by contrast you have to think about panic safety almost everywhere. Rust’s error handling is a big improvement in that regard.

Re: Switching from C++ to Rust

#107

Post by phendrenad2 »

girvo wrote: post #26

I want to switch to Rust, to get away from the C/C++/Nim mix we rely on at work. But embedded development (specifically for the ESP32-S3 chip, but we also have to do a lot of STM32 work as well for our coprocessors) has sort of forced us down this path. That said, the bulk of our code is Nim, and it is lovely to work in. I just wish we didn't have to rely on C/C++ libraries and toolchains as much. CMake will be the d…

Do you really need CMake? Are clean compilation times very slow?

Re: Switching from C++ to Rust

#108

Post by mgraczyk »

loeg wrote: post #43
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…

Yeah. In the C++ codebase I work on, we use folly::Expected (essentially similar to Rust's Result ) heavily. Is it as ergonomic as Result is in Rust? Absolutely not. But it's still a nice design pattern for some of the same reasons people use Result in Rust. (And C++ std::optional is somewhat similar to Rust's Option type.) https://github.com/facebook/folly/blob/main/folly/Expected.h...

Worth mentioning that C++23 adds something very similar to the standard library, called std::expected.

https://en.cppreference.com/w/cpp/utility/expected

Unfortunately it does not come with nice syntax to return on error.

Re: Switching from C++ to Rust

#109

Post by burntsushi »

noobermin wrote: post #104
burntsushi wrote: post #24

Earlier quoted context omitted.

Nope, not unions. Sum types. Sum types would be more analogous to tagged unions or discriminated unions. > i have almost never needed to use such types Well sure. When is an abstraction "needed"? Before Fortran, nobody "needed" a programming language either. So is a programming language necessary? That's the funny thing about the word "need." It has very narrow application, and it's precisely why I didn't mention the…

Can you explain the utility of them over unions then? Asking sincerely.

Unfortunately it's actually kind of difficult to parse your question because of the ambiguity in the surrounding comments. You could mean "tagged union" instead of "union," or maybe not and "them" means "tagged union"...

If you're asking to compare tagged unions and unions, then...

A union is not a tagged union. A union is part of a tagged union. A union on its own is just a region of memory. What's in that memory? I dunno. Who does? Maybe something about your program knows what it is. Maybe not. But what if you need to know what it is and some other aspect of your program doesn't tell you what it is? Well, you instead put a little bit of memory next to your union. Perhaps it an integer. 0 means the memory is a 32-bit signed integer. 1 means it's a NUL terminated string. 2 means it's a 'struct dirent'. The point is, that integer is a tag. The combination of a union and a tag is a tagged union.

An abstract syntax tree is a classic example of a tagged union.

If instead you're asking to compare tagged unions and sum types, then...

Tagged unions are one particularly popular implementation choice of a sum type. Usually sum types have additional stuff layered on top of them that a simple tagged union does not have. For example, pattern matching and exhaustiveness checking.

Post reply on HN