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

201–210 of 289 posts

Re: Switching from C++ to Rust

#201

Post by tialaramex »

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…

The privacy boundary applies in both cases by the way. Despite labelling your AmericanCity enum as #[non_exhaustive] since it only has Houston and Chicago in it so far, you are allowed in your own code inside the boundary to write a match which handles only Houston and Chicago. And that's actually probably a good idea, because when you add SanFrancisco to the enum, the compiler will point out anywhere your match clauses don't handle it, whereas if you had a default case (as your 3rd parties will) you'd drop into the default.

Re: Switching from C++ to Rust

#203

Post by endorphine »

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…

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

Re: Switching from C++ to Rust

#205

Post by staunton »

ryandrake wrote: post #60
staunton wrote: post #17

Earlier quoted context omitted.

The overhead is the same. Rust just takes care that you're doing it right, while C++ lets you shoot your foot off in this area.

I know this is an unpopular opinion but if you want to stick with C++, the solution to this, at least in my experience, is to stop doing things that let you shoot your foot off. C++ gives you every tool in the tool chest, and most of them are not safe. Stick to a safe subset and you've solved 90% of all those stereotypically C++ problems. I've got a pretty big C++ codebase for my hobby projects, sanded down, polished…

Yes, of course. If you use C++, try to not shoot your foot off. The same advice also applies to Rust or any other programming language. You should still try to follow best practices and not mess up, even if a language makes it less likely to mess up in certain ways.

The question is how often you mess up in each language and how bad those mess-ups are. This depends a lot on the programmer(s) and the kind of project. My personal view is that the space of team/project combinations where you should ever start a new C++ project is now confined to "team desperately wants C++".

Re: Switching from C++ to Rust

#206

Post by girvo »

thefourthchime wrote: post #134
girvo wrote: post #28

Earlier quoted context omitted.

Professional C++ is the 1072 page book that taught me modern C++, for what it's worth. I have the physical copy. And even then I have gripes with some of it's contents! The Rust book is second to none, tbh, and I say this as someone who doesn't really write Rust.

As someone who wrote C++ for 20 years, just don't. It's a horrible language(s). None of the codebases look the same, everyone uses different features or different versions of the language. Building is a nightmare, it takes forever to do anything. Run!

100% agreed. Though the work I do pays very well!

Re: Switching from C++ to Rust

#207

Post by girvo »

n8henrie wrote: post #126
girvo wrote: post #35

Earlier quoted context omitted.

Right, though Espressif's official support for anything should be taken somewhat with a grain of salt ;) Having used their tools at work in anger for years at this point, there is a lot of gotchas, issues and bugs with their bindings at this point -- not all of which is Rust's fault, but the underlying problems with ESP-IDF itself. That said, its getting better over time, so I'm keeping a close eye on it (and we keep…

Doesn't the ESP32C3 have native rust support -- no esp-idf or espressif official support concerns need apply? Are you stuck on the S3 exclusively?

We are stuck on the S3, yeah. The C3 is lovely, but doesn’t have everything we require, at least currently. Might change in the future but not right now.

Re: Switching from C++ to Rust

#208

Post by girvo »

phendrenad2 wrote: post #107
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?

ESP-IDF is pretty dependant on it, sadly. I’m halfway through getting to the point where I can build it without!

Re: Switching from C++ to Rust

#209

Post by staunton »

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…

> 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

That doesn't sound right to me. Do you have a source? Is that in the standard?

Re: Switching from C++ to Rust

#210

Post by tialaramex »

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…

I strongly recommend just writing a #[derive] line for every user defined type you make. Start off with Debug in there, and you'll find often you already know some other traits that'll be trivially derived for this type, Clone, Default, stuff like that.
Post reply on HN