[wyager]

Jesus, I hope not.

Go now is like Java in 1997. A mediocre language with lots of corporate support and a big standard library. It's popular in the developer crowd right now because it's A)simple B)has a good standard library and C)getting support (in the forms of tools, tutorials, etc.) is easy.

We shouldn't let those things be the deciding factors in choosing what language to stick with over the next ten or twenty years. That's what we did with Java, and even though we're on revision 8, people are still (rightfully) complaining about many of the same flaws that are still present 20 years later.

As Java aged, developers realized that they didn't actually want the type of language that Java started out as, so over time, Java has accumulated features like lambdas, generic programming, etc., but because the language wasn't designed with it in the first place, it's all sub-optimal cruft.

Go has a lot of the same problems now. No generic support (What language designer in 2014 builds something that idiomatically requires casting to the top type? That was precisely a huge problem for Java; Java (sort of) fixed this by adding Generics in 2004), a mediocre type system (which gets completely ignored pretty frequently anyway; see the previous issue), inflexible (you can't extend important built-ins like range or make()), and with none of the interesting features that programming languages have gotten good at in the last few decades (pattern matching, immutability, null/nil-free programming, etc.).

I really hope that developers can see past the hollow promises of corporate support and a strong standard library and wait for a language that is actually good in and of itself, and not just because there are so many developers propping it up. There are a number of very well-designed languages on the horizon. The one closest to Go may be Rust, which has excellent features like ML-style generic programming, pattern matching, an almost-hindley-milner type system, strong support for immutable and functional programming, etc.

[penguindev]

In addition, GO failed to advance the art of error handling in any way, in fact I'd call it a step back. I can already do multiple return values in python, or I can choose to use exceptions rarely or frequently depending on the problem and have easy syntax like 'with' for critical cleanup. Any language that demands 100% programmer reliability to trap errors is not useful for most projects that don't have google-level code review and rapidly changing project specs.

I've done the C way of checking every function for errors. It's painful, and should be done only when the problem domain demands it, which is a small subset of problems. Googlers are living in their own universe.

[mseepgood]

> No generic support (What language designer in 2014 builds > something that idiomatically requires casting to the top > type? That was precisely a huge problem for Java

Even a seasoned Haskell programmer like Erik Meijer has a more nuanced view on the topic than you: https://www.youtube.com/watch?v=on5DeUyWDqI&t=23m40s

> you can't extend important built-ins like range or make()

This was a deliberate design decision. When the Go team was asked about what they like about Go one answer was:

"It's very simple to understand, and the code that I read on the page is the code that is executed.

When I iterate over a slice, there's not some chance that there's an iterator implementation that fetches a file from a web server in Romania and serves me some JSON or something.

Instead, the language is very deliberately simple and contained so that it's very easy to reason about code that you're reading." https://www.youtube.com/watch?v=sln-gJaURzk

[wyager]

>Erik Meijer has a more nuanced view on the topic than you

I'd rather not watch a 40 minute video. Care to summarize?

>"and the code that I read on the page is the code that is executed... the language is very deliberately simple and contained"

This is a dumb argument. The same thing can be said about assembly, and in fact this property doesn't hold true once you introduce abstraction through functions.

All well-written code is easy to read, and most poorly-written code is hard to read. Go does not change that.

[mseepgood]

> I'd rather not watch a 40 minute video. Care to summarize?

I linked to the exact time where he starts to share his thoughts about generics.

[kyrra]

I'm waiting for the talks from Gophercon to appear online, but one of them[0] talks about using Go interfaces to handle most generic type problems. Another interesting read is Rob Pike's argument about "less is more"[1]. The HN discussion on less-is-more from 2 years ago brought about some interesting discussion as well[2].

[0] http://talks.golang.org/2014/go4gophers.slide

[1] http://commandcenter.blogspot.com/2012/06/less-is-exponentia...

[2] https://news.ycombinator.com/item?id=4158865

[wyager]

>using Go interfaces to handle most generic type problems

Do you mean Go interface specifications, or the Go interface{} type?

Because the latter is the top type. Using it is equivalent to casting things to Object in Java, which people did up until 2004 when they realized it was really stupid.

You also can't use Go interface specifications to make generic data structures, which is the really important use case.

[jmoiron]

Go does not have a type hierarchy, so there is no top type.

You can easily use interface{} to make generic data structures, but interfaces have a time/space/code-complexity cost which makes them not worth it most of the time.

[wyager]

>Go does not have a type hierarchy, so there is no top type.

Go does have a type heirarchy. It's just not very extensible. There is top (interface{}) and then there are all other types (which are subtypes of interface{}).

If Go didn't have a type heirarchy, you wouldn't be able to up- and down-cast (up-casts are performed via implicit coercion to interface{} and down-casts are explicit).

>You can easily use interface{} to make generic data structures, but interfaces have a time/space/code-complexity cost which makes them not worth it most of the time.

You also lose any semblance of type safety, which is kind of awful.

[jmoiron]

There is no type hierarchy and there are no subtypes. Interfaces do not describe type relationships. The conversion required between `[]int` and `[]interface{}` further demonstrates the significance of this distinction.

As for losing type safety when writing generic containers, this is true, and another reason why people don't do this.

[jeremiep]

This is exactly why I don't want to jump on the Go bandwagon.

You forgot to mention the Go ABI which isn't even compatible with C. That alone for me is reason enough not to use it as a systems programming language.

I would choose D over Go any day of the week. It's longer to learn and master, sure, but it is also much more powerful and expressive.

[pjmlp]

One of the design decisions that I deslike in Go, is that instead of providing FFI declarations like Object Pascal, Ada, D and many others, they require the use of an external C compiler.

[chimeracoder]

> A mediocre language with lots of corporate support

It's very disingenuous to compare the level of corporate support that Sun provided Java and the level of corporate "support" (involvement) that Google provides Go.

The Go project began at Google to solve the sorts of challenges that Google was having (architecting and managing large servers), and several of the original members of the Go team work at Google, but the Go team has gone out of their way to ensure that Google (the corporation) doesn't control Go development.

[masklinn]

So... a mediocre language with (very relatively) little corporate support but lots of corporate name recognition?