Hacker News Reader

Comment by PaulRobinson | Hacker News Reader

TL;DR: "Go isn't like Haskell, and that means it's not as good"

I get that we all have favourite languages, but it is not amazingly helpful to try and compare them like this, for me. I'm sure if you're a Haskeller and you're eyeing up Go, being forewarned might be helpful, but here's another idea:

Don't compare. Just use. Take it at face value. Figure out what becomes easy, what becomes hard.

I came at Go from 10+ years of professional Ruby development, and it was a tough punch to the stomach at times. I still think in Ruby more often than I think in Go. But I know the two aren't really comparable for most things.

View on HN

I don't understand. How can they not be comparable? They're the same type of tool, built with the same goal (writing any kind of software). In fact, Go itself was born because its creators felt the current languages weren't good at handling the current computing environment - comparisons with other languages are the at core of its existence. Finally, why even choose Go if it's not because it has some comparative advantage? Might as well stick with what we already know.

They're not the same type of tool. Go is mainly aimed at distributed computing evironments and infrastructural tools. I really don't see a sensible Consul/Kubernetes/Docker alternative being written in Haskell.

I don't see why not, Haskell has green threads, channels, and everything that Go has. The only argument I can see made is that the laziness and current GC implementation aren't suited, and even then, those problems can be solved with strictness pragmas, and a different GC respectively.

   > I really don't see a sensible Consul/Kubernetes/Docker alternative being written in Haskell.

The only reason for this is the unpredictable latency issues caused by the current garbage collector in GHC. This should be avoidable once GHC has linear types[1] and someone rewrites its GC to take advantage of this.

[1] https://news.ycombinator.com/item?id=13866787

> Don't compare. Just use. Take it at face value. Figure out what becomes easy, what becomes hard.

Isn't this precisely what the author did? The bad parts he mentioned were mostly "this is stuff that the compiler could've catched, but it didn't and thus gave me a hard time".

If we were going to carry out this argument, it would probably just boil down to the familiar debate of how strict a type system should be. The author is just a proponent of expressive type systems, and he plainly puts it in the title: "a Haskeller's perspective".

I learned Go in the manner which you describe. It's still a disappointing language. I don't understand the powerful Stockholm Syndrome which appears to grip most Gophers.

For example, compared to MRI, Go has better GC and execution speed, much less flexibility, better concurrency primitives but not better concurrency libraries (EventMachine), and is incredibly verbose.

If you refuse to compare languages, then you are asserting that at least one of the languages is somehow magically incomparable and thus criticism-free, and Go is not so special or good that it should get any pedestal-driven treatment.

What was hard to get used to when you came from Ruby?

I came from Java, but it should be said that the Java style I've been using since the mid 2005s (some functional influences and a lot of experience-driven minimalism) made learning Go really easy. I should be missing immutable types and types that can only be instantiated if the state is consistent, but for some reason I didn't. Perhaps it is that the Go mindset is just very easy to adapt to?

One thing I would say, though, is that you can feel that Go was a more deliberate language. Unlike most popular languages it wasn't really a language that grew out of inexperience and as a learning exercise for the language implementers. The authors already had a fairly good idea of what they wanted to accomplish and they had the attention to important detail that others tend to miss due to lack of experience.

I found this comparison really interesting. Yes it is snarky and condescending at times (someone really needs to write the corollary to that blub essay, about programmers spending more time working on powerful abstractions and purity than real work), but it's useful to have an outside perspective - sum types seem nicer than returning type,error to me, the criticism of containers is fair, etc

I guess you have looked at Crystal then? Much of the same expressibilty and stdlib as Ruby, but natively compiled and with channels.

Reply on news.ycombinator.com