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

111–120 of 289 posts

Re: Switching from C++ to Rust

#111

Post by pornel »

jcranmer wrote: post #64
jesse__ wrote: post #2

Nice to see some level-headed anecdotes on the experiences of actually _using_ each language, as opposed to the usual "z0mg rustc fixez all yur mem0ry bUgz!!111one" And, as someone who's spelunking in the depths of a large CMake project right now, cargo sounds pretty nice.

Cargo is definitely a more pleasant build system than anything the C/C++ world has, until you fall off the happy path. One of the pain points of trying to design a build system for C/C++ is that a lot of projects do weird stuff that needs to be supported in build systems, which means you end up needing escape hatches to do that weird stuff all over the place. Cargo takes a narrower view, which means it doesn't attemp…

I think Cargo is more of a social success than a technical one. People just agreed to use one standard tool, and that does wonders.

Technically nothing stops C++ from having the same, except getting everyone to agree on one tool.

Re: Switching from C++ to Rust

#112

Post by cdcarter »

zabzonk wrote: post #90
cornstalks wrote: post #77

Earlier quoted context omitted.

Pretend we have the following sum type: enum SumType { Foo(foo), Bar(bar), Baz(baz), } void DoSomething(SumType sum_type) { match sum_type { Foo(foo): foo.do_x(); Bar(bar): bar.do_y(); Baz(baz): baz.do_z(); } } This could be lowered to: struct LoweredSumType { optional foo; optional bar; optional baz; } void DoSomething(LoweredSumType sum_type) { if (sum_type.foo.has_value()) { sum_type.foo->do_x(); } else if (sum_ty…

> Pretend we have the following sum type: which looks remarkably like a union to me, if i understand your made-up language.

It's not a union, though, it stores references to three memory locations, not just one (as a union represents a single memory location which can have multiple possible interpretations). And the lowered code has nothing protecting it from an invariant where more than one reference is non-null!

Re: Switching from C++ to Rust

#113

Post by signa11 »

burntsushi wrote: post #84
zabzonk wrote: post #27

Earlier quoted context omitted.

[flagged]

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…

this is just ... beautiful ! thank you !

Re: Switching from C++ to Rust

#114

Post by pclmulqdq »

girvo wrote: post #28
xiphias2 wrote: post #20

Earlier quoted context omitted.

I was just trying to find a modern C++ tutorial, but there's nothing comparable to the Rust Book on the internet. I think even now the best resource to learn C++ is to first learn C, then original C++, then all the modern memory management techniques, which is just crazy hard for a new programmer compared to just going through the Rust book 10 times (which is needed to get a deep understanding).

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.

1072 pages sounds like it's a little too thin to actually teach modern C++.

I'll let you decide whether this is sarcasm - I could go either way.

Re: Switching from C++ to Rust

#116

Post by aw1621107 »

gnulinux wrote: post #87
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…

This is exactly what I think too. Sum types are so powerful, I feel a lot safer in Python + mypy with sum types (`from typing import Union`) than anything with C++ [1] even though C++ has a significantly more complex type system (it's type system is TC) and Python is as type-unsafe as a language can get. C++ made this odd choice as if any complex type system is better than a simple type system. When I was a younger s…

> even though C++ has a significantly more complex type system (it's type system is TC)

For what it's worth, Python's type hints are also Turing complete (https://arxiv.org/abs/2208.14755, discussed on HN at https://news.ycombinator.com/item?id=32779296)

Re: Switching from C++ to Rust

#117

Post by noobermin »

burntsushi wrote: post #109
noobermin wrote: post #104

Earlier quoted context omitted.

Can you explain the utility of them over unions then? Asking sincerely.

Unfortunately it's actually kind of difficult to parse your question because of the ambiguity in the surrounding comments. You could mean "tagged union" instead of "union," or maybe not and "them" means "tagged union"... If you're asking to compare tagged unions and unions, then... A union is not a tagged union. A union is part of a tagged union. A union on its own is just a region of memory. What's in that memory? I…

Sorry, yes I meant tagged union, a C style union (as in the language's concept) is so useless by itself that I thought being tagged was an obvious given.

In that case, the pattern matching and exhaustiveness means that the value the sumtypes in rust offer is in combination with those other language features, not the mere usage of the sumtypes themselves then, I think that makes more sense.

Re: Switching from C++ to Rust

#119

Post by jnwatson »

jhatemyjob wrote: post #95

[flagged]

He didn't claim expertise. It is actually more interesting to me to hear someone's opinion with a medium level of expertise in the language. We've had plenty of experts and beginners already weigh in.

English isn't a first language for everyone.

Sounds like you need a break.

Re: Switching from C++ to Rust

#120

Post by burntsushi »

noobermin wrote: post #117
burntsushi wrote: post #109

Earlier quoted context omitted.

Unfortunately it's actually kind of difficult to parse your question because of the ambiguity in the surrounding comments. You could mean "tagged union" instead of "union," or maybe not and "them" means "tagged union"... If you're asking to compare tagged unions and unions, then... A union is not a tagged union. A union is part of a tagged union. A union on its own is just a region of memory. What's in that memory? I…

Sorry, yes I meant tagged union, a C style union (as in the language's concept) is so useless by itself that I thought being tagged was an obvious given. In that case, the pattern matching and exhaustiveness means that the value the sumtypes in rust offer is in combination with those other language features, not the mere usage of the sumtypes themselves then, I think that makes more sense.

Yes. When you say "sum type" and you're talking about, say, Ocaml or Standard ML or (mostly) Haskell or Rust, then what comes with that is also the infrastructure around sum types in those languages. They aren't really separable. That includes pattern matching and exhaustiveness checking (the latter is an opt-in warning in Haskell, and can be opted out of in Rust on a per-type basis).

The discussion around "sum type" the concept is to disentangle it from the implementation strategy. Tagged unions are the implementation strategy, and they don't come with pattern matching or exhaustiveness checks.

Of course, many of these terms are used interchangeably in common vernacular. But if you look at the comment that kicked off this annoying sub-thread:

> so, um, unions? i have to say that in many years of programming, i have almost never needed to use such types.

Then this is clearly trying to draw an equivalence between two different terms, but where no such equivalence exists. There's no acknowledgment here of the difference between what a "union" is (nevermind a tagged union) and the "sum types" being talked about in my original top level comment. And the last part, "i have almost never needed to use such types" is puzzling on multiple levels.

Post reply on HN