Hacker News new | ask | show | jobs
by cgag 4242 days ago
I don't think you're going to come around on it. It's not suddenly going to stop being terrible at abstraction. That essay seems very accurate and applies to Golang.

The strengths of Go to me seem to be its extensive standard libary and the fact that you don't need to worry about writing elegant code because it's not really an option. That reduced decision making is actually really appealing to me on some level, but it's not enough for me to consider it over what I consider better tools (Haskell, Rust).

I'm currently porting a tiny program a friend wrote in Go to Haskell so we can compare notes, and I think the Haskell is both safer and more elegant, but I'm jealous of the fact that all the libraries he used are from the standard library while I have to evaluate libs of varying quality. However, I would rather put my time in to improving the Haskell ecosystem than using something convenient that makes a lot of decisions I disagree with.

edit: I also think there's value in being a conventional imperative language as someone mentioned below. I with there were something between Go and Haskell. Perhaps that'd essentially be Rust with immutable data structures and garbage collection.

1 comments

I dont know much about go, but I always thought that the problem with 'the standard library does everything' is that it starts to feel heavy and better alternatives pop up. Then you have these dark places in the library that most people avoid, and you cant really throw away.

Clojure used to have something called, clojure contrib and it was kind of awsome, it did pretty much everything in just one jar. It was also a huge problem to mentain and everybody wanted to be in contrib, so you had the one json lib in contrib and fasters outside.

With clojure 1.3 it got split up into many diffrent parts and it still servs as somewhat of a community standard or recommended library. Overall its much better and much more usful, but sometimes I miss the days when everything was in one jar on on dependency.

Rust is avoiding the contrib problem by shipping a robust package manager from the beginning and pushing much of the Rust stdlib (and language features) into libraries.

http://crates.io/

I started using Clojure just after 1.3 came out so I could be wrong, but my impression was that while contrib was all in one place, it was still maintained by a bunch of random people who got their code into contrib, rather than being treated as a core part of the language the way (I believe) Golang's is.
Yes it was, like I said it is better now. However it was also kind of nice because everything was just there. Even with good mantainers, some of the same problems could keep existing.
That's right. contrib was always the red-headed stepchild to core.