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

281–289 of 289 posts

Re: Switching from C++ to Rust

#281

Post by otabdeveloper4 »

milesedgeworth wrote: post #268
otabdeveloper4 wrote: post #261

Earlier quoted context omitted.

A distinction without a difference, because "panics" and "exceptions" are literally the same code under the hood of the compiler and standard library. Fragile run-time behavior and unmaintainable code is because programming is hard and cruft accumulates in the face of difficult requirements. Renaming a thing that traumatized you in the past won't make the cause of the trauma go away.

Although the code generated might be similar, it's not a "distinction without a difference" because the language doesn't provide the same tools for interacting with panics as say C++ does with exceptions. There is no "try catch" for panics, you either catch them at the thread boundary or catch them with catch_unwind. Everything in the std lib is built with Result for errors that can be handled, not panic. Programming…

> you either catch them at the thread boundary or catch them with catch_unwind

So exactly like C++ exceptions then?

Re: Switching from C++ to Rust

#282

Post by endorphine »

burntsushi wrote: post #220
endorphine wrote: post #203

Earlier quoted context omitted.

Can someone elaborate on what sum types are and an example in Rust?

The section on "enums and pattern matching" in the Rust book is probably a good place to start: https://doc.rust-lang.org/book/ch06-00-enums.html A "Rust enum" is a sum type. Also, I talked about ASTs being a good example use case for a sum type. Here's a "real" version of an AST for a regular expression in all its complex glory: https://github.com/rust-lang/regex/blob/a9b2e02352db92ce1f6e... You can see that it star…

Are there other examples of sum types besides enums, in Rust? Are the two terms synonymous?

Re: Switching from C++ to Rust

#283

Post by steveklabnik »

endorphine wrote: post #282
burntsushi wrote: post #220

Earlier quoted context omitted.

The section on "enums and pattern matching" in the Rust book is probably a good place to start: https://doc.rust-lang.org/book/ch06-00-enums.html A "Rust enum" is a sum type. Also, I talked about ASTs being a good example use case for a sum type. Here's a "real" version of an AST for a regular expression in all its complex glory: https://github.com/rust-lang/regex/blob/a9b2e02352db92ce1f6e... You can see that it star…

Are there other examples of sum types besides enums, in Rust? Are the two terms synonymous?

Rust does not have sum types outside of enums. Other languages have sum types, and may or may not call them enums depending on the language.

Re: Switching from C++ to Rust

#284

Post by Volt »

klabb3 wrote: post #135
tcmart14 wrote: post #133

Earlier quoted context omitted.

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.

Is swift outside of Apple as fully fledged and performant when it comes to concurrency? Last I checked, a lot of the heavy lifting came from GCD (ie the Apple runtime-scheduler)

GCD is open source and runs on FreeBSD and Linux.

Re: Switching from C++ to Rust

#285

Post by blub »

burntsushi wrote: post #265
blub wrote: post #262

Earlier quoted context omitted.

How is it nonsense if you admit at the end (albeit after a straw-man of me allegedly screaming “abuse”) that it happens? Result is being sold on HN as a great solution to error handling while there’s several crates available which are needed to polish its rough edges, rough edges which have led to e.g. unwrap abuse in the past. It is tedious to shuffle around results, but this is never part of the sales pitch. And fo…

I didn't say "nonsense." I said "(partial) nonsense." If we use our powers of logical deduction, it therefore follows that I wasn't claiming that everything you said was nonsense. Hence the reason I added nuance to my comment, unlike yours. I'm trying to tease apart the convoluted mess you're making. You're aware of Brandolini's law, right? This is a microcosm of that. Some of what you're saying is bullshit, but not…

The Rust community always had a deep interest to sell Rust and did so through blog posts, comments and projects. I’ve seen this with many other languages on HN, but the zeal with which Rust is constantly shoved in the face of everyone is a tad more irritating than what I remember about what seemed to be grassroots interest in Ruby, Haskell or Objective-C.

When I read your top-level comment I don’t read a story from a random developer, I read an endorsement from a prominent member of the Rust community trying to paint Rust in a positive light, but conveniently omitting any negative aspects. This happens way too often to be a coincidence: the polite Rust developer educating others about the benefits of Rust may as well be a recurring character in this series.

Yet as companies actually start to use Rust and hit various problems, these are not given the same amount of attention. Obviously you don’t care about that, but this kind of submarine advertisement is a pet peeve of mine, so don’t be surprised if I continue to comment.

Re: Switching from C++ to Rust

#286

Post by blub »

