Switching from C++ to Rust • Hacker News Board

Re: Switching from C++ to Rust

#181

Post by 3836293648 » Tue, Mar 14, 2023, 9:18 AM UTC

blub wrote: post #171

dureuill wrote: post #168

Earlier quoted context omitted.

Yes, but: - nobody uses it in the ecosystem. As outlined in the article, a lot of value of Option/Result is derived from their pervasiveness in the Rust ecosystem. C++ is far from this - the ergonomics of it are terrible: no pattern matching, structural variants instead of named variants (yes you can emulate that with wrapper types but meh), lambda-oriented matching means you cannot as easily do things like early ret…

Variant types where one has to use objects as types don’t come up that often in API design or data structures in my experience with mobile and system programming on e.g. Linux. I think I’ve genuinely had to use them only a few times. Error types are probably the most popular incarnation of that. There’s several libraries available and they will be part of the C++ standard. This is a case of the Rust community oversel…

You clearly haven't tried using variant types properly then. Sure, `std::variant` is pretty unergonomic, but they really are game changing. Most of my types are variant types

Re: Switching from C++ to Rust

#182

Post by dureuill » Tue, Mar 14, 2023, 9:20 AM UTC

blub wrote: post #171

dureuill wrote: post #168

Earlier quoted context omitted.

Yes, but: - nobody uses it in the ecosystem. As outlined in the article, a lot of value of Option/Result is derived from their pervasiveness in the Rust ecosystem. C++ is far from this - the ergonomics of it are terrible: no pattern matching, structural variants instead of named variants (yes you can emulate that with wrapper types but meh), lambda-oriented matching means you cannot as easily do things like early ret…

Variant types where one has to use objects as types don’t come up that often in API design or data structures in my experience with mobile and system programming on e.g. Linux. I think I’ve genuinely had to use them only a few times. Error types are probably the most popular incarnation of that. There’s several libraries available and they will be part of the C++ standard. This is a case of the Rust community oversel…

> Variant types where one has to use objects as types don’t come up that often in API design or data structures in my experience with mobile and system programming on e.g. Linux

You can't use what you don't have, so you adapt to the tools you do have. In my C++ time, the team would often write types that logically held several variants. However they were expressed as product types, so with space overhead and error-prone, unergonomic use.

Sum types are game-changing. Look at any Rust project you'll find enums with data everywhere. They're just a building block to model problems, like product types are. A language that miss them is as strange too me as a language without product types. After 10 years of mostly C++11 and C++14 I would never go back to it for this reason alone (although as outlined in the article there are other reasons too).

> Error types are probably the most popular incarnation of that. There’s several libraries available and they will be part of the C++ standard.

Again, with what performance and ergonomics?

Re: Switching from C++ to Rust

#183

Post by blub » Tue, Mar 14, 2023, 9:21 AM UTC

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.

Rust programmers misuse unwrap and the like all the time, to the point that I’ve seen some projects explicitly state that they don’t do that, since nobody wants their library to crash their program because someone was too lazy to propagate errors.

Which brings me to the point: propagating errors is tedious enough that people are looking for shortcuts, which then cause other problems.

Re: Switching from C++ to Rust

#184

Post by jandrewrogers » Tue, Mar 14, 2023, 9:23 AM UTC

zabzonk wrote: post #21

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.

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

Manually managing memory is idiomatic for performance engineering in C++. You don't always need to do it but it is definitely done.

Re: Switching from C++ to Rust

#185

Post by whyever » Tue, Mar 14, 2023, 9:26 AM UTC

blub wrote: post #171

dureuill wrote: post #168

Earlier quoted context omitted.

Yes, but: - nobody uses it in the ecosystem. As outlined in the article, a lot of value of Option/Result is derived from their pervasiveness in the Rust ecosystem. C++ is far from this - the ergonomics of it are terrible: no pattern matching, structural variants instead of named variants (yes you can emulate that with wrapper types but meh), lambda-oriented matching means you cannot as easily do things like early ret…

