Hacker News Reader

Comment by pif | Hacker News Reader

> Go is an open source programming language designed for building simple, fast, and reliable software.

By the way, what would you use for complex, fast, and reliable software?

That depends a lot on what you mean by "complex". If your problem naturally and profitably decomposes into a pipeline of smaller, simple subproblems, Go can still be pretty nice to work with.

I wrote a (bad) compiler in it, and Go wasn't really any of the trouble I had with it.

Could you give an example of a program you think Go isn't suited to?

The compiler was straightforward to express in Go, but I wouldn't want to write a static analysis tool in it.

I don't especially love writing database-backed web applications in Go.

You could use Go. Simple here means that the language doesn't add unnecessary complexity, not that it is only suited for simple problems.

I think "simple" in that context means that the software should be as simple as the problem domain will allow, not necessarily that it's bad at building applications with complex needs.

A language with generics, e.g. OCaml, Haskell, Scala or F#. Once complexity reaches a certain level that's one of the tools you need to manage it.

Sometimes. Other times, generics are a tool that development teams use to amplify complexity.

Giving your team more powerful tools should always be a positive. If you don't trust them not to do harmful things with them then you have bigger problems.

It doesn't feel like that's a strategy that worked especially well for Scala or C++. Go isn't the only language that removes powerful tools: all the strict functional languages do too!

The issues that Scala and C++ have are far beyond just "having generics". Classical (ML-style) generics are an incredibly simple feature, much more so than, say, built-in channels.

I agree and I like generics, but I think it's hard to argue that generics have never made a complicated project more complicated.

I'd say typeclasses, templates, and variance have, sure. Those are separate features from generics in my mind. (But you could reasonably lump them all together under the heading of "generics" and I won't argue too much.) :)

It's worked exceedingly well for Scala from where I'm standing. There is no other language I'd rather be using.

If you read my comment carefully, you'll see that I was not in fact saying that people were wrong to like Scala. I like C, but I don't get irritated when people point out its innumerable flaws.

If you read my comment carefully, you'll see that I was not in fact saying that you were saying that people were wrong to like Scala. I think it's the best language available today and I think that's as a direct result of it being willing to put powerful tools in the hands of its users; therefore "It doesn't feel like that's a strategy that worked especially well for Scala" is, in my view, simply wrong.

I don't think I'm the first person to suggest that Scala introduced a fair bit of complexity with all the features it embraced, but, fair enough.

I would say "Go" (among others).

I think the author meant that Go is a simple means to design fast & reliable software.

That would certainly be my point of view, in any case.

Reply on news.ycombinator.com