Google has invented a new programming language designed to reduce the complexity of coding without compromising the performance of applications. Called Go, the language has been tested internally at Google but is still at an experimental stage, so the company is releasing it as open-source code in the hope that it will get help with its future development.
I’ve read some docs on it and it seems very dirty to me. To elaborate, too many things are implicit and there are many built-in global functions (like len(), for example).
Having built-in functions reminds me of the days of Pascal.
Now, I said that too many things are implicit and here is an example of this: Any type, variable, constant of function of a package is public if and only if its name starts with an Uppercase letter.
Also, some things are not logical to me. For example:
Why not just
Functions can return more than one value (which is cool) like this:
A function that returns only one value looks like this:
So, I ask, why do we need parentheses when returning more values? Why can’t we just write this:
Now, I don’t want to be all critical. There are some good aspects of the language and some interesting ideas. Those implicit things I mentioned have an up side as well. Once you know the language well, I guess you can write code very fast.
Also, the Go code compiles very fast. It’s worth noting that it is a compiled language like C and yet it features many things from languages like Java, namely Garbage Collection and (I think) Reflection.
Oh, and by the way, the Go does not seem to be object-oriented (I am not sure.) and does not support exceptions…
Thanks for reading, and I would like to hear your comments of this.
Dirty perhaps.. but the mascot is so cute!
Rob Pike and Ken Thompson, who are leading the project, worked together previously on Plan 9 at Bell Labs, which had a similar looking mascot:
http://en.wikipedia.org/wiki/Glenda,_the_Plan_9_Bunny
It wouldn’t surprise me if this one was also drawn by Renee French (Pike’s wife).
Edited 2009-11-11 19:28 UTC
All issues (?) you’ve pointed out are just your personal preferences regarding the syntax. Is it really that important whether the import statement uses parentheses or not? To me any reasonably readable, regular and compact syntax will do, as long as the language has semantics and libraries I need.
The language is OO (more than C++ or Java for that matter), has very flexible type system and built-in concurrency primitives. Feature set is pretty conservative but it feels right for system-level programming.
Whether it is enough – hard to say. To promote a new system level language Google needs more than just a compiler, debugger and a basic class library. For start they should make Go a core part of their frameworks, just like what Sun or Microsoft did with Java or .Net.
I’m also a bit concerned about the binary compatibility, this issue should be dealt with asap or Go may end up going C++ route, where each compiler/architecture uses different calling conventions, symbol names mangling etc.
Please do elaborate (especially about Go being more OO than Java).
It uses interfaces to describe capabilities (i.e. duck typing), not a rigid class hierarchy. With no restrictions on what you can attach methods to, it is much more flexible and simpler mechanism than subclassing. “Subclassing” is still available through type embedding, btw. Whenever you embed other types, you automatically “inherit” their interfaces and implementations (of course, you can redefine some of their methods if you choose so).
OK. That is Prototype-based programming which is a kind of OO, but I don’t see how is that more object-oriented than Java. Is JavaScript more OO than Java?
Unlike Go, in Java everything is an object and although you could write a procedural Java code by putting everything in one static class, all those “static” keywords scream that you are doing it wrong.
In Go, however, you can write very C-like procedural programs without even knowing that you can make objects.
The point is, I still don’t know how Go can be considered more OO. In fact I argue that it is, in fact, just the opposite.
OO is (mostly) about leveraging polymorphism to create flexible code. Inheritance based polymorphism is probably the most tightly coupled and rigid form of polymorphism.
It’s not something you really get until you fully implement something in a language that is not class oriented the way that most of the c++-ish systems languages are. Really grokking something like ruby or smalltalk will totally change the way you look at these things.
Also, dynamic dispatch + duck typing does not nessicarily mean prototypal. For example, ruby is a strongly typed language where objects can (and often do) vary from their type. In js, you can do
“”.prototype.foo = new function() { .. }
that will add foo to all instances of string. in ruby, attaching a method to the string class is one option, another is to attach it to the instance, like
s = “”
def s.foo
..
end
s.foo # calls method
“”.foo # method not found, only exists on s
Anyways, all that to say that while prototypal programming is one way to do this sort of thing, doesn’t mean there aren’t others.
Java’s OO semantics have deficiencies that Go solves. To me it is equivalent to “Go can be considered more OO”.
It doesn’t mean that Java is bad – it’s actually my favorite system-level language. But that’s mostly because of its robust frameworks and the fact I’ve learned to live with its limitations.
The Java OO deficiencies (those that matter to me) are:
– non-OO primitive types,
– no multi class inheritance (for a good reason – it can get messy very quickly),
– limited interfaces (the only way to implement an interface is to write it by hand or inherit it from a (single!) base class).
Go simply doesn’t have these limitations.
I agree with you that one can write procedural programs in Go (and Java, C++,…). However, this doesn’t make the language non-OO, it’s just user’s choice not to use these capabilities.
—
Sorry about my comments regarding the Go syntax issues. I just can’t help thinking that even a bad syntax (which it isn’t) is at worst a nuisance.
I think his points are valid (regarding parens). They are not needed at their position for return variables. They come between “)” and “{“… the parser should not require the parens for a list of return vars.
It IS just opinion, but still, it seems like an extraneous thing that was unnecessary.
Built-in functions are fine with me… languages like Euphoria simply auto-include certain files that include oft-used functions. Same with Python, etc.
The bit about making a var/type public simply by capitalizing the first letter … that just doesn’t seem like a good idea.
But again, you are right, that is a matter of taste, I suppose. Like how some people get riled up about Python’s indentation rules.
“The bit about making a var/type public simply by capitalizing the first letter … that just doesn’t seem like a good idea.”
I think I can hear someone in China sigh.
I personally think it is a wonderful idea. It may be somewhat arbitrary and it wont be obvious to new users because the concept is somewhat unique, but what it DOES do is create a reason for differentiating starting case on your symbol names, and even better it has consequences.
Almost all languages have conventions for this, but none of them have a reason for it – it is simply convention. Convention without concrete purpose results in coding errors because people start to assume things due expectations based on convention.
For example, in many languages the convention is all uppercase variables are constants. But there is no consequence for not adhering to this (other than it will confuse the crap out of other people).
In go, a variable starting with an upper case character is publicly scoped – that isn’t a convention, it is a RESULT of making the starting character upper case.
I agree that it’s practical and it would go well with Python’s block indentation, but if you add too much of these “shortcuts” to a language you can make it difficult and full of “gotchas”.
Here is an example of where the parens are missing in a list of operations (for-loop and if syntax)…
19 func main() {
20 flag.Parse(); // Scans the arg list and sets up flags
21 var s string = “”;
22 for i := 0; i < flag.NArg(); i++ {
23 if i > 0 {
24 s += Space
25 }
26 s += flag.Arg(i)
27 }
28 if !*omitNewline {
29 s += Newline
30 }
31 os.Stdout.WriteString(s);
32 }
At first glance it all seems willy-nilly.
It DOES have some nice features tho… channeling… etc.
I think the inconsistant syntax, however, will be massaged out once the language gets further from the experimental stage.
I find that especially odd, since control structures (if, for, …) do not use parentheses, and “Go needs fewer parentheses” is listed as an advantage of Go’s formatting.
Of course, apart from that, Go might still be a nice language.
I’m not sure if there are any technical reasons, but IMHO the parentheses make it more obvious that it’s all part of the return type.
Go is fairly object-oriented, although a little differently from c++/java (no type hierarchy). Still, it has methods, interfaces, and the like.
As far as exceptions, the FAQ http://golang.org/doc/go_lang_faq.html
suggests that the authors are leaving it as an “open issue” for now, so they might still enter in some form, I guess.
While the lack of exceptions and generics/templates (also an “open issue”) make me a little worried, Go still seems like a nice improvement over C for most programs. I’m surprised they didn’t make a bigger deal of Go’s support for proper closures (at least according to the spec) and anonymous functions, though – making C++ functors is quite painful.
I was excited at the moment I read the title, but after reading the specs and the tutorial, I didn’t find it sexy.
Edited 2009-11-11 15:36 UTC
I think it’s pretty impressive to devise a wholly new programming language intended to compete with the “major languages” of today. Its major benefit: being just two years old (project started in 2007), rather than twenty (or forty, with some regenerations). This should have the potential of being headline news.
It remains to be seen how this language finds its way into the programming world. I’m missing a book (open-source of course) that teaches starting developers how to go about their way with Go. Fortunately, at this point, their connection for existing developers (mainly C/C++) is really decent.
I’m downloading the TechTalk video just now, it ought to be an interesting watch on my way home.
After reading the tutorial, I can say that it is already dead for me.
Compared with mainstream languages, and languages that are currently gaining momentum as well, Go doesn’t have much to offer.
And several syntactic elements look real strange, as many people already noted on the forums.
I won’t care about it.
Same here. I’d rather use Euphoria and/or groovy for pet projects. Heh. Actually I’d rather still be coding in VAX Ada and VAX BASIC. LOL!
If they manage to combine fast compiling with fast execution and the ability to do low level systems programming then they could be on to something. Not many other languages are working on that combination of features.
I like the idea
but, is this just jocaml with C syntax?
I think the designers of Go placed too much emphasis on fast compilation speeds. Apparently during early development they rejected a LLVM based solution because of slow compilation speed. Is compilation speed really that important? Maybe they should have gone the GHC route and provided a compiler and interpreter bundle. The GHC compiler can be a little sluggish sometimes, but the interpreter allows for quick iterative development by quickly catching all compile time errors when you load a source file. Leaving the slower, heavyweight compiler mainly for compiling optimized release builds rather then testing and debugging.
flynn wrote:
“I think the designers of Go placed too much emphasis on fast compilation speeds. Apparently during early development they rejected a LLVM based solution because of slow compilation speed. Is compilation speed really that important?”
This language was written to scratch Google developer’s own itch, so compile times were obviously an important factor for them. I like seeing a new language aimed at system level programing, glancing at the syntax it looks like it’s based on c. The language itself has some nice properties, like corout…(oops) goroutines with an outspoken aim of easing programming for concurrency, multithreading (which I guess will be it’s biggest draw). Being targeted at system level programming performance will obviously be important and using automatic garbage collection is more expensive than manual, however great development has been made in the field of garbage collecting so it will be interesting to see what it performs like (anyone know what method they use?). Anyway, good to see a new non-managed language, I’ll reserve further judgement until I’ve actually tried it and had a chance to see what the performance is like. Saying that it is ‘near’ c speed doesn’t really say that much since ‘near’ can be VERY broadly defined as we’ve seen in the past.
It’s really debatable whether the cost of automatic garbage collection is more than that of manual memory management, especially as the size and complexity of the program grows. I used to be firmly in the manual camp, but these days, it seems to be better to let the machine keep track of your memory, especially if correctness is required.
That said, Go’s garbage collector is (currently) based on a very primitive mark and sweep algorithm. It’s basically a child’s toy compared to the generational, iterative, compacting collectors found in the JVM and CLR.
It’s certainly interesting for language geeks, and I’ve spent too much time already digging through it because I like these things, but I don’t see a new non-managed language truly having much use going forward. The ability to distribute a single binary that can run on (and be optimized for) x86, AMD64, PPC, MIPS, Arm, etc has too many advantages to ignore. And there is no denying that the potential for optimization in a JIT compiler far exceeds that of a static compiler– even if we’re not quite there yet.
Edited 2009-11-12 00:40 UTC
The language is nice, but Go is not a good name… it’s hard to google for it, and Go Programming Language would be GPL, and is not easy to google it too.
But I will check it out.
Wouldn’t that be irony? It being hard to Google a Google language?
I will never understand languages that decide to break conventions. Maybe the ‘new’ way is marginally better, but is it worth mucking with the mind of developers who have to code in multiple languages.
var v2 string; // const std::string v2;
var v3 [10]int; // int v3[10];
oh jeez, let’s put the type after the name to be opposite of C. I find myself working with java and C# and have to second guess myself every now and then where the array [] goes. In C# (int[] arr1; ). In java String s[]; Now we have another permutation on something rather irrelevant.
They kind of address this in the lang design faq, but not directly, and its more to do with multiple declarations on the same line.
On the good side, I like their native support for Go Routines (threads), Go Channel (Message passing), unit testing
Always good to see another language though. I’ll see if their *quick* compile time really plays out. Knowing Google… it probably does.
In java – String[] s; and String s[]; are equivalent – one of the few odd places in java where there are two ways of doing exactly the same thing.
Right. Java convention prefers the former, since it arguably makes a lot more sense to keep the type information together. But the compiler accepts both syntaxes…
aaah, I stand enlightened
I guess I don’t need to be careful about that in Java. Might save me what is left of my brain cells.
Pretty sure there are a lot more languages out there where the type goes after the variable rather then before. works that way in c# 3.5+ too
var bar = new Foo()
It seems to me like a cross between Smalltalk and C with better concurrency features.
[OT] I really have enjoyed working with the D programming language lately. D is a systems programming language that more similar to C++ than any other language, but IMO D is much nicer that C++. [/OT]
I love this:
In other words, “We desire for the open source community to write free sh*t for us.” I don’t write open source software for a living, but if I did, I’d be sort of offended by this. Here’s a novel idea… if they need more coders/testers, why don’t they hire some, instead of expecting the open source crowd to do it for $0?
Of course, I realize that not everybody is in it for the money, but if you’re going to write/test code for a for-profit company, you should expect to be paid for it, IMHO.
Developers would not be writing and testing for a for-profit company. They would be writing and testing for an open-source project which they and others presumably find useful. “Others” being Inclusive of Google, of course, which did the major grunt work to get the project this far, and released into the OSS community.
I’m not a current Go developer at Google, but if I were, I’d be offended by your ingrateful post.
Edited 2009-11-11 19:50 UTC
Previous poster is right, Google is ran by cheapskates.
If they want some more libraries then they should hire some more developers.
If you don’t want to contribute, don’t contribute. Simple as that. Though neither of you seem like the sort of people who contribute code to OSS projects, anyway. Am I right?
As the score stands now regarding this project, it’s Google and its paid employees which have done all the contributing.
Edited 2009-11-12 17:01 UTC
i think problem with Go is that it is initially designed by two old (maybe long bearded) respectable unix guys. But because of their mind set Syntax seems cryptic and somewhat too low level – alien. i wish they got two higher level masters from Google into their group (Rossum and Bloch). I also wish Google came up with next generation Java instead..
Rob Pike give a 1hr talk on Go on Oct 30.
http://www.youtube.com/watch?v=rKnDgT73v8s
What also bothers is me is, Rob Pike doesn’t have any facial hair. Ken Thompson has, so I guess it’s ok.
Google isn’t the first to call a programming language Go.
Here’s a link to the other Go’s book.
http://www.lulu.com/content/paperback-book/lets-go/641689
From Wikipedia:
———————————————————
It should be noted some issues with google’s choice of name “Go” is in conflict with that of a previously released programming language called “Go!” by F. G. McCabe and K. L. Clark in 2004. The naming issue is discussed on Google’s Go page, with current popular consensus that it should be renamed as “Issue 9”
———————————————————
I assume “Issue 9” is a loose reference to Plan9.
Loose reference yes. Also a direct reference to the fact that the name conflict is issue 9 in the google code issue tracker for the go language project:
http://code.google.com/p/go/issues/detail?id=9
I really like their approach on polymorphism and concurrency!
It looks, to me, like a mix of Objective-C and Java. I had wished for something like this would be supported by Java as I mostly prefer composition to sub-classing. Even James Gosling seems to agree:
http://www.artima.com/intv/gosling34.html
http://www.artima.com/intv/gosling13.html
The syntax reminds me a lot of the “D” programming language. I’d probably prefer to use D though, given that it has goodies like lazy evaluation.
I also find D quite nice, but not sure if it will ever gain traction.
Still waiting on D 2.0 to come out. And out is all about the low level calls when you need to use D on Windows?
Some aspects of this language seem really nice, especially the concurrency support and speed. I don’t particularly like the syntax, but it’s alright. However, one feature I really can’t live without is generics. If they added generics I’d probably start using it right now for all my projects.
I find coding in languages without dynamic dispatch and type inference nowadays feels like working with a chisel on stone when you are used to a paintbrush on canvas. It is fantastic to see someone (other then scala) bring this to a systems language, and the fact that it is unmanaged makes it downright unique. Also, compiling 120k lines of code in 8 seconds, and 1k lines in 20 milliseconds is downright delightful. Compiled languages tend to be horribly unproductive when working through the refactor/compile/test cycle compared to languages that take out the middle step.
They are pretty far from prime time still (standard library seems rather anemic), but I think this is one of the most interesting new languages I have seen in a very long time. If they are able to match c performance with those kinds of features, all the current systems languages will have going for them is the mountains of existing code already written in them.
The real problem with low-level programming is libraries that allow performing useful stuff, not how many parentheses and where you write declaring array variables.
E.g. Fortran is still used in numerical computations because there are vast libraries of already developed code, going back to 1960’s.
Fast compilation? Hmmm. Why would I need fast compilation when the language itself has weak library (I’ve had a look at it, it is quite patchy) and this won’t allow me to easily ‘say’ what I want to say solving concrete low-level programming problem?
Edited 2009-11-12 13:50 UTC
The real problem with low-level programming is libraries that allow performing useful stuff, not how many parentheses and where you write declaring array variables.
E.g. Fortran is still used in numerical computations because there are vast libraries of already developed code, going back to 1960’s.
Fast compilation? Hmmm. Why would I need fast compilation when the language itself has weak library (I’ve had a look at it, it is quite patchy) and this won’t allow me to easily ‘say’ what I want to say using concrete low-level programming problem?
Edited 2009-11-12 14:03 UTC
It looks like a remake of the Limbo programming language (part of the Inferno operating system
It was also conceived by Kernighan, Ritchie & Pike while they were at Bell Labs…
http://en.wikipedia.org/wiki/Limbo_%28programming_language%…
http://www.vitanuova.com/inferno/limbo.html
semi-C syntax + concurrency – delegation/inheritance
0. The whole “type after variable” feels very weird in this as compared to other languages which do the same.
1. No inheritance or delegation..
It seems to have the Dylan (and CLisp) style of decoupling the class from the methods; but I really find the method syntax confusing.
func (this Class) method(arg1 Arg1, arg2 Arg2) Ret {}
It looks clean but I keep getting mixed up on lot of occassions. The new C++0x syntax on the other hand:
[] Class::method(Arg1 arg1, Arg2 arg2) -> Ret {}
While more senile, I actually find it easier to read.
2. The mechanism for maps was very awkward to me.
Although I don’t think it offers anything new. Also I don’t quite get how it can have C++ like speeds..
The interface stuff is completely new, I think. It’s also insanely cool – static duck typing without the template complexity :-).
Edited 2009-11-13 11:17 UTC
I had thought about it.. It’s (probably) not like templates.
The deal is; first I thought it was the (removed) C++0x Concepts i.e., interfaces for templates — which is *exactly* the same as this (cept for the extra syntax).
But if it’s like implicit C++ concepts, then every time you pass an object of a different class it would compile a new function meant specifically for that class. Considering how there’s no inheritance, that would seriously increase the executable file size..
The alternative is that it’s similar to pure-virtual classes, which wouldn’t give it C++-template like speeds..
I trust they have something clever cooked up for this. It may also be that google doesn’t care about the size that much.
It’s also very possible to use polymorphic vtables for this. Just create a different per-class vtable for every interface the class implements.
Instead of speculating I’d rather just wait for someone to explain what exactly they are doing ;-).
http://www.reddit.com/r/programming/comments/a3hku/mark_c_chucarrol…
Ah, that’s *exactly* what I was trying to say earlier but I wasn’t sure if I had the right words… Nevertheless, that means it is as efficient as “virtual C++”.
Which would also explain the benchmarks:
http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=g…
There is no point wasting too much time on benchmark comparisons right now, esp. for the “6g” compiler which doesn’t optimize seriously yet.
Go by no means forces you to use interfaces, direct method calls don’t go through the interface jump table.
No, but it sure gives one a rough estimate of how ‘fast’ a language because I don’t think optimizations can contribute to a great change in it, especially because it’s not like Java or C# which has a complex type system or so, but then I’m not so knowledgeable in this area.
Also, interfaces are not used in that submitted code (which is by the Go creators)..
I’m just sceptical about the “as fast as C” claims when the languages are of much higher-level. And Go is sufficiently high level. After optimizations I expect it to optimistically meet the speeds of C# Mono implementation but not too much more than that..
Edited 2009-11-14 15:37 UTC
just the very idea that we need to “open source” a programming language shows how stupid the whole IP/copyright/patent issue has become.