Variant types where one has to use objects as types don’t come up that often in API design or data structures in my experience with mobile and system programming on e.g. Linux. I think I’ve genuinely had to use them only a few times. Error types are probably the most popular incarnation of that. There’s several libraries available and they will be part of the C++ standard. This is a case of the Rust community oversel…

I disagree. Whenever there is a null pointer in the API, you could (and probably should) be using a sum type instead.

Sum types are not novel (Standard ML had them 40 years ago), but I think they are indeed a game changer.

Re: Switching from C++ to Rust

#186

Post by tialaramex » Tue, Mar 14, 2023, 9:27 AM UTC

unwind wrote: post #173

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.

At least in C, you cannot store a tag inside the union since all fields of the union live at the same offset (0) they tag will be smashed by the actual value it's trying to talk about. In C, you have to wrap the union in a struct in order to add the tag, and that pattern is fantastically common. Let's have a little geometry-inspired example: typedef enum { SHAPETYPE_RECTANGLE, ... } ShapeType; typedef struct { ... }…

I'm not certain for C, but definitely in C++ it's legal to union a bunch of structures with a common prefix, and then talk about the prefix in the "wrong" variant and that's OK. There may be some restrictions about exactly what is in that prefix, but at least obvious things like an enum or an integral type will work.

So for your example you put ShapeType type in each of Rectangle, Circle, Triangle etc. and then you can union all of them, and the language promises that shape.circle.type == Rectangle is a reasonable thing to ask, so you can use that to make a discriminated union.

Re: Switching from C++ to Rust

#187

Post by kaba0 » Tue, Mar 14, 2023, 9:28 AM UTC

delta_p_delta_x wrote: post #125

tialaramex wrote: post #76

Earlier quoted context omitted.

Actually all three of Rust's user defined types (the sum type enum, the product type struct, and union†) are fully fledged types which can implement traits and have functions of their own (including functions taking a self parameter, thus methods) C++ unions can actually have methods, although this isn't used very much. However C++ enums can't have methods, even C++ 11 scoped enums ("enum classes") can't have methods…

> C++ enums can't have methods, even C++ 11 scoped enums ("enum classes") can't have methods, I have no idea why that restriction seemed like a good idea It is possible that Oracle holding the patent[1] to methods on enums is the blocker, rather than any technical restriction. [1]: https://patents.google.com/patent/US7263687

I am absolutely not a lawyer, but wouldn’t it fall into the “trivial” category, so even if patented, it couldn’t be enforced?

Re: Switching from C++ to Rust

#188

Post by blub » Tue, Mar 14, 2023, 9:28 AM UTC

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.

Rust’s memory management is not hard, it’s just tedious. If programming in the future will mean annotating the crap out of everything then garbage-collected languages start to become attractive - see golang competing with Rust in unexpected areas.

Perhaps the only hard part is storing and passing references everywhere, which may mean that one has to act like an automaton and patiently type their lifetimes to the Rust compiler. Unfortunately the Rust programming community has settled exactly on this kind of reference usage.

Re: Switching from C++ to Rust

#189

Post by kaba0 » Tue, Mar 14, 2023, 9:29 AM UTC

the_gipsy wrote: post #159

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…

Same here, go would be such a killer language if it just had sum types.

Yeah, it might even reach Java 1.1, feature-wise then.

Re: Switching from C++ to Rust

#190

Post by dureuill » Tue, Mar 14, 2023, 9:30 AM UTC

tialaramex wrote: post #179

pharmakom wrote: post #160

Earlier quoted context omitted.

C++ has std::variant though?

So, so many ways in which this is defective compared to actual sum types, some of them were already listed, but to me the most crucial, even if mostly about theory rather than practice, is valueless_by_exception. The choice to provide exceptions everywhere as a error handling means C++ is obliged to admit that your std::variant may not have a value at all. Which blows up all of your type safety. In Rust I can say tha…

I get the "theoretical" point, but the issues I encountered in practice are closer to the ones I listed in my response than to valueless_by_exception (which I never encountered, I think?).

Wrt type safety we had more pressing issues with C++ (use after move, implicit conversions, ...)