Hacker News Reader

Comment by ebingdom | Hacker News Reader

I'm pleasantly surprised by these comments. A few years ago people were so entrenched in their object-oriented upbringing that sum types were considered "weird functional stuff" and thus unsuitable for "real" work (what a shame to have that attitude). People are finally coming around to good ideas from other paradigms.

Rust's popularity is certainly helping that, though I wish they hadn't repurposed the existing word "enum" to serve as a new synonym for a concept with an existing name ("algebraic data types").

View on HN

> A few years ago people were so entrenched in their object-oriented upbringing that sum types were considered "weird functional stuff"

A step further: I was hearing talk of enums being a code smell and that they should all be replaced with interfaces as they represented alternative implementations and you might want to be more extensible or insert a mock for testing

As an aside, tagged unions weren't a big deal to me (though I thought it neat to merge tagged unions with enum constants) but what blew me away was when I learned they could have methods and implement traits. Would love it if Rust took it a step further and made the variants types. There are cases were id like to have builder methods on variants. The closest I can get is having an explicit struct and implementing From to the enum. Also wish there was variant visibility so I wouldn't have to wrap my enums in structs to hide the variants.

“algebraic data types” includes product types (aka structs, classes and tuples) as well as sum types (aka enums and probably other names)

Rust's "enums" also include products. Each case can have multiple arguments. That's a sum of products. "Algebraic data type" is the proper term for what Rust calls "enums", since they encompass both sums and products.

