Hacker News Reader

Comment by mholt | Hacker News Reader

The author is using a sharp blade as his implication for good: features that make a language more complex.

If the added complexity is "good" to you, then fine. In modern systems, simplicity is a powerful debugger.

Adding all those features that the author talks about -- "Constraint-based Generics and Parametric Polymorphism", "Algebraic Types and Type-safe Failure Modes", and "Pattern Matching and Compound Expressions" -- even if useful, would defeat the purpose of Go.

View on HN

People use the word "complex" in different ways. Do you mean number of features? Do you mean the size of the compiler? By some measures, operator overloading adds complexity; By another measure, it add simplicity.

I use complexity here the same way the Go community does: it is whatever its authors and users consider it to be. So chances are, if it slows down compilation, it's complexity. If it adds significantly to the grammar or syntax or keyword list, it's complexity. If it does things that can already be done, just differently, it's complexity. If it makes code less clear, it's probably complexity. (You get the idea.)

> I use complexity here the same way the Go community does

To mean anything Go doesn't currently have?

> I use complexity here the same way the Go community does

It is more important for the implementation to be simple than the interface.

-- http://dreamsongs.com/RiseOfWorseIsBetter.html

>If it does things that can already be done, just differently, it's complexity.

Doesn't that make programming languages themselves complexity? After all, you can already do anything in assembly.

That seems like a really weak argument. Sometimes having a more "complex" (in your terms) system leads to simplicity. For example, programming languages in general. Programming languages add "complexity" to computers over machine language programming, but the result is that making a program is a much simpler task.

>In modern systems, simplicity is a powerful debugger.

I don't consider the features I mentioned in this article to constitute "complexity".

I think that Haskell is a beautifully simple language, in the same way that e.g. Euler's identity is beautifully simple. The reasoning behind it may be somewhat complicated, but the result is very simple (and impressive) to behold.

So why not just use Haskell? Why didn't Haskell take over Go's niche?

Because Go is pretty good at its niche, and it has a huge amount of corporate support (from Google), which can make even a mediocre language seem very attractive.

I was around for the Java vs. Smalltalk keruffle. I have to say that Go is less hype and more good, pragmatic design than Java. Go also started out with quite respectable speed and a pleasant development experience, which wasn't true for Java.

Also, as for a "huge amount" of corporate support, if we see the equivalent of "Enterprise Java Beans" then I'll concede that Go is "another Java."

Similar to Java: The barriers to outreach are small because the language is in many ways familiar. I think that's a wise and pragmatic choice.

Because they're completely different languages. The philosophies of the two languages are completely opposite in almost all respects (purely functional vs. procedural, highly general vs. not-general-at-all, and so on and so forth). If you find Go interesting you probably don't find Haskell interesting and vice versea.

I do (well, Scala), and it's much nicer. So it's frustrating to see all these articles praising this Go and encouraging beginners to learn it, or claiming it's innovative when it's nothing of the sort.

Reply on news.ycombinator.com