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.
Go, as it stands, is intended for getting good performance in server-side applications. There's good support for huge numbers of simultaneous network connections, and no standard GUI support. Google needed something; C++ has too many memory problems and Python is too slow.
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.
There are two things going on in Servo that are causing it to use a lot of unsafe { ... } blocks. First, it still depends on a large amount of large c libraries, like SpiderMonkey for JavaScript. We automatically treat c foreign functions as unsafe as we can't protect against them doing unsafe things. Second, the DOM is very much built on an object oriented class hierarchy, and we in rust have put off figuring out how we can support that until after 1.0. So Servo uses unsafe code to hack around our temporary lack of support for that feature. So while there may be a lot of unsafe blocks, it should only be for the short/medium term.
There is convergence on hashed dictionaries as a basic type, and syntax for subarrays. Generics are still up in the air. Templates got so complex in C++ that they ate the language. Go avoids generics, but that leads to over-use of the any type ("interface{}" in Go) and reflection. Rust is somewhere in between.
A REPL environment is more of a tool chain issue than a language design issue.
"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
Actually, I really enjoy using Groovy as a Java REPL, when having to use Java. Your code is run in a Script class
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") : {}()
World
Up 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") : {}()
Why wasn't Groovy updated so most java 8 code is also valid Groovy code? And why didn't you actually post some code to do something useful like "configure a transformation from XML -> CSV" instead of creating a HN login to post a meaningless syntax sample?
Completely spot on. And we know how this works in other open source projects. When you have most of the committers from one company they do ultimately drive the direction in their favour.
Go for all intents and purposes IS a Google project. At least for now.
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.