Hacker News Reader

Comment by bogomipz | Hacker News Reader

Hi, could you elaborate on you comment about Go's "less than stellar type system"?

Lack of generics (stick, meet dead horse) is at the forefront.

Lack of very basic functions (map, filter, reduce) against slices.

map[string]interface{} is pain to work with (one of the moderately popular libraries I mentioned helps: https://github.com/karlseguin/typed)

Lack of immutability.

I don't want to get into errors vs exceptions, but I've never heard a pro-errors argument that wasn't hand waving. I think the decision makes sense given Go's genesis (system programming), but given how Go's actually being used, it's a step backwards.

What I struggle to understand is: If that functionality is considered useful or even impeding the development process for those developing in Go, why has nobody forked the language to add them?

Many of the points you mention are fairly low hanging fruit for inclusion if you are willing to accept the tradeoffs that official Go maintainers are not willing to.

I think the trouble there is just that many other modern languages haven't taken the extreme stance on typing that Go has. It's much easier to learn say, Rust or Scala, than it is to fork and maintain a branch of Go, and there's certainly nothing so special or attractive about Go to tip the balance in the latter's favor.

The issue with that is that anyone invested in Rust or Scala have no reason to want a better type system in Go. Fixing Go is as important to them as fixing COBOL, and I don't see HN full of threads on what needs to change in COBOL.

What we have here is people who are already heavily invested in Go to the point where its type system is a real problem for them, yet they do not want to fix the problems, even in light of the relative ease at which at least some the problems can be solved (again, if you are willing to accept the tradeoffs).

Check the gonuts archives to see how welcoming the community is to such ideas.

Yes, exactly.

You could fork Go and add generics support, but you'd be maintaining that fork forever. The Go core team would never allow it to go back upstream.

It is rather surprising if not outright shocking that experienced developer get heavily invested in a language when other mature/ better alternatives are there.

> What I struggle to understand is: If that functionality is considered useful or even impeding the development process for those developing in Go, why has nobody forked the language to add them?

The group of people who are able to fork, change and maintain their own Go variant are usually not the people who would ever consider using Go in the first place.

Have a look how long it took PHP to get an AST (instead of the broken mess of reading&executing). Those who are able aren't those who would ever deal with PHP.

I've sometimes wondered a bit about this myself. But consider what you'd end up with if you wanted to keep most of go's benefits, but add on such bits. And consider that you could just use Ada, Nim or OCaml. Or maybe Rust (I really like Rust, I'm not sure how much overlap there is in any subjective list of "Go the good parts" and "Rust the good parts" though).

I think some of the best parts of Go is the central model: "go get", "go fmt" along with the standard library - if you fork, the burden falls on the fork keep all that stuff working in a sensible way too.

Go' success is not a mere coincidence:

- OCaml is great but parallelism is still limited by its "Global Interpreter Lock" (like Python or Ruby).

- Rust is great but ownership/borrowing is not for everyone and people sometimes prefer relying on a good garbage collector.

- Nim is great but it's a "small" project compared to Go and most people prefer relying on a large ecosystem like the one offered by Go.

- Ada was a major milestone in the history of programming languages, but it's considered by most as an "old" language, compared to Go/Rust/OCaml/Haskell/Scala/etc.

Thanks. Right, generics is a big one. But isn't Go actually being used for system programming? At least that what I think of when I think of Golang. Maybe the scales have tipped and writing api/microservices is the larger use case now?

I don't know. All I know is this [possibly dated] quote from Rob Pike:

"Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++"

Maybe Python and Ruby programmers are adopting Go to do system programming, but that isn't my impression.

While this may not be a popular opinion, I find Go's type system to mainly benefit the compiler in optimization and be of minimal benefit to the safety or correctness of the program.

Any non-trivial Go project will have interface{} sprinkled all over [1], which effectively gives you the guarantees of a dynamic language with the syntactic overhead of a typed language. Truly the worst of both worlds. While I realize it's a tired argument, Go desperately needs generics in some form or another. It would remove most criticism from the language while substantially improving the correctness of programs.

[1] Here's an example with an LRU cache. Just search for interface{} : https://github.com/hashicorp/golang-lru/blob/master/simplelr...

> It would remove most criticism from the language while substantially improving the correctness of programs.

You seem to assume that people who do not like generics complexity will not complain then.

Reply on news.ycombinator.com