Go is not a dynamic language. It is a statically and strongly typed language. The dynamic part is explicitly programmed by the programmer by using interface casts like in Java.

Personally, I don't understand what's the fuss.

Slashdot says "Parallelism is emphasized in Go's design. The language introduces the concept of 'goroutines' which are executed concurrently", but if you look at the documentation, goroutines are nothing more than threads and channels are nothing more than synchronized data queues...big deal. I can do a synchronized queue in C++ with very little effort. Example:

The interface decoupling from the class is a nice feature, but I can do with with C++ as well, with very little coding, using duck typing. For example:

What else is there? nothing much, really.

Go does not have templates, so writing any compile-time safe reusable code that has minimal performance is not possible.

Go looks like a crippled version of D with bizarre syntax. In fact, it looks like D from like 5 years ago (D started out with no templates too) with bizarre syntax.

Parentheses around if statements are optional, but curly brackets for the block are required. Personally, I've never had grief with the parentheses, but being forced to use curly brackets bloats the code.

Based on that, I am going to assume the designer is making another Java-like language. By that I mean a language which arbitrarily restricts the code for "best practices". We are supposed to be giving more control to programmers, not less. Java was a step backwards from C++ in my mind, even with all of its modern features. Think of those cars that steer themselves during an accident. Imagine if they didn't have the override feature. Do you really want to trust your life to a computer? In this case, I'm fine with trusting the compiler for most things, but I want an override.

C# is much more the language I prefer. It has the feature describe in the OP; being dynamic yet compiled. It's loaded with features, a nice set of standard libraries, and best of all provides that all essential override in case of accident. It is a shame C# is VM based. It sure does run fast, and pretty much every Windows system has .NET on it by now (and Linux has Mono). Still, I consider that a major flaw.

The involvement of Rob Pike and Ken Thompson alone makes it worth a longer glance than most new languages. I only looked briefly yesterday, but it could be quite nice for a certain niche.

Actually, goroutines are green threads, so you can have a lot more of them before running out of memory, as compared to OS threads. Which is of course not new, but is a feature which works best when its natively supported by the compiler/runtime rather than hacked on. Further, programming languages are not about who came up with what feature first, but how the features combine (or not combine).

Because:

Do you trust the car makers to have a perfect piloting system? Even if they did, why not have the override option?

I guess what it all comes down to is freedom; the freedom to choose my own best practices rather than follow blindly the ideas of another.

I totally agree, but the people writing the code should choose the rules, not some skanky compiler. I will reference C# again as a fair example. The compiler generally does not enforce best practices with errors. The C# language specification, however, comes with a list of best practices, including how to space code. Visual Studio will automatically do the specified code spacing, but I can override it any time I wish.

Perhaps it would be nice if compilers could be loaded with sets of custom rules, instead of having a fixed set.

It does impact performance, but there are HUGE advantages to such a model; to name a few:
- Proper reliable reflection
- Constructing classes, instances, etc. on-the-fly
- Access control that goes beyond what the OS has to offer
- Self-contained assemblies (just dump a DLL into your project, and the types it contains, including documentation, are available to the compiler and the IDE)

This is all fine and dandy if it's a solo project, or if you are the lead and the rest of your team follows your guidelines. In other situations however, I'm thankful for any sane rule that the language, the compiler, or the IDE, forces on me and my team.

Which is exactly why nobody uses it these days.

No.

I watched the talk.. rather half of the talk. The big names got my interest since everyone including google is involved. Then the introduction really got my attention: a simple grammar, orthogonal features, systems level language with GC, etc. It really seems like simplicity at its best! .. And then I saw the code itself.

No. I think it's time for the next big language beyond C and C++.
One that:
executes just as fast or very close to C++.
makes programming easier and safer than C++.
still lets you mess things up if you want to.
lets the programmer use the full power of multiple cores easily and safely.

Anything more?

I didn't read the project page, so I'm just going to ask here. Is Go's standard library named Ogle?

Apparently that's the proposed name of the debugger.

Why would Google name it "Go"? Sure, it's catchy and has a similarity to their name but I can't even search for the board game Go. C was bad enough. However, not nearly as many people just start using the letter C when talking but Go is everywhere. I'd prefer to search for something in another language rather than try to find it done in Go.