I see it a lot: there is a type of developer who loves brevity in writing of the code. It is critical to them. They believe that productivity is hurt with more verbose code. They optimize for writing.

Depending on the project, maybe that is ok. I work on projects with multiple teams and zounds of developers. In this sphere, productivity is NOT increased with these kinds of things as they save moments during writing but cost more during onboarding and reading. The more you have to keep in your head to make the code make sense, the harder it is for new team members to spin up.

Productivity in the kinds of orgs I work in is improved when individuals can look at a small section of code and understand it directly. If you are going up call chains to understand things, you are costing productivity. When you have to slow down and mentally parse something, you are costing productivity.

I would take a hand written and hand maintained version of what this utility has as output over the utility every single time.

I went years without using a language with sum types and was fine. As soon as I was exposed to them, I was hooked. They just make so much sense in so many places, especially in trees.

It seems that over the past five or so years, they've been adopted more as pattern matching has. If they're not an explicitly feature of the language, then they can be replicated (like with Java sealed classes).

I'm not sure if Go would ever implement them, or add something that we can more easily replicate sum types with, but god damn are they my favorite language feature that so few languages properly support.

I wouldn't have expected Go to implement them, but after generics and range over functions, I feel like anything could be game.

Meanwhile in the 1970's....

    type
        Planet = (Unknown, Mercury, Venus, Earth, Mars, Jupiter, Saturn, Uranus, Neptune);
        PlanetContainer = record
            gravity: real;
            radiusKm: real;
            massKg: real;
            orbitKm: longint;
            orbitDays: integer;
            surfacePressureBars: real;
            moons: integer;
            rings:  boolean
        end;

    var
        planets : array [Planet] of PlanetContainer;

Golang doesn’t have sum types is Golang’s biggest problem, not generics

It would be a very significant improvement to have tagged unions in the language.

  type planet int // Gravity[float64],RadiusKm[float64],MassKg[float64], ...

Edit: I'd find it marginally less sucky if there at least were some special prefix like `//#` or `//my-preprocessor` or whatever to mark magical semantically significant comments. And what's the deal with the `field[type]` syntax that seems totally ad hoc, why not use the standard Go syntax `field type`?

I see literally nothing in this post that elaborates on "Go Enums Still Suck".

I'm wondering if it be better if an iota would assign random, unique numbers at compile time, just to make it clear that these are not entirely safe identifiers inbetween compilations.

Go doesn't have enums.

Go does not have enum types and Go does not have [Pascal-style] subrange types.

The correct title should read "Go named constants suck", but then I'm not sure what's wrong about them.

How does this compare to enumer? https://github.com/dmarkham/enumer

In most languages enum suck, it's not specific to Go, lot of pitfall and ABI issues, even my modern languages like C# have those.

I'm having some real issues with legibility on this page. I'd like to encourage the author to decrease the font size, increase the line spacing and look into a smaller max-width for the paragraphs. It'd also be nice to have some spacing before a new sub-heading.

I'm coming from a 4k screen, so that does play into it, but i honestly just could not read the article without changing the text properties here.

What's up with the horizontal scroll?

What enums?

I have a mountain of respect for Bell Labs and its contributions to the public welfare, and a lot of respect for the current group of alumni, mostly at Google, and mostly affiliated to a greater or lesser degree with golang. I have my differences with one or two of them (Pike telegraphs a wildly overcompensated imposter syndrome, but he’s almost as much of a genius as he acts like he is and who am I to judge on an overcompensated imposter syndrome, moreover when the guy in at the next desk over is Ken Thompson, who wouldn’t be a little intimidated by the legend).

With that said, golang is too opinionated for its level of adoption, too out-of-touch with emerging consensus (and I’m being generous with “emerging” here, the Either monad is more than an emerging consensus around the right default for error handling), and too insular a leadership to be, in my personal opinion, a key contender outside some narrow niches.

I’m aware that there are avid advocates for golang on HN, and that I’m liable to upset some of them by saying so, so I’m going to use some examples to illustrate my point and to illustrate that I’ve done my homework before being critical.

