Hacker News Reader

Comment by jghn | Hacker News Reader

Meta comment.

Something I've wondered of late. I keep seeing these articles pop up and they're trying to recreate ADTs for Python in the manner of Rust. But there's a long history of ADTs in other languages. For instance we don't see threads on recreating Haskell's ADT structures in Python.

Is this an artifact of Rust is hype right now, especially on HN? As in the typical reader is more familiar with Rust than Haskell, and thus "I want to do what I'm used to in Rust in Python" is more likely to resonate than "I want to do what I'm used to in Haskell in Python"?

At the end of the day it doesn't *really* matter as the underlying construct being modeled is the same. It's the translation layer that I'm wondering about.

View on HN

(Author of the post.)

I think so, in the sense that Rust has successfully translated ADTs and other PLT-laden concepts from SML/Haskell into syntax that a large base of engineers finds intuitive. Whether or not that’s hype is a value judgement, but that is the reason I picked it for the example snippet: I figured more people would “get” it with less explanation required :-)

Got it. It makes sense and was what I figured is the case. I find it interesting as it's a sign of the times watching the evolution of what the "base language" is in threads like this over time. I mentioned in another comment that several years ago it'd have been Haskell or Scala. If one went back further (before my time!) it'd probably have been in OCaml or something.

In my experience learning a bit of OCaml after Rust, and then looking at Haskell, the three aren't all that different in terms of the basics of how ADTs are declared and used, especially for the simpler cases.

Agreed. As a concept they're all the same thing.

Another way of phrasing my query is that given these are all basically ML-style constructs, why would the examples not be ML? And I was assuming the answer to that is "the sorts of people reading these blogs in 2024 are more familiar with Rust"

I think a second reason might be that translating OCaml/Haskell concepts to Python has that academic connotation to it. Rust also (thanks to PyO3) has more affinity to Python than the ML languages. I guess it isn't a surprise that this post has Python, C++, and Rust, all "commonly" used for Python libraries.

Apologies for my meta-meta-comment :) I've been writing code for ~30 years in various languages, and today my brain can't compute how people find any syntax other than this more intuitive:

  data Thing
    = ThingA Int
    | ThingB String Bool
    | ThingC

To me, the above syntax takes away all the noise and just states what needs to be stated.

I think "hype" has some connotations that I wouldn't necessarily agree with, and I don't think it's as much "on HN" as "people who write Python," but I would agree that I would expect at this point more Python folks to be familiar with Rust than Haskell, and so that to be the reason, yes.

The reason I said hype is that it's a cycle here. If you go back 10 years every example *would* have been in Haskell. Or perhaps Scala. They were the cool languages of the era. And the topics here painted a picture that their use in the broader world was more common than they really were. And I say that as someone who used both Haskell & Scala in my day job at the time. HN would have you believe that I was the norm, but I very much was not.

That's not to say it's bad, or a problem. If it gets more people into these concepts that's great.

It is quite common to see people in Rust circles mentioning Rust being innovative for feature XYZ, that was initially in a ML variant, Ada, Eiffel, ....

I would say familarity, and lack of exposure to programming languages in general.

Nowhere in this post or in any Rust community post I'm aware of does anybody claim that sum types (or product types, or affine/linear types, etc.) are a Rust novelty.

As a stretch, I've seen Rust content where people claim that Rust has successfully popularized a handful of relatively obscure PLT concepts. But this is a much, much weaker claim than Rust innovating or inventing them outright, and it's one that's largely supported by the size of the Rust community versus the size of Haskell or even the largest ML variant communities.

(I say this as someone who wrote OCaml for a handful of years before I touched Rust.)

Where did I specially mentioned it was this post, and not in general?

Here is another common one, "It would be great a Rust like but with GC".

> Here is another common one, "It would be great a Rust like but with GC".

What in this phrase suggests or implies that Rust has innovated something that an earlier FP language actually did? Something that resembles Go's managed runtime but with Rust's sum types seems like a very reasonable thing to want, and doesn't exist per se without buying either into a very foreign syntax and thus a much smaller community and library ecosystem.

