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

261–270 of 289 posts

Re: Switching from C++ to Rust

#261

Post by otabdeveloper4 »

cornholio wrote: post #157
otabdeveloper4 wrote: post #141

Earlier quoted context omitted.

"Panic" and "exception" is literally the same thing. Sorry you were misled, but programming is, indeed, hard, and no, you can't go shopping instead.

A panic is an unrecoverable error caused by violating runtime invariants. A bug exists in the program and there is no (correct) way for the program to continue execution. For example, an array was accessed at index "-1". Exceptions are a particular technique for dealing with errors in general, that can be used for both unrecoverable and recoverable errors. They infamously trade programmer convenience for hard to unde…

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.

Re: Switching from C++ to Rust

#262

Post by blub »

burntsushi wrote: post #242
blub wrote: post #183

Earlier quoted context omitted.

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.

For other folks following along and possibly getting mislead by this (partial) nonsense, I'd encourage you to read a blog post I wrote about the topic of unwrap. I think it should clear up most things: https://blog.burntsushi.net/unwrap/ At a meta level, one of the reasons why there is so much focus on 'unwrap()' in particular is because it is often the precise point at which in your code where a runtime invariant is…

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 for those of us that don’t want to depend on all sorts of crates for the simplest things, that’s the reality.

Re your reply “Maybe improve your reading comprehension. I said "(partial) nonsense." Therefore, some of what you said wasn't nonsense. But some is. What a fucking revelation.”

Partial nonsense isn’t nonsense by definition, I believe, but I won’t dwell that point. I am surprised seeing a Rustacean being (mildly) offensive and even saying the f-word. I must say that I am proud of you, too many nowadays act like polite, pedantic robots. :-)

Re: Switching from C++ to Rust

#263

Post by [deleted] »

blub wrote: post #262
burntsushi wrote: post #242

Earlier quoted context omitted.

For other folks following along and possibly getting mislead by this (partial) nonsense, I'd encourage you to read a blog post I wrote about the topic of unwrap. I think it should clear up most things: https://blog.burntsushi.net/unwrap/ At a meta level, one of the reasons why there is so much focus on 'unwrap()' in particular is because it is often the precise point at which in your code where a runtime invariant is…

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…

[deleted]

Re: Switching from C++ to Rust

#264

Post by loeg »

mgraczyk wrote: post #108
loeg wrote: post #43

Earlier quoted context omitted.

