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

191–200 of 289 posts

Re: Switching from C++ to Rust

#191

Post by mejutoco »

fulafel wrote: post #155
mgsloan2 wrote: post #66

Earlier quoted context omitted.

In my experience with languages that lack concise sum types and pattern matching, you end up with data types that have lots of implicit invariants. If you find yourself writing docs or thinking in your head things like "Field X is only set if field Y is true" or "If field X is non-null then field Y must be null and vice-versa", then these are indications that sum types would model the data better. Then these invarian…

Type systems are of course not the only possible mechanism that can enforce these kinds of invariants. In dynamic languages, schema style solutions (eg malli or spec in Clojure) have advantages: they have more expressivity than typical type systems, you can manipulate them as data, you can use in contexts that are not statically verifiable, like at the data interfaces of yuor app.

I agree it has more flexibility, but more expressiveness is a double edged sword. Type systems are often not Turing-complete, or at least they are limited in some ways. A language being very expressive means it cannot be run at compile time, sine we cannot know if it terminates.

If we cannot run it at runtime now we need tests to hit that path or to test it manually to actually know if it works.

Re: Switching from C++ to Rust

#192

Post by DoctorDabadedoo »

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!

Hey, but I have this single header only spaghetti-code library here, super easy to include in your package, should be a breeze to use!

I'm with you, my sunken cost is 10 years, though.

Re: Switching from C++ to Rust

#193

Post by kaba0 »

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…

Thanks for the writeup!

Slightly unrelated, but re

> More to the point, the Wikipedia article for "sum type" redirects to "tagged union," which just honestly makes this more of a mess

I often see Wikipedia articles in CS topics severely lacking, or claiming exact definitions, when no such thing exists. Many definitions we regularly use are not exact at all, different papers/books use them differently, e.g. how would you even define OOP, low-level languages, etc? I would prefer them to use less strong language, as too many people argue on the internet based on Wikipedia definitions.

Re: Switching from C++ to Rust

#194

Post by ptman »

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…

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

Re: Switching from C++ to Rust

#195

Post by kaba0 »

dcow wrote: post #136
zabzonk wrote: post #72

Earlier quoted context omitted.

and you would use it ... how?

It's not exactly Java, but: Cons(1, Cons(2, Cons(3, Nil)))

Actually, Java does have sum types nowadays, and you can write a recursive list implementation like “new Cons(2, new Cons(3, Nil.nil()))”.

Here is a definition for a Maybe type, converting it to a List is left as an exercise to the reader :) : https://news.ycombinator.com/item?id=35133670

Re: Switching from C++ to Rust

#196

Post by kaba0 »

zabzonk wrote: post #59
nicoburns wrote: post #46

Earlier quoted context omitted.

Does your code ever contain class hierarchies with a fixed set of classes? Or variables where certain values have special case meaning? Those are the cases where Sum Types make things immeasurably nicer than the alternatives.

> Does your code ever contain class hierarchies with a fixed set of classes? no - one of the advantages of OO programing is that class hierarchies (should you feel the need to use them, which mostly i do not) can be expanded. or indeed contracted. > Or variables where certain values have special case meaning? very, very rarely (i would say never, in my own code) but of course we have the null pointer as a counter-exa…

The Visitor pattern, which is a must in certain niches is exactly analogous to pattern matching over a sum type, and I am fairly certain that I can objectively say that the latter is a million times more readable and maintainable.

It doesn’t make OOP obsolete, though, at all. Certain other areas are better expressed as hierarchies, e.g. GUI nodes.

Re: Switching from C++ to Rust

#197

Post by kaba0 »

cmrdporcupine wrote: post #54
zabzonk wrote: post #19

Earlier quoted context omitted.

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

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.

Re: Switching from C++ to Rust

#198

Post by kaba0 »

blub wrote: post #188
xiphias2 wrote: post #5

The most fun thing reading this comparision is again that for an experienced C++ programmer who is used to managing memory by hand (and fixing segfaults), Rust's memory model doesn't seem that hard, because it makes sense, and he understands why the checks are important.

Rust’s memory management is not hard, it’s just tedious. If programming in the future will mean annotating the crap out of everything then garbage-collected languages start to become attractive - see golang competing with Rust in unexpected areas. Perhaps the only hard part is storing and passing references everywhere, which may mean that one has to act like an automaton and patiently type their lifetimes to the Rust…

Well, a huge swath of the developer community did realize it like 20 years ago — the vast majority of applications can absolutely get away with a GC, and that’s the correct choice from the perspective of developer productivity and safety.

Rust is a huge win for the small niches where the GC overhead is unacceptable, because it is completely novel in its memory safety, which is absolutely a must and was neglected for way too long, but I never really understood the desire to use it for CRUD apps and the like. Sure, to each their own, but it is just an arguably bad choice. Even OSs could be written in managed languages - it’s not like it hasn’t been done before and they can just as well have escape hatches like Rust’s unsafe (hell, they are likely even safer if they are only used to manipulate “external heap”)

Re: Switching from C++ to Rust

#199

Post by IYasha »

> I feel more at piece shipping Rust code that C++ code.

More a piece? More in pieces? :D

I too got lots of crashes and UB in my life, but more because of pile-of-garbage architecture and interoperability than of language. (un)surprisingly, Rust emerged AFTER people learned their mistakes in C/C++ so it gets lots of attention and expectations.

Re: Switching from C++ to Rust

#200

Post by capableweb »

kaba0 wrote: post #187
delta_p_delta_x wrote: post #125

Earlier quoted context omitted.

> C++ enums can't have methods, even C++ 11 scoped enums ("enum classes") can't have methods, I have no idea why that restriction seemed like a good idea It is possible that Oracle holding the patent[1] to methods on enums is the blocker, rather than any technical restriction. [1]: https://patents.google.com/patent/US7263687

I am absolutely not a lawyer, but wouldn’t it fall into the “trivial” category, so even if patented, it couldn’t be enforced?

Problem is, unless it has been tried in court, you can't be certain. And if you're building something, you might not want to spend time in court having to fight it in the first place. So even if it's 50/50 enforceable/not enforceable, do you really want to spend the time testing if it is?

Patents really have a chilling effect, even if a particular one might not be enforceable.

Post reply on HN