Hacker News new | ask | show | jobs
by aptenoforst 1061 days ago
Its a shame that Go as a language is so lacking, the tooling is amazing.

I wish there was something like Go but with an actually good programming language attached.

2 comments

This is pretty much my take, too. Go as a compilation target?
I’ve noodled around with generating review-ready Go from CL (because macros), but it’s hard to flatten subexpressions (like multiple-value-bind around a call that returns a value and an error) into blocks of statements that assign to new temp vars, and I couldn’t expect arbitrary CL to just work, it’d be more of a CL-flavored DSL for generating loops and error handling.
What do you think Go is missing?
Anything that made programming easier in the last 30 years.

I miss Hindley Milner type inference, ADTs, default immutability, sane error handling, pattern matching, and functional collection manipulation.

I'm not even mentioning the time it took to add generics to the language, which should've come from the beginning, and we got a bad implementation of it.

Not saying that it HAS to have all of this, but at least 1 or 2 things of that list would already make Go have much better ergonomics.

Go has no excuse since it's a relatively new programming language, and it could've got some of those from the start.

TBH, it sounds like you want a functional language (type inference, pattern matching, collection manip), of which there are many. GO is not such a language. But then you want ADTs, which aren't really functional. I'm not sure you can have both in a clean way. The closest you might get is a multi-paradigm language that tries to allow both, like C++.

Default immutability is great in a language like Rust where it's designed from the ground up to warn you as much as possible at compilation when something is wrong. You can rely on the compiler a lot. But adding default immutability to a language that isn't designed around the same concepts seems odd. You don't gain the same kind of benefits, but you do have to deal with the tedium. Worst of both worlds, in my view.

Not exactly. I don't think Go should have ALL those, but some would be extremely helpful. That's just a wishlist.

There are some examples of languages that have a nice blend of functional features built in that are not fully functional languages, and the developer experience is fantastic (e.g. C#, Typescript, Kotlin, Swift, Java 11+)

They could've improved the developer experience, but they made some kind of C+- with easier concurrency.

And I find it all sad because Go ticks many of my boxes for a "perfect" general-purpose programming language.

> But then you want ADTs, which aren't really functional.

Pretty sure by ADTs, GP means "algebraic data types". These are very much functional, at least in the sense that they're a standard feature of statically typed FP (at least I know of no such language that doesn't have them).

ADT also sometimes stands for "abstract data type", which is something different. Although I wouldn't call them incompatible with FP either, Haskell typeclasses can express abstract data types, for example.

Ahah, whoops. I thought they meant "abstract data types", ie, classes - which AFAIK Go does not have.

Yeah, then if they want algebraics then a functional language is definitely the answer here.