Everyone check off "immediately making a Golang conversation about Rust"'on your HN bingo.

I'm absolutely baffled by this attitude in literally every single programming language thread in HN.

PLT and PL Design don't live in vacuum, it's a vast field that has been developing exponentially in the last years (just like any other CS discipline).

Any development in Haskell, Rust etc... Or other relatively mainstream frontier languages are fundamentally relevant to any other language's design. Period. All this bickering about "Rust in every thread" is excruciatingly misguided. Lessons we can learn from Rust will be highly influential on other languages and it's worth discussing these. Please keep this in mind before complaining for the 999th time.

It's fine to compare language design, and it can make for interesting discussion, but that's not what HN has been lately. It's just "Rust is better because it has x feature." If I wanted that level of discourse I'd go to /r/ProgrammerHumor and find the 10,000th "Python is better than Javascript" meme.

Is my comment any better? No probably not.

But this particular chain started as a discussion of how sum types are missed in every other language. Isn't that a very important observation?

Every programming language is an experiment: it tests whether an well-defined, particular model of computation ends up having advantages on human engineering results. Maybe it causes fewer bugs. Maybe it makes development faster. Maybe it makes certain features easier to implement.

So whether one language has a feature that's highly missed in other languages is the very basis of the debate.

I personally am not a Rust programmer, but not knowing Rust, but knowing another programing language that has sum types, it seems understable to me that it worths mentioning this for every language that doesn't have sum types. And when you do do that you might as well mention Rust as an example. (Maybe because it's more mainstream?)

It's a common phenomenon on HN, typically referred to as "a casual dismissal".

Are you really surprised or upset to see those types of comments when the article itself is fundamentally about trying to adapt Go to become more Rust-like?

Personally I think people can't help but notice the trend of Go users rediscovering bug-by-bug and frustration-by-frustration why Rust was designed the way it is.

> the article itself is about trying to adapt Go to become fundamentally more Rust-like?

The article does not even mention Rust. Not every attempt to make something 'safer' is an attempt to make it 'fundamentally more Rust-like'. (And you're also misusing the word "fundamental" - even if we grant this is "Rust-like" this is adapting their code to make their Go programs practically more Rust-like.)

I should have said "the article itself is fundamentally about…", and not "Go to become fundamentally more…". Apologies. I've edited my comment.

Not only Rust, there is plenty of programming language design experience between 1950 and 2009, but naturally that was PhD stuff not worth taking into consideration.

No, I'm not surprised, that's why it's on the bingo card. They are very different languages, so endlessly comparing them is tiresome.

Aw come on there was a whole two hours that this post was about Go before I showed up.

You gotta give the people what they want!

The ‘safe’ keyword in the title is a Siren’s song to certain types of Rustaceans, so it’s not surprising.

I was reading this because hey, safer enums. But I agree, Sum types are a must have.

Particularly, decryption should be Authenticated, and so the correct return type of a decrypt function is a Sum type, and if you don't have Sum types you can't do that.

The C# of my day job often feels like banging rocks together with its c-style enums and lack of sum types. But there is always an article about go that makes you appreciate what you do have.

> The C# of my day job often feels like banging rocks together with its c-style enums and lack of sum types.

Hah, I agree. I switched over to F# and never looked back. It plays nicely enough with C# that my colleagues couldn't stop me (but didn't join me either).

> But there is always an article about go that makes you appreciate what you do have.

Yes. Go seems like a time machine back to about 1985.

Starting a new project and trying to decide between Go and F# of all things. Go seems fast and very widely used which means resources and help is widely available and it’ll be easier to find contributors. Meanwhile coming from the C# world at my job I really like the syntax of F# from what I’ve seen so far. The type system seems incredibly expressive in a way Go’s isn’t, access to C# libraries means I can do pretty much anything I’ll need to, and I enjoy FP paradigms even though I’m not looking for full FP (I generally like loops and escape hatches from FP if I need to do something specific). What’s your experience with F#? I’m worried about support and finding other people familiar with the language, not a huge fan of nuget, and I prefer to use VSCode but C# has been impossible to program in VSCode imo.

I’ve had a great experience with F#. It’s now my preferred language in almost all cases, and it’s plenty fast enough for the vast majority of applications. I use Visual Studio and the UX is excellent. (A lot of F# developers use Paket instead of Nuget.)

MS seems committed to F# as at least a source of future C# language enhancement ideas (although C# will never fully catch up). There’s also a vibrant F# community on Stack Overflow, Reddit, etc. I never have trouble getting help if I need it.

Unfortunely switching to F# also means throwing away what actually makes .NET relevant in terms of end to end developer experience, and the Redmond overloads don't seem to care that much to change that, as the C in CLR seems to refer to C# and no longer to Common, in the ways VS and VS4Mac are designed.

I do like the way they added type-switch and switch expressions to get some of the sum-type ergonomics out of the existing object oriented type system.

C# has sum types

C# does not have sum types.

It has "enumeration types" but their behaviour is exactly that of C's, with various additional conveniences but critically (and unlike Java for instance) no more type-safety.

Not without squinting really hard and making some OO monstrosity with internal impls of an outer abstract type it doesn’t. And that’s not really language support it’s banging your rocks together really hard trying to bend it into being ML.

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").

> 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.

One of the "offshoot" or inspired by languages of Golang, is Vlang (https://vlang.io/), and the other is Odin. Vlang has both sum types and real enums. It had those, including generics, for quite a while.

From a first glance, Odin looks like a nice language to use! Looks like they have fixed ocd-causing idiosyncrasies of Go - "for value, index" and not the other way around, "defer" belongs to surrounding scope, and not the whole function.

Thank you!

Your welcome. I keep my eye on both Odin and Vlang. And if a person has experience with Go, they offer some different features and freedoms that might have been wanted, but couldn't get. Additionally, it's not too difficult to switch among the languages as well, if one is strongly familiar with one of them.

Problem is to switch people around you to use something else. Second company, second fight Java vs Go, and I am loosing again... Makes me wonder if all my efforts to learn something new are for nothing, for no real benefit.

Since 1.18 was released it's now trivial to implement compile-time (safe) 'sum types' in Go. They're fully supported.

It's about 300loc to implement and then sum types can be defined declaratively just like any other type (and without any boilerplate).

There hasn't been any fanfare about this capability because it doesn't require any special syntax or new keywords. Just know that the suggestion that "Go 1.18+ doesn't support sum types and/or enums", is very wrong.

Not going to link it anywhere? I have some doubts given how widely it wouldve been shared if the claim is actually true, and your not linking of an example kinda just furthers that

Sum types: https://go.dev/play/p/R7Bhy2LDmde

Enums: https://go.dev/play/p/MnbmE0B3sSE

Here you go.

That code appears to be using reflection to build up runtime tables?

https://github.com/qlova/tech/blob/c6379c9c32e5b7b2973bc02ba...

https://github.com/qlova/tech/blob/c6379c9c32e5b7b2973bc02ba...

That's a big difference from other languages where this is all handled at compile time.

This is cool, but it doesn't seem like Switch is implemented for Int, and the use of runtime reflection limits the contexts in which this implementation can be used, compared to a language construct that gets compiled into efficient machine code. I wouldn't want this to be endemic in my codebase or my dependencies.

Enum supports an exhaustive Switch as well, here's an example based on the blog post: https://go.dev/play/p/Ef78vLyw33g

Is it just me or is the syntax on these worse than the issues it’s solving?

It's not you, this is a worse version of std::variant, which isn't exactly great in the first place.