This is on the opposite end of the spectrum from Swift which is controlled by Apple, which is not necessarily a bad thing depending on your perspective.
However, Go did originate at Google and the points the article makes about it having been designed to solve specific problems at Google are all true. It was not originally intended to be a widely-used general-purpose language: it just happened to catch on after it was released publicly.
Furthermore, the most significant contributors to the language design and its evolution (Rob Pike, Russ Cox, Andrew Gerrand, Brad Fitzpatrick, etc.) are all employed by Google.
It's not at all unfair or misleading to call it "Google's" in the way the article does.
Facebook uses PHP for much of their server-side stuff. They did a PHP compiler to make that tolerably fast.
Mozilla's Rust has potential, but I'm not convinced they have the "owning" logic right. Supposedly 10% of the code in Servo, their browser renderer, is "unsafe". That's far too high. They've had their first good big idea, but I think they're one or two key concepts short of definitively solving the problem of memory safety without garbage collection.
Swift I don't know about.
Interestingly, these are all hard-compiled languages. Most of the "flexibility" of scripting languages has been removed. It seems that the one scripting language feature programmers really wanted type inference for local variables. That's a feature of Go, Swift, Rust, and PHP. Even C++ has that now, with "auto". (Writing iterator type declarations in C++ FOR statements was a huge pain.) It's almost better if function parameters have hard types; you can look at the function definition and see what it wants. Python and JavaScript leave you wondering "what type is parameter 3 supposed to be, anyway?"
There's some syntactic convergence, too. Go, Rust, and Swift all use C-type brackets. Python indentation style control structure didn't catch on. We're also converging on "name: type", instead of C's "type name" form. That was a design mistake in C; the language became context-sensitive when "typedef" was added and the compiler had to known which words were type names. Where to put semicolons, though, is not converging.
Other features that I would put in that category:
- string interpolation
- a repl-like environment (fast startup, interactive, not requiring one to define a function or class to get some output)
- convenient syntax for initializing arrays and hashes
- generics as a most-of-the-time substitute for weak typing
A REPL environment is more of a tool chain issue than a language design issue.
Moreof, maybe, but it is language design, too. If you had a Java REPL, you still would have to type quite a bit of stuff (a class and a function) before you would have your "Hello, world".
Yes, you could add an implicit class named GLOBAL that magically gets a property named 'P' the moment you type
P = "Hello, world";
Most java code is valid Groovy code and it has some nice dynamic features, syntax sugar and has closures. I am currently using it to hack together a small DSL to easily configure a transformation from XML -> CSV
Here's an example of a Groovy session (From my instance of IntelliJ IDEA through Tools -> Groovy Console)
> P = "Hello world!"
Hello world!
> sub = P.substring(5)
world!
> sub ==~ / wo.+/ ? println("World") : {}()
WorldUp to Java 7 you could say "most" but why not "all"? Was it too difficult to test full compatibility? Why is the == slightly different between Java and Groovy, and the rest of the little differences which only confuse? And as for your example it doesn't look in the slightest like Java...
P = "Hello world!"
sub = P.substring(5)
sub ==~ / wo.+/ ? println("World") : {}()
Go for all intents and purposes IS a Google project. At least for now.
Yes, it was. That was always the intention.
I'm sure I was paraphrasing Rob Pike from one of his talks describing the origins within Google.