Yeah. In the C++ codebase I work on, we use folly::Expected (essentially similar to Rust's Result ) heavily. Is it as ergonomic as Result is in Rust? Absolutely not. But it's still a nice design pattern for some of the same reasons people use Result in Rust. (And C++ std::optional is somewhat similar to Rust's Option type.) https://github.com/facebook/folly/blob/main/folly/Expected.h...

Worth mentioning that C++23 adds something very similar to the standard library, called std::expected. https://en.cppreference.com/w/cpp/utility/expected Unfortunately it does not come with nice syntax to return on error.

Nice.

> Unfortunately it does not come with nice syntax to return on error.

Yeah. We use a C preprocessor macro for this, but it's a little more verbose than question-mark operator.

Re: Switching from C++ to Rust

#265

Post by burntsushi »

blub wrote: post #262
burntsushi wrote: post #242

Earlier quoted context omitted.

For other folks following along and possibly getting mislead by this (partial) nonsense, I'd encourage you to read a blog post I wrote about the topic of unwrap. I think it should clear up most things: https://blog.burntsushi.net/unwrap/ At a meta level, one of the reasons why there is so much focus on 'unwrap()' in particular is because it is often the precise point at which in your code where a runtime invariant is…

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 quite all of it, and aspects of it are rooted in truth and reasonable experiences. (For example, I also do not "depend on all sorts of crates for the simplest things.")

My tactic is to present nuance. You come back to me and instead of actually engaging with the nuance, starting whinging about what's being "sold on HN." Yawn.

> It is tedious to shuffle around results, but this is never part of the sales pitch.

This is a good example. Your sentence starts with something that I wouldn't agree with as a general rule, but I could certainly see it being true in specific circumstances. And even then, I'd want to explore those circumstances. That is, is it really a property of `Result` that makes it tedious, or is the problem of error handling in that context itself? It could be either.

But then you follow it up with whinging about "sales pitch." Are you talking about some kind of sales pitch put out by the Rust project? Because if so, please link it to me. Or are you talking about a bunch of random HN commentators that can be overzealous about just literally anything? I don't see anyone saying Result is the best thing since sliced bread. What I do see are people describing positive experiences with it, especially in relationship to alternative error handling paradigms. Is that really a sales pitch?

I mean, look at my top-level comment in this entire post. I sang the praise of sum types, and I did it by echoing what the OP said. Is that a sales pitch? Am I saying that sum types are the "best" at something? Am I saying that they have literally no costs at all? Am I saying that useful programs can't be written without sum types? Am I saying that all languages should be designed to include sum types?

No. No. No. No and no. Did some other people go a touch too bar and make broad pronouncements about "correct" language design? Oh yeah, absolutely. Are those people some kind of singular phenomenon unique to Rust? Fuck no. And it is absolutely fucking baffling that I need to explain that to someone who has been on HN for as long as you have. This observation is so banal that it's blub.

Re: Switching from C++ to Rust

#266

Post by blub »

3836293648 wrote: post #181
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…

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

Most of your types? Well that certainly deserves congratulations and I hope someone will take advantage of the opportunity.

I think you misunderstood me though if you say I haven’t used them properly. I just didn’t need them or find them that useful because it rarely happens that I want to model a type which has several states.

Specific variant types like std::optional or the Result-equivalents are useful, but not that game changing either. They’re nice I suppose.

I wonder what kind of software you write that such low-level coding idioms make a big difference to the end result. Or what do you mean by game changing?

Re: Switching from C++ to Rust

#267

Post by shakow »

School-Cotton wrote: post #251
shakow wrote: post #249

Earlier quoted context omitted.

> Indexing into a vector unwraps That's what it's supposed to do, RTFM. Use .get() for safe access.

Er, yes I know, I use rust every day as a primary language. I was just giving an example, not claiming it wasn’t documented.

Then what is the issue if you know both the “fast-but-panicking” and “slow-but-Option-ing” versions?

Re: Switching from C++ to Rust

#268

Post by milesedgeworth »

otabdeveloper4 wrote: post #261
cornholio wrote: post #157

Earlier quoted context omitted.

A panic is an unrecoverable error caused by violating runtime invariants. A bug exists in the program and there is no (correct) way for the program to continue execution. For example, an array was accessed at index "-1". Exceptions are a particular technique for dealing with errors in general, that can be used for both unrecoverable and recoverable errors. They infamously trade programmer convenience for hard to unde…

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 is hard, but that doesn't mean that certain language design choices don't have meaningful impact on what type of code becomes easier/harder to write. Other people are saying similar things, and I ask you listen to what they're saying, rather than talking about people being "traumatized" by a programming construct.

Re: Switching from C++ to Rust

#269

Post by School-Cotton »

shakow wrote: post #267
School-Cotton wrote: post #251

Earlier quoted context omitted.

Er, yes I know, I use rust every day as a primary language. I was just giving an example, not claiming it wasn’t documented.

Then what is the issue if you know both the “fast-but-panicking” and “slow-but-Option-ing” versions?

First of all, neither is faster than the other.

Second, I never claimed it was an issue or a bad thing at any point. Someone asked for examples of libraries that panic, and I gave an example.

I must be missing something because it makes no sense to me that people seem to be responding defensively and claiming that I either don’t understand the Rust docs or am pointing out problems in Rust.

Re: Switching from C++ to Rust

#270

Post by tcmart14 »

hiccuphippo wrote: post #237
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.

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

I've been checking out Zig over the past week. It is a really nice language and I like so far. Just not spending as much time as I'd like in it since it is still pre-1.0, but I am excited for it's 1.0.
Post reply on HN