undefined | Better HN

0 pointsWorldMaker2y ago0 comments

Error handling absolutely breaks the language for me. I understand why many don't like exceptions handling in many contemporary languages like C#, but I think that if you are going to do a sum type instead and force handling errors as a result type from functions you could at least use a proper Either monad and some form of monadic binding to remove boilerplate and enhance composition. (This was a problem with ColdFusion too. I can go on at length about some of the terrible "circuit breaker" boilerplate in that language and how tough it made handling errors correctly without killing entire applications.)

As for the ecosystem, most of what I've seen is a language that seems built for supply chain accidents (random github.com main branches as far as the eye can see) built by a company with a track record of developer tools that provide terrible developer experience that live in their own little bubble divorced from most of the rest of computing. (These are also things that seem very familiar to me from my brief horrifying time with ColdFusion.)

If golang works for you then that is great, but it upsets me to look at and right now you'd need to pay me a lot to have any interest of maintaining code written in it. I have enough scars from terrible things like ColdFusion on my resume.

0 comments

jeff_d_miller2y ago

> Error handling absolutely breaks the language for me.

I think you missed my point. This is not about whether I personally like go (I don't) or its error handling (I don't). It's about which aspects, historically, tend to lead to a language's demise over a few years. The claim is that error handling is not one of them.

C isn't great with that either. It's still heavily used.

The supply chain issues are more relevant, but the key question then is whether the language and ecosystem evolve to avoid this. Golang has shown to be flexible and generics were unthinkable not too long ago. Now they are there.

Neither golang nor C are my favorites, and you can argue all you want why golang is not for you, but that misses the point entirely.

WorldMakerOP2y ago

We are definitely having two different conversations.

I don't have much to say on the possible longevity of golang or not. Longevity is sort of guaranteed as soon as you write code in a language used in Production. Today's hip programming language is always tomorrow's terrible "legacy code" language. Someone has to support that long after the fact, whether or not the language itself ever remained in support or "alive". That sort of longevity is inevitable, per the law of averages.

I'm mostly just commenting on the ways that writing ColdFusion, in a brief window where it was a supported "alive" language, actively "hip" among certain types of baroque Enterprise development and developers, it still felt (to me at least) like prematurely writing "legacy" code. Single (arguably bad) vendor, bad error handling leading to lots of ugly boilerplate, bad development tools, bad ecosystem, et cetera. That's a lot of orthogonal concerns compared to longevity. ColdFusion had a longer supported longevity than is often credited for, but that doesn't really give a sense of how much it felt like a "dead man walking" even in all those supported years. ColdFusion to this day has a massive "legacy" longevity that is likely invisible to much of HN, but still likely fills plenty of ugly legacy code niches in dark matter Enterprise development even for a dead language, even despite it being a dead language, but the difference between today and when the language was "alive" doesn't feel all that dissimilar because it was always a zombie language in a zombie ecosystem.

Golang seems to me another "born (un)dead" language in that way, that even while it is actively supported certain things about it feel to me like "a dead language walking" (and all code in it feeling like "legacy code" even as it is written) and I think that's what I've been trying to find the right words to say for months now of seeing Go code in increasing places and having a bad gut reaction to it.

In that feeling of "born (un)dead", I don't see C there at all. It's impossible to argue that it isn't an alive language, with plenty of multi-vendor support and nearly always has been (even if it is definitely not the best language to work with in 2023). (Objective-C, rather than C, is easier to argue has had many decades of seeming "born (un)dead". For another modern example, I think you can make a case that Swift also fits closer to "born (un)dead", even though I like its error handling better, mostly, I think it seems healthier than Objective-C in some ways, and I don't hate looking at Swift example code in the same way that golang gives me the heeby jeebies.)

j / k navigate · click thread line to collapse