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

231–240 of 289 posts

Re: Switching from C++ to Rust

#231

Post by unwind »

tialaramex wrote: post #186
unwind wrote: post #173

Earlier quoted context omitted.

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

Yes, totally. Good point, I forgot about that technique. I prefer this, which is less invasive.

Re: Switching from C++ to Rust

#232

Post by zaphar »

evntdrvn wrote: post #178
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…

I just wish that Rust’s enum Variants were types… maybe someday! :)

It's not exactly what you want but you get most of the benefit by just wrapping types in enum variants.

Re: Switching from C++ to Rust

#233

Post by burntsushi »

kaba0 wrote: post #193
burntsushi wrote: post #84

Earlier quoted context omitted.

Based on your other replies in this thread, as far as I can tell, you're not here to try and understand something. You're here to fuck around and play games with people over definitions. So, I'm not responding to you. I'm responding to the people following along who might get confused by the mess you're making here. More to the point, the Wikipedia article for "sum type" redirects to "tagged union," which just honest…

Thanks for the writeup! Slightly unrelated, but re > More to the point, the Wikipedia article for "sum type" redirects to "tagged union," which just honestly makes this more of a mess I often see Wikipedia articles in CS topics severely lacking, or claiming exact definitions, when no such thing exists. Many definitions we regularly use are not exact at all, different papers/books use them differently, e.g. how would…

I agree that they are lacking. In theory, I have the disposition to improve articles like that, but in practice, whenever I've tried, I get shut down by editors. It's been a long time since I've tried though.

It happens on other wikis too, like the Arch wiki.

I realize it's a tired complaint that a lot of people have and editors don't have an easy job, but I am so completely done with contributing to wikis. I know a lot of other people with the same complaint and same conclusion, including experts in the domain of type theory. One wonders whether this is one of the reasons why the articles are not as good as they could be.

Re: Switching from C++ to Rust

#234

Post by burntsushi »

kd5bjo wrote: post #147
burntsushi wrote: post #84

Earlier quoted context omitted.

Based on your other replies in this thread, as far as I can tell, you're not here to try and understand something. You're here to fuck around and play games with people over definitions. So, I'm not responding to you. I'm responding to the people following along who might get confused by the mess you're making here. More to the point, the Wikipedia article for "sum type" redirects to "tagged union," which just honest…

> But you can disable it for a particular sum type with the '#[non_exhaustive]' attribute. I’m not sure this is the best description of what `#[non_exhaustive]` does in Rust. It doesn’t so much disable exhaustiveness checking as it marks the given list of variants as incomplete. In Rust, some pattern matching contexts are required to be exhaustive (e.g. ‘let pattern = …;’, ‘match … {}’), and others are not (e.g. ‘if…

My goal wasn't to describe it thoroughly, it was to call it out as a means of disabling exhaustiveness checking. Regardless of whether that's really what the essence of '#[non_exhaustive]' actually is, it does disable exhaustiveness checking. It's right in the name. It's an important part of what it does.

Basically, we're talking past each other. I called it out for what it does, but you're pointing out why someone would want to use it. That is, "#[non_exhaustive] on enums indicates that the list of variants is incomplete, and it does this by disabling exhaustiveness checking outside of the crate in which it is defined." Although, of course, not even that is precisely correct. Because your match arms are still forced to be technically exhaustive via the compiler requiring a wildcard arm. But the end effect to the user of the enum is that exhaustiveness checking on the variants of the enum is disabled.

Re: Switching from C++ to Rust

#235

Post by chippiewill »

rayiner wrote: post #121
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…

A nice thing about Rust is that it brings many well established good ideas from the ML branch of languages to the curly brave branch of languages. And frankly does a better job naming them (for people who weren’t math majors).

A monad is just a monoid in the category of endofunctors.

Seriously though, calling Algebraic Data Types an Enum was a stroke of genius.

Re: Switching from C++ to Rust

#236

Post by sat0ri »

aldanor wrote: post #217
alphanullmeric wrote: post #115

Rust will only be a real competitor once it’s generics can hold a candle to C++ templates.

You forgot to add /s. Thanks but no, replacing a bunch of code as strings and then relying on some code _not_ compiling should be left in 20th century for good.

I have a feeling you're talking about C macros, not C++ templates.

Re: Switching from C++ to Rust

#237

Post by hiccuphippo »

tcmart14 wrote: post #133
joenot443 wrote: post #75

Earlier quoted context omitted.

Swift has a similar Result type, it’s very handy.

Swift on linux is supposed to be decent server side, but as far as I've heard, not much use outside of that and even limited testimonials on that. The bit I have dabbled in Swift, I really like it. I just wish it grew more out of the Apple ecosystem. It has lots of things I like, but considering I can't exactly take it with me to any system and just run with it is why I have not dived to much into it.

Take a look at Zig (but it's not stable yet, may take a couple of years), linux is a first class citizen for it. It has `error!type` unions and `?type` optionals and language constructs to deal with them:

    const number = try parseU64(str, 10); // returns the error
    const number = parseU64(str, 10) catch 13; // default
    // more complex stuff
    if (parseU64(str, 10)) |number| {
        doSomethingWithNumber(number);
    } else |err| switch (err) {
        error.Overflow => {
            // handle overflow...
        },
        // we promise that InvalidChar won't happen (or crash in debug mode if it does)
        error.InvalidChar => unreachable,
    }

Re: Switching from C++ to Rust

#238

Post by gpderetta »

epage wrote: post #38

Background: C++ since around 1998, added in Python around 2008, Rust around 2016 While I agree with everything in the article, some times I wish I could have it both ways with: > First of all, generics without duck typing are greatly appreciated. Traits clearly indicate the contract struct or function expects from the type, which is great. This also helps compiler to generate helpful error messages. Instead of “inval…

The original C++0x concept proposal had concept checking, but had an escape hatch to instantiation-only checking when needed.

Re: Switching from C++ to Rust

#239

Post by chippiewill »

MathMonkeyMan wrote: post #94
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.

I was really excited for `std::variant`, when I actually got it I was seriously disappointed.

It's just a pain to use because of how much template magic is used.

Re: Switching from C++ to Rust

#240

Post by the_gipsy »

johnny22 wrote: post #99
mikebenfield wrote: post #86

Earlier quoted context omitted.

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.

What does php not have by now, is the question.
Post reply on HN