Live data from Hacker News

Switching from C++ to Rust

laplab.me

221–230 of 289 posts

Re: Switching from C++ to Rust

#221
post #183

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.

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.

Somehow I must've been lucky enough to avoid this unwrap abuse in crates I use.

I think you maybe meant converting between errors in Rust can be tedious sometimes, but propagation is pretty easy.

The conversation is something that generally need's to happen rarely (like a few times per project?), but `thiserror` and `from` make this pretty ergonomic.

Re: Switching from C++ to Rust

#222
post #194

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…

Go generics allow all kinds of things https://github.com/samber/mo

I'm aware. I wrote go-sumtype long before Go got generics.

Re: Switching from C++ to Rust

#223
post #213

Earlier quoted context omitted.

You can do that with go too, there are libraries out there. But it's all a joke compared to real support in the language.

Real support like what Java has? It literally has sealed classes and interfaces that specify all the possible classes that can subtype it. This is enforced by the language and allows for things like exhaustive switch cases. Pattern matching is a related feature which is also available in Java now, though as of yet only limited to records.

So it's a Frankenstein monster, with no real pattern matching support. Good luck with using it in the real world.

Re: Switching from C++ to Rust

#224

Earlier quoted context omitted.

The standard library is one example. Indexing into a vector unwraps, as do many other stdlib functions.

the docs[0] are clear: > be careful: if you try to access an index which isn’t in the Vec, your software will panic! > Use get() and get_mut() if you want to check whether the index is in the Vec. In my experience, most people are using get() if the source of the index is untrusted [0]: https://doc.rust-lang.org/std/vec/struct.Vec.html#indexing

A lot of these Rust complaints are just people not reading the docs (not trying to say Rust doesn't have legitimate usage friction; of course it does).

Pro tip: most popular crates have excellent documentation (I know it's a shocker coming from other languages). So, check stuff before you use it.

I assume this is because the ecosystem lowers the barrier to entry for writing an generating documentation (compared to other ecosystems).

Re: Switching from C++ to Rust

#225
post #41

Earlier quoted context omitted.

If the lack of some services allows it (maybe not given the chip, but it was enough for me) I recommend using esp-hal+esp-wifi rather than esp-idf-hal, it is a pure rust 'rewrite' and it's been a great experience compared to esp-idf(c++). Default is bare-metal but embassy resolves most of the need of an rtos.

I don't know what the issue is but I've tried esp-wifi on the ESP32-C3 with the examples and nothing would run. It's a bummer since I'd have liked to leverage the Bluetooth support for my project.

Esp-wifi is very actively being updated, looks like C3 is supposed to work[0][1], so if you tried more than a few weeks ago it probably changed.

[0]: https://github.com/esp-rs/esp-wifi#current-support [1]: https://github.com/esp-rs/esp-wifi#ble

Re: Switching from C++ to Rust

#226

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! :)

Since I've heard of this idea, I keep finding places where id use it, whether that be for variant-specific behavior or to remove the redudant type definitions in my API.

Re: Switching from C++ to Rust

#227
post #197

Earlier quoted context omitted.

The C++ (or Java etc) way to do many of the kind of things people do with Rust pattern matching & sum types would be via OO subtyping polymorphism. e.g. classic visitor pattern, etc. Way more verbose and awkward, and scatters the logic all over the place. Enums + switch is the other, and far less powerful.

I swear I am not paid to shill for Java or anything…, but Java did get sum types recently, and it’s quite good. They made it in a backwards compatible manner by sealed classes that list all of its subtypes. Switch expressions were also implemented, and they can exhaustively match on the given sum type. Pattern matching is quite limited as of now (only usable with records), but it is coming.

I should take a look. I kind of have a nostalgic interest in looking back at the JVM again, as 10 years ago it was my main career.

The problem with Java was always that it has moved so slowly in acquiring nice things. The actual core runtime is amazingly well engineered.

Re: Switching from C++ to Rust

#228

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?

[deleted]

Re: Switching from C++ to Rust

#229
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.

Generally I do. My comment isn't about whether my own types are `Debug` but others on top of several other problems.

Re: Switching from C++ to Rust

#230

Earlier quoted context omitted.

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?

I don't know about the standard, but if cppreference.com is good enough: At https://en.cppreference.com/w/cpp/language/union it says "If two union members are standard-layout types, it's well-defined to examine their common subsequence on any compiler."
Post reply on HN