(It is also true that structs are products. But that isn't relevant.)

Rust's syntax makes plenty of concessions to familiarity, as a way of making up for the much more important and irreducible unfamiliarity that it brings to the table (e.g. ownership). Originally Rust used the keyword `tag` here (for "tagged unions"), then vacillated between `enum` and `union` for years and years prior to 1.0.

I also like sum types, but I have intense whiplash from "this language is AN ABSTRACT MESS that needs a PhD in type theory to use productively" five years ago, to today's "this language is COMPLETELY USELESS because it doesn't have them".

I don't think anyone ever struggled with sum types (or at least, I hope not), they associated them with things like Haskell's monads, which are less commonly accessible (though they're undeserving of their reputation too). The hate was a little silly, but algebraic data types are clearly just an extension of the concepts everyone already knew.

> I don't think anyone ever struggled with sum types... algebraic data types are clearly just an extension of the concepts everyone already knew.

You're definitely in a bubble.

I can't count the number of C++ codebases I've worked on where either myself or some other engineer implemented an ad-hoc, incomplete "sum type-like" enumeration system, e.g. in linting, pre-compilers, etc. In my case, I've done it without even knowing what these were--my background is physics, not computer science. The concept isn't terribly difficult to understand, even if the jargon name for it isn't widely known, or is associated with more type-theory oriented languages.

Rust is an abstract mess that needs a PhD (or type theory or guess-and-check) to use productively; it's more to do with overuse of generics and wildcard trait impl and trait resolution and higher-order functions and lifetime HKTs and reverse type inference, than sum types. Rust enums require less generics to use productively than C++ std::variant (which requires std::get_if or std::visit), because enums have language-level `match` and `if let` syntax as a fundamental binding block which can take the place of combinator method chaining (but the community instead sees it as an opportunity to invent and add even more methods).

> Rust's popularity is certainly helping that, though I wish they hadn't repurposed the existing word "enum" to serve as a new synonym for a concept with an existing name ("algebraic data types").

What keyword would you prefer they use instead, "datatype" like SML?

If I were designing a language I'd call them or-types, to indicate a type that is "this OR that", as distinct from and-types, which are "this AND that". The product vs. sum terminology strikes me as needlessly forbidding, although it is undoubtedly cute that one can extrapolate algebraic data types to calculus and such.

>> Rust's popularity

Is Rust actually popular? I know that question is inviting downvote oblivion on here but on the off chance of attracting a thoughtful comment (and because I secretly want to really fall for rust, i love the idea and think we badly need the next step on from C-based foundations, but the pragmatic side of me just rolls around laughing at rust) here’s where i’m coming from:

    - There’s not much in the way of job postings
    - There’s no halo product yet, servo appears to have gone nowhere? If it makes it into Linux *that* will launch the lang for sure
    - There’s no halo company championing it, mozilla has never moved away from churning out c++ and js primarily, microsoft made some noise but then crickets
    - it’s been around about as long as Go yet its google trends search traffic is around 1/16th that of Go’s
    - The only large rust code bases on github are servo and the rust compiler/stdlib itself

The only metric i can find where rust scores well is the stack dev survey and the number of tutorials posted online. If there was actual traction alongside these two metrics, rust would be a rocketship. But without any obvious successes in the world so far, it’s beginning to look like a handy way to identify devs susceptible to stockholm syndrome.

There’s all sorts of weird signs in the community that makes me think the median rust “user” has a rust career something like:

    1. Downloaded rust
    2. Installed the wrong plugin in VSCode (why is the correct plugin - rust analyzer - so low on downloads and votes, yet the dead plugin is still getting tons of traffic? Is noone actually reading the documentation?)
    3. Followed a hello world tutorial, marveled at the genuinely awesome compiler errors
    4. Full of enthusiasm, started a side project and… gave up after a few nights but who knew, they wanted to solve a problem not add lifetimes onto the existing stack of problems to wrestle with.

AFAICT the future’s not looking bright for rust right now. It’s coasting on a wave of enthusiasm from relatively junior developers who aren’t making impressive things with the language yet.

This is a strongly typed language with lifetimes understood by the compiler - that’s a rocket suit compared to a language like the tire fire that is javascript. Enums? Pah excuse me while i pass a string literal…

With this rust exo-skeleton surrounding a developer, it should be unlocking the ability to manage 10million+ LOC code bases like it’s hello world.

Reframing your question, it's incredibly impressive how popular Rust has become without a halo product, halo company, etc. Rust proponents will readily argue that Go is only as popular as it is because of being championed by Google. Meanwhile Rust has had to grow to the place where it is organically.

My personal belief is that over time Rust will inevitably eclipse C and C++. But it will take time. C and C++ will never fully go away, but projects that would have been written in them will be over time be preferentially written in Rust. The Linux kernel starting to write drivers in it is a harbinger of this, and once that effort has made it into released kernels we'll quickly start to see other parts of the kernel adopt Rust.

> AFAICT the future’s not looking bright for rust right now. It’s coasting on a wave of enthusiasm from relatively junior developers who aren’t making impressive things with the language yet.

Frankly this is my perspective of Go, which is (from my vantage point) mostly popular amongst junior developers. Rust is not even remotely marketed towards novices, and in many of the communities it's openly acknowledged that it's perhaps not the best choice for someone just setting out. C and C++ programmers are the ones primarily flocking toward Rust, while Python, Ruby, and Node developers are the ones who are primarily adopting Go as they're starting to see the value of static types, even as anemic as Go's type system is.

Anecdotally I know many, many engineers who have grown disillusioned with Go once they've worked on larger projects and had to repeatedly reinvent wheels that other languages provide as built-in features. Many of those engineers have gone on to champion Rust, and the flow of engineers between those two languages from my point of view heavily favors Rust.

But without a big champion like Microsoft, Google, or Sun/Oracle, this growth is going to happen organically and take time. Maybe there will be an enormous driver like Kubernetes for Go, Rails for Ruby, or ML for Python, but even without that I think Rust will gradually continue to snowball.

>> incredibly impressive how popular Rust has become

But it hasn’t become popular yet, it’s not competing with something like Go or C++, it’s competing with Erlang or Clojure for popularity

https://madnight.github.io/githut/#/pull_requests/2021/4

P.s. thumbs up, that was a thoughtful reply! But the predictable down votes arrived too :-)

Mozilla and Firefox.

Or do you think anyone would care if it was some random joe/jane posting about this Rust language they were developing.

Reply on news.ycombinator.com