(Or as another phrasing: what is actually wrong with someone saying this? Insufficient credit given to other languages? Do people apply this standard to C with BCPL and ALGOL? I haven't seen them do so.)

> Something that resembles Go's managed runtime but with Rust's sum types ..... Or as another phrasing: what is actually wrong with someone saying this?

I don't think there's anything wrong per se. Although I do think it contributes to the sentiment that people may be ascribing things as being novel to Rust, even when not intended as in this case. To be fair, that's what sent me down the mental path earlier that prompted this subthread. And that's when I figured it was more a matter of being the implementation most likely to resonate with the audience.

And I don't think it's a matter of needing to give credit to other languages. But phrasing it like "Something with a managed runtime, but with sum types" is generic enough, unless there's something specific about either of those. For instance the phrasing I gave does exist in plenty of places, but perhaps "Something that resembles Go's managed runtime with sum types" perhaps does not. I don't know enough about Go to say that.

In other words, is there something specific about *Rust*'s sum types that one is after in this example? Or just the concept of sum types.

> In other words, is there something specific about Rust's sum types that one is after in this example? Or just the concept of sum types.

I think, concretely, it's the fact that Rust's syntax is more intuitive to the average engineer than ML or Haskell. Maybe that's a failure of SWE education! But generally speaking, it's easier to explain what Rust does to someone who has taken a year or two of Java, C, or C++ than to explain ML to them.

I agree and think you're right, to a point. But I would posit that a much higher percentage of devs than the typical HNer would expect would find the Rust syntax to be pretty arcane. Although I grant that they'd find Haskell to be *more* arcane for sure.

And that stopping point I think is where the perception of Rust's popularity on sites like HN is much higher than in the general public. And by that I mean people who at least grok, if not use, Rust and not people who like the idea of Rust.

For instance, keep in mind that even during the heyday of Scala here on HN the rest of the JVM world was complaining that Scala syntax was too arcane.

No particular disagreement there!

It implies completely lack of knowledge that something like that already exists, predating Rust by a few decades.

The contexts where it pops up, it is as if it would be yet to come, such language.

Speaking of C and BCPL, indeed we do, because many wrongly believe in this urban myth, that without them there was nothing else as high level systems programming languages, even though JOVIAL came to be in 1958, followed by ALGOL and PL dialects, Bootstrap CPL was never planned to be used beyond that purpose, and there was a rich research outside Bell Labs in systems programming in high level languages.

Instead we got stuck with something that 50 years later are still trying to fix, with Rust being part of the solution.

> It implies completely lack of knowledge that something like that already exists, predating Rust by a few decades.

I don't understand why you think this: we explain things all the time without presuming that the particular choice of explanation implies ignorance of a preceding concept. In high school physics, for example, you wouldn't assume that your teacher doesn't know who Ptolemy is because they start with Newton.

The value of an explanation is in its effectiveness, not a pedantic lineage of the underlying concept. The latter is interesting, at least to me, but I'm not going to bore my readers by walking them through 65 years of language evolution just to get back to the same basic concept that they're able to intuit immediately from a ~6 line code snippet.

(It's also condescending to do so: there's no evidence whatsoever that Rust's creators, maintainers, community, etc. aren't familiar with the history of PL development.)

For what it's worth, you're right. I saw the same thing happen with Go: everyone seems to think that Go invented static linking and gasp compiling executables, seemingly ignorant of the fact that we actually used to do that all the time, before bloated dynamic runtimes and massive virtual machines even existed. I don't trust software "experts" who don't know their history, because they usually don't know a lot of other important things, either.

It always has to be some moral thing with you people. What's "wrong" is that software practitioners who don't know their history are doomed to repeat it. It implies a lack of exposure to different parts of the field, and especially a lack of exposure to the theory. Someone who thinks Rust is an entirely new idea in computing probably has other massive gaps in their knowledge, and it follows the irrational pop culture this industry has cultivated where anything older than 18 months is bad, and anything newer than 18 months has never existed before and is the greatest thing since sliced bread.

Some of us are tired of cleaning up after the inevitable messes these developers leave behind.

What are you talking about? The “wrong” above is factual i.e. positive, not normative.

Please be a little bit more charitable with how you read comments. The core observation here is that “Rust is completely novel” is not actually something that Rust practitioners, including junior engineers, actually say. Nobody has said it in this thread, and nobody has even provided a single example of somebody saying it.

Is there any reason why you've singled out Rust as particularly notable here and not any of the many other languages with them? OCaml, Elm, F#, Scala, I think more recent versions of Java, Kotlin, Nim, TypeScript, and Swift all support ADTs. Python already supports them, albeit with very little runtime support. Rust doesn't particularly stand out in such a broad field of languages. They're so useful a language needs a good reason these days to not support them.

You're making the exact point that I was raising.

I'm sorry, I'm still completely confused where rust came from or what particular relevance it has to the conversation beyond the short segment in the article?

My point being—you see articles about ADTs involving non-rust languages all the time. Why single rust out?

FWIW I seem to often find myself reaching for Haskell-isms when writing Typscript or Scala. And I’ve never actually written production Haskell code! But so many concepts like this just map nicely. “Parse don’t validate”, “make illegal states unreprsentable”, etc - all those patterns.

Also known as Type Driven Development, a much better approach than the other TDD abbreviation.

Reply on news.ycombinator.com