dureuill wrote: post #182
blub wrote: post #171

Earlier quoted context omitted.

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

I just checked the old Rust classic “ripgrep” on github.

In matcher.rs, the enum is used as poor man’s OOP. I saw several match expressions which then call the same function on each matched type.

searcher/mod.rs is an error definition.

glob.rs contains a sort of policy enum which can be implemented once again with OOP or as a policy template.

json.rs usage can be modeled as a single class.

core/app.rs is more involved, but can be modeled as a series of structs with a map from enum -> any. Or as am std::variant. Or using OOP.

I looked at all instances and didn’t see anything game-changing. It’s a nice syntax and it should have really good performance, but such idioms are way too low-level to change any game.

Re: Switching from C++ to Rust

#287

Post by blub »

whyever wrote: post #185
blub wrote: post #171

Earlier quoted context omitted.

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.

You’ve described std::optional, a special case of std::variant.

Re: Switching from C++ to Rust

#288

Post by burntsushi »

blub wrote: post #285
burntsushi wrote: post #265

Earlier quoted context omitted.

I didn't say "nonsense." I said "(partial) nonsense." If we use our powers of logical deduction, it therefore follows that I wasn't claiming that everything you said was nonsense. Hence the reason I added nuance to my comment, unlike yours. I'm trying to tease apart the convoluted mess you're making. You're aware of Brandolini's law, right? This is a microcosm of that. Some of what you're saying is bullshit, but not…

The Rust community always had a deep interest to sell Rust and did so through blog posts, comments and projects. I’ve seen this with many other languages on HN, but the zeal with which Rust is constantly shoved in the face of everyone is a tad more irritating than what I remember about what seemed to be grassroots interest in Ruby, Haskell or Objective-C. When I read your top-level comment I don’t read a story from a…

That is Grade-A-nonsense.

So what I'm getting from your comment is that it's not possible to say something positive about a project like Rust unless all commensurate trade offs are accounted for. Otherwise, the comment is a "submarine advertisement"? I didn't pipe into a conversation about non-Rust. The OP is about Rust. The OP mentioned sum types. I commented endorsing what OP said and to call extra attention to it, because sum types (with pattern matching and exhaustiveness checking) are amazingly useful. I also legitimately do not believe they have many downsides, if any at all. They might have downsides within the context of a particular language design (for example, Go, where their interaction with default values and interfaces would potentially be quite weird). But in general, no, sum types are pretty close to an unmitigated good thing in my view.

Does Rust writ large have downsides? Oh absolutely! So unless you're telling me I need to exhaustively enumerate every downside of Rust every time I mention something positive, then I don't know what you're getting on about.

> so don’t be surprised if I continue to comment.

That's not surprising? You've been posting low quality commentary in Rust threads for literal years. If there are people sick of the "advertising" for Rust, then there are also people who are sick of the people whinging about it. What would be surprising is if you started posting well informed productive comments in Rust topics.

Re: Switching from C++ to Rust

#289

Post by burntsushi »

blub wrote: post #286
dureuill wrote: post #182

Earlier quoted context omitted.

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

I just checked the old Rust classic “ripgrep” on github. In matcher.rs, the enum is used as poor man’s OOP. I saw several match expressions which then call the same function on each matched type. searcher/mod.rs is an error definition. glob.rs contains a sort of policy enum which can be implemented once again with OOP or as a policy template. json.rs usage can be modeled as a single class. core/app.rs is more involve…

This is a straw man. There is nobody on this Earth claiming that sum types are necessary to solve a problem. Product types aren't necessary either. You could just write everything in Assembly. Or maybe raw bytecode if you want.

As should be patently fucking obvious to anyone who has been commenting on a technology web site for as long as you have, sum types are a tool. They are a tool for expressing clearly and concisely the idea that a value can be exactly one of several possible options. That tool then interacts with the rest of the language based on that invariant, sometimes providing things like exhaustiveness checking and pattern matching. Put all this together, and you have a very succinct and very clear way of representing certain kinds of values in a program.

Your comment might as well go through ripgrep and talk about how functions aren't needed. "They could have just used goto here and there."

> I looked at all instances and didn’t see anything game-changing. It’s a nice syntax and it should have really good performance, but such idioms are way too low-level to change any game.

Sum types were game changing to me when I learned about them over a decade ago. Since then, they have been a significant factor in how I think about and structure data in programs.

I have zero interest in trying to convince someone like you that you should think it's game changing. That's not the point. Maybe you could do some perspective taking and realize that others might just think differently than you.

Post reply on HN