Many, including myself, became aware of what is now called golang via this presentation at Google in 2007 (https://youtu.be/hB05UFqOtFA) introducing Newsqueak, a language Pike was pushing back in the mid-90s with what seems to be limited enthusiasm no greater than the enthusiasm for its predecessor Squeak. Any golang hacker will immediately recognize the language taking shape on the slides.

I’ve been dabbling with golang for something like a decade now, because I really want to like it. But like a lot of the late labs stuff it seems to have suffered from the dangerous combination of the implications of Richard Gabriel’s Worse is Better observation: it was simpler, faster, cheaper, and ultimately more successful to incrementally adapt innovations from Plan9 into Linux (and other Unices), to adapt innovations from sam and acme into nvim/emacs (and now VSCode), and to adapt channel-based and other principled concurrency from Newsqueak/golang (not to mention Erlang and other more full-throated endorsements of that region of the design space) into now countless other languages ranging from things like TypeScript and Rust at the high end of adoption all the way to things like Haskell at more moderate levels of adoption. Ironically enough, the success of UTF-8 (a compromise for the non-ASCII world but the compromise that made it happen at all) is this same principle in action via the same folks!

And golang would be fine as yet another interesting language serving as a testbed for more pragmatic applications of radical ideas: but it’s got corporate sponsorship that puts Sun Microsystems and Java to shame in scale and scope, but done quietly enough to not set off the same alarm bells.

The best example of this is probably this GitHub issue: https://github.com/golang/go/issues/19991 (though there are countless like it). I’ve worked with Tony Arcieri, he’s brilliant and humble and hard-working and while we haven’t kept in touch, I keep an eye out, and he’s clearly passionate about the success of golang. But proposal after proposal for some variation of the Either monad has died on procedural grounds for nearly a decade, all while being about the only thing that everyone else agrees on in modern industrial PLT: TypeScript supports it, Rust supports it, C++ de-facto supports it via things like abseil and folly, and of course the hard-core functional community never even bothered with something worse in the modern era. You can even kind of do it, but there are intentional limitations in the way generics get handled across compilation units to ensure it never gets adopted as a community-driven initiative. Try if you don’t believe me (my golang code has a Result type via emacs lisp I wrote).

Another example is the really weird compilation chain: countless serious people have weighed in here, I’ll elide all the classics because most people making these arguments have their own favorite language and they’ve all been on HN dozens of times, but a custom assembly language is a weird thing to have done, almost no one outside the hardcore golang community thinks it’s sane, the problems is creates for build systems and FFI and just everything about actually running the stuff are completely unnecessary: there are other IRs, not all of them are LLVM IR if you’ve got some beef with LLVM IR, and given that go doesn’t seriously target FFI as more than a weird black sheep (cgo) there’s, ya know, assembly language. It’s a parting shot from the Plan9 diehards with the industrial clout to make it stick.

The garbage collection story is getting better but it’s an acknowledged handicap in a MxN threading model context, it’s not a secret or controversial even among the maintainers. See the famous “Two Knobs” talk.

Raw pointers, sum types, dependency management, build, generics that never get there, FFI: solved problem after solved problem killed by pocket veto, explained away, minimized, all with mega-bucks, quiet as a gopher corporate sponsorship fighting a Cold War against Sun and the JVM that doesn’t exist anymore marketed by appealing to the worst instincts of otherwise unimpeachable luminaries of computing.

There is great software written in golang by engineers I aspire to as role models (TailScale and Brad respectively as maybe the best example). I had to get serious about learning golang and how to work around its ideologically-motivated own-goals because I got serious about WebRTC and Pion (another great piece of software). But it sucks. I dread working on that part of the stack.

Go enums do suck, but that’s because we pay a very heavy price for golang being mainstream at all: we’ve thrown away ZooKeeper and engineer-millennia of garbage-collector work and countless other treasures, it sucks oxygen out of the room on more plausible C successors like D and Jai and Nim and Zig and V and (it pains me to admit but it’s true) Rust.

Yes there is great software in golang, tons of it. Yes there are iconic legends who are passionate about it, yes it brought new stuff to the party and the mainstream.

But the cost was too high.

Yes. And?

[flagged]

[flagged]