>you're saying Go will be an excellent systems programming language, which is its main stated purpose

It will be, when it is finished. Without dynamic linking it cannot replace C/C++ for lots of the intended use cases.

>Then, you claim it doesn't work like established alternatives, so it must be over hyped.

No, I claim that it lacks most useful features of the powerful languages it is constantly being compared with. Rob Pike says you don't give up much expressiveness moving from Python/Ruby to Go. This is absurd. Go has a different way of doing things yes, but for many things, that different way is to write more code.

I think in real usage (in my experience), this is very rarely the case. The only thing Generics are really extremely useful for is writing data structures that you can re-use with multiple data types.

Also, I tend to appreciate Go's approach of writing more code in these situations, because in general the code is still far more readable than a C++ Template (for example).

The Go creators have not ruled out adding Generics, they are simply being very careful about how they implement it. I would rather have this situation than something like a generic Java/C#/C++ style generics implementation rammed in because it is demanded by people who have hardly touched the language (or refuse to touch it until said feature is added).

"I think in real usage (in my experience), this is very rarely the case. The only thing Generics are really extremely useful for is writing data structures that you can re-use with multiple data types"

When working in .NET on framework-y code I use generics with reflection a lot because it makes it easy to remove a whole swathe of repetitive code. Mapping from one object to another using a Mapper<TFrom, TTo> with generic constraints, reflection and some over-ridable conventions springs to mind.

Not an argument for adding generics in Go, or against Go itself as I haven't yet found the time to play with it. However I do think generics can be more useful than people give them credit for.

The thing is that Go has generics already for the most common data types: slices (vectors, what Python calls 'lists', others call them 'arrays'), channels (iterators, generators), and maps (dictionaries, hashes). Since there's already a built-in map[T1] T2, so you wouldn't need to build it yourself, which saves even more work.

If what it has are a handful of special cases baked into the language, saying the language supports it is probably overselling (similarly, having types like `float[3]' doesn't mean we consider C as supporting dependent types).

"The only thing Generics are really extremely useful for is writing data structures that you can re-use with multiple data types." Take a look at C++'s STL: a large set of generic algorithms that work with any data structure (built-in or user-written) supporting the standard iterator protocols. Many people think of STL as "a bunch of container classes", and ignore the algorithms.

  ... it cannot replace C/C++ for lots of the intended use cases

Does Go need to replace C/C++ in all use cases to be a "worthwhile" language? If not, then is there some required percentage of use cases that Go must be better at than C/C++? If not, then what is the point in arguing that there are some things Go is not as good for? Of course, knowing what those deficiencies are is important but it sounds like you are trying to convince people to not use Go. Why?

Yes there is a lot of Go hype around here and I understand your desire to counter that hype.

Choosing programming languages and other technologies and skills is an unfortunately subjective and messy process.

    > Without dynamic linking it cannot replace C/C++ for 
    > lots of the intended use cases.

What use case requires dynamic linking?

Loadable modules like the way Apache/nginx do, or Nagios or quite a few other basic infrastructure applications.

Another related issue (though not specifically dynamic linking) is with client libraries for server software. For example say you wrote something like Redis in Go. You write a Go client, then you want to start porting client libraries. You will be starting over from scratch because you can't expose your Go code through any kind of native interface. If you write client libraries in C it is pretty easy to create language bindings in all other popular languages. So if I wrote a server in Go that I wanted to distribute widely, I think I'd have to write the reference client in C.

    > Loadable modules like the way Apache/nginx do, or 
    > Nagios or quite a few other basic infrastructure 
    > applications.

I agree this style of composition is not currently possible in Go, but I do not agree that it is necessarily a good (in the engineering sense) solution to the requirement(s) it solves. There are lots of other ways to communicate between dynamically dispatched blocks of code, and dynamic code loading is by any account fragile.

Or, to put it another way,

    > you can't expose your Go code through any kind of 
    > native interface

I'm not convinced this restriction is anything but good.

> What use case requires dynamic linking?

Here's one: writing a plugin for AviSynth in Go.

some I can thnk of:

- Using a GPL-ed library in a BSD project.

- using a LGPL library in a commercial project.

- keeping source code secret from customers who buy your library.