Stack OverflowWhat's your take on the programming language Go?
[+159] [60] fbrereto
[2009-11-11 00:14:45]
[ programming-languages go ]

I've just been told about a new programming language, Go [1], developed at Google by such notables as Ken Thompson and Rob Pike. Does anyone have any experience with it so far? What are your thoughts about how viable small- and large-scale applications could be developed with it?

Relevant links (thanks to Lance Roberts; feel free to update these as necessary):

(1) Dynamic dispatch only through interfaces - that sounds overly restrictive to me. - Georg Fritzsche
(291) countdown to first job asking for 3years experience in this .... - Martin Beckett
(10) hehe, I love the use of Kanji in the Hello "sekai" example! - hasen j
(5) oh btw, no windows port, does google hate ms that much ?? @_@ - kar
(5) Well, the Go guys are clearly Unix guys. Makes sense there'd be no Windows port. I'm sure that'll change. But it could take awhile. Look how long it took to get Chrome on Mac. - Nosredna
(1) x10 looks better. - Sake
(7) "goroutines"? Seriously? - Pillsy
(1) @mgb: great comment! - RageZ
(43) Please do not close this. - Frank
(5) @Pillsy: we're better off if they make new words for their new concepts, rather than pollute existing concepts with them. - György Andrasek
(4) @mgb what do you mean... I already have 5 years commercial experience in Go on my CV.... mostly the variant GoFigure - geocoin
(1) I just want to know what happened to the first four versions of the language ... :-) - Stephen C
(40) firstly, this is a community wiki sort of question. secondly, I think the name of the language will prove to be a pain: try googling "go this" or "go that". See where I am coming from? It's like naming a language "the" or "a"... - Peter Perháč
>sigh< no silver bullet. - jpinto3912
(1) Upset me greatly by completely excluding those developers true to MS. It's an insult, one would not have expected this to happen in the third millennium! - Peter Perháč
(4) Yeah! How dare they release a new language without .NET support! - György Andrasek
(45) Hard to say. New languages come and GO. - Developer Art
(4) Aarg I'm confused, first it was Ruby, then Haskell, then Erlang, then suddenly Javascript, then Scala, then D, and no it's Go! Who do I have to believe!? - StackedCrooked
(3) @Jurily No doubt Visual Go.Net will be along soon... - George Shore
(3) @MasterPeter: Surely Google would know Googling the language would be a problem. Think they did it on purpose? P.S. If this came from anyone but Google, it would be completely ignored. - Mark Ransom
(2) c'mon people, this is a gossip thread, not a serious programming question. Vote to close. - Steven A. Lowe
(5) Now Microsoft will release the language Micro with a debugger named Soft. - Chap
(1) Chap: Wouldn't that be Mic? But no, they won't until the language matures and all the flaws are taken away. Then, MS will take all the good parts, will make a list of the rants and will release a new programming language will all those innovations - OscarRyz
(2) @StackedCrooked Yourself? I can't wait to complete my own programming language! Meanwhile, all these languages are great because even if they fail, they bring new concepts to the knowledge of programmers, which can pick the good ones to develop newer - better - languages. - luiscubal
I think GO must go on providing best performance for the GO applications. - Himadri
(2) @George Shore: No, the .Net version will be called G#. - Dennis Williamson
(7) @MasterPeter, yeah but try googling for information about languages like C and D. Go at least gives us two characters.... - quark
Anything from Google GOes, that is, new Google products are generally well accepted. - Zach
(1) Could you un-accept my answer please? - community_owned
[+110] [2009-11-11 01:58:19] Sergio Tapia [ACCEPTED]

I just feel that it is yet another language. Nothing really special about it except that it is new and is far from mature. We'll have to see.

(65) Most languages created today are created to compete with functional languages (haskell, F#) or scripted languages (ruby, python). This is the first new language looking to compete with something as low level as C. - vanja.
(27) I got the impression that it was more in competition with Java/C# than with C. - MAK
(37) @vanja, Actually D tried it before (still trying, too) - hasen j
One word - channels! Occam rises again :) - Martin Thompson
(56) I think the incredibly fast build times, the promise of latency free garbage collection, built in concurrency and multicore/processor support with only a 10-20% overhead over C makes this language special. How can you not see the value in that? I think it's special, albeit immature and experimental - Pierre-Antoine LaFayette
(21) @Pierre, that sounds remarkably like C#/.NET :o - 280Z28
(1) Be beware of the fact that the current .NET GC ain't latency free. Same for Mono's current GC. Though .NET's gets a new GC. - Dykam
Same for Mono though, but the new GC for Mono won't be latency free either. - Dykam
(1) And sounds more like Parallel C#/.Net :D. - Dykam
I just thought it funny how Rob kept going out of the way to avoid mentioning C#/.NET - keithwarren7
(1) If you read carefully, GO's gc isn't latency free either. They have merely promised to have a latency free GC "soon" - Breton
(2) @hasen j - I'm not convinced. D has so many language features and utility libraries built in. Feels more like a competitor to C++ than C. - vanja.
(1) Looks nice to me. It actually reminds me most about Erlang with the focus on very simple multiprocess programming, but with a more familiar syntax (Erlang is based on Prolog) and conveniences like variables (which Erlang doesn't have). I think it's a great approach for scalable (as in multi-core) programming, vastly superior to Java threads or Ruby processes - j-g-faustus
(3) Looks good. Hope it GOes well. - fastcodejava
(1) What an insipid answer. - aehlke
(3) This guy doesn't even understand how there is any difference between C# and Java, if you look at his posts. - aehlke
(6) 124 up-votes for an answer than anyone could produce just by guessing? - Andreas Rejbrand
(1) C++ has some problems like that it takes very long to compile.. go addresses some of these. On the other hand also go is slower and some stuff is still missing.. - Nils
You'd accept this from a "ASP.Net MVC2" programmer? I don't even know what that drivel is, let alone whether it requires knowledge of computer architecture or languages. - Matt Joiner
@Matt Joiner: lol u mad? - community_owned
Well... You feel. Have you tried it yet? And if you did, do you understand the differences of it from other languages? - Zippoxer
I'm also sure that ATLEAST 98% of the upvoters for this question, did not try Go and they also think that the language they use is the best. - Zippoxer
[+63] [2009-11-11 04:19:29] ceo

Having spent the day wrestling with some tricky BGP parsing in regular old C, and then having spent part of the trip home thinking about what a new systems language that combined the speed and simplicity of C with proper memory management, built-in concurrency support etc. would look like, I read through the Go materials with a good bit of interest. First impressions:

  • I really like multiple return values. You can do that in Perl, sort of, by returning a list.
  • The concurrency model is interesting. I've thought for a long time that this was something that really needed to be built into a language, and Go does it at a basic syntactical level.
  • I don't see anything in the way of built-in containers, other than statically-allocated arrays.
  • I like the rethinking of things like for loops, switches and printf(). Too many languages (I'm looking at you, Java and Perl) simply copy these verbatim from C.
  • Interesting that they took Java's concept of interfaces and divorced it from any kind of type hierarchy.

There's a lot of work yet to be done, but it's among the better candidates for Next Big Thing that I've seen in recent years.

(2) Well, they do have built-in hash tables (called maps)... - Jeremy Friesner
(17) When is the Next Big Thing coming out? Anyone know? I am desperate for it :) - Peter Perháč
(1) "I really like multiple return values. You can do that in Perl, sort of, by returning a list." >> of course, in POC, you can alwas return a struct. - René Nyffenegger
Copying loop constructs, you might include java script and c#. Arguably worse as they're more recent than perl and java. - mike g
(3) The interfaces system actually doesn't come from Java at all. It is actually much more like (or equivalent to?) type classes. - Thomas
(1) +1 for concurrency - luiscubal
(1) Re: No containers: Yes they stated that generics are missing and they would like to add them as soon as they decide the correct approach. So right now you cannot create type-safe containers (List<Integer>, Set<String>, etc). - Mark Renouf
(1) Someone else felt the same as you about C, his name was Bjarne and he created C++. SBRM/RAII is the best GC I've ever used! Return boost::tuple. And for concurrency OpenMP is pretty standard across compilers; and though it's definitely not an end all, they are working on concurrency issues like every other language is right now... - joshperry
[+47] [2009-11-11 22:48:18] Matthew Crumley

The gopher is probably the best programming language mascot ever.

alt text

(14) Yeah, I could gopher that. hides - Michael Myers
(8) Dramatic Gopher? - Mark Renouf
@Renouf - Victor Rodrigues
Is that sarcastic? - acidzombie24
@acidzombie: not at all, I just think it's hilarious. Of course, not many programming languages even have mascots, so there's not much to compare it to. - Matthew Crumley
[+40] [2009-11-11 02:16:39] Nosredna

I think the compilation speed is more important that people realize. I don't think it's "yet another programming language." I think it might be a big deal.

I watched the hour long video: Before that, I was skeptical.

(2) yes much like D lang, you never realize until you really need it. - kar
(29) I wanted to like D, but it seems like a bit of a train wreck. - Nosredna
I haven't seen the video yet (no time, I tag it for the weekend). I agree that compilation time is important, but don't you think that the more work the compiler does, the better? I mean, compilation flags can help us choose between better code and faster compilation, and when we want better code, we want better code. Also Moore's law is on our side when we want faster compilation. I will have to see the video to see if it's such a big deal. - machielo
You can have an hour long loop counting 2+2, but is it better? - György Andrasek
For compilations speeds, take a look at the haXe compiler, it is blazing fast. - Dykam
(4) +1 I was skeptical too until I saw the video: I have always wondered, what would be Rob Pike and Ken Thompson doing at google all this time. now I know! - OscarRyz
If you want fast compilation speed, there are other options - choosing Go just because of that doesn't seem a good choice. Delphi is the obvious candidate (very fast single-pass compiler, and is a more 'normal' language.) C# is okay-ish too. - David M
(10) +1 for watching video first and voicing opinion later. - mizipzor
(5) @mizipzor, obviously, I'd never make it as a reporter on any of the 24-hour cable news channels. - Nosredna
@Machielo: I don't think Moore's law is on our side for compilation anymore (at least for individual source units)--it's pretty hard to parallelize and single cores aren't getting faster anymore. That said, I think compilation speed is a rotten reason to choose a statically-typed language. - Drew Hall
[+38] [2009-11-11 06:24:44] Frank Krueger


Yet another C Language. Yet another for syntax. What's the contribution again?

Oh and he broke the cardinal rule of C languages:

If you want your new C-syntax language to succeed, run far far away from any syntax that uses :=

(I am making no judgement on the usefulness of :=. I am simply stating a fact that every adaptation of the C language that has used that syntax has failed to catch on in popularity. See A Modest Proposal: C++ Resyntaxed [1].)


(21) why, the := is one of Go's best features. - Peter Perháč
(52) In virtually all the keyboards I've used, either the = is lowercase and the : uppercase, or the reverse. I type a lot of assignment operators, particularly in C, and find having to type a single operator while changing the shift key status annoying. I hated it in Pascal, about thirty years ago, and I still hate it. - David Thornley
(23) Using the := operator is optional though. It's just a shortcut for variable declaration/initialization, e.g. x := initialValue; is the same as var x = initialValue;. - Matthew Crumley
(6) So declaring a variable uses the exact same syntax as a fairly common method of assignment? I don't think I like that either. - David Thornley
That is a valid point, although lots of programmers coming from a C-family background have probably never used languages with := assignments. For me, I'd probably just use var x... anyway since that's what I'm used to. I don't see much benefit to the slightly shorter syntax. - Matthew Crumley
(2) My delphi IDE is set to auto-correct ';=' to ':=' - I never type ':=' manually. It still annoys me, though. - Blorgbeard
(1) var x = intialValue and x := initialValue are giving me this warm and fuzzy nostalgic feeling for Pascal. :-) - ceo
(4) @David. You should try a Scandinavian keyboard. - Jonas
On my keyboard layout := is on altgr+a and altgr+f, respectively. Its not hard to type. Still dont like it though, why do you need to make assignment a two character command when you do it so much? - mizipzor
@David Thornley: So ... := |= ANNOYING ? - Tim Post
@mizipzor, := is for initialization (and only if you want to leave off var and the type), not assignment. You never have to use it if you don't want to. - Matthew Crumley
(15) well, <= and >= are widely used, and they have the same shift key problem. I don't see an issue with it. - GSto
<= and >= (and =>) have the advantage that the two characters are typed using two different fingers. := uses the same finger for both characters, which makes it more annoying. - Kyralessa
What are you talking about? I use my index finger for : and my middle finger for = :D - trinithis
@trinithis: If I did that on my keyboard, I'd be hunting and pecking. On this standard US keyboard, the home position for the little finger is on the ;/: key, and the =/+ key is way to the upper right. Both would normally be typed by the right little finger, which really isn't a good finger to task with combinations like this. - David Thornley
About the keyboard difficulty: typing the whole type name is easier? - Zippoxer
[+37] [2009-11-11 18:24:42] Thomas

I've only watched the talk [1], read the FAQ [2] and skimmed some other stuff on the website [3]; not actually tried it. But here's my take.


  • Strict typing; no implicit conversions. This will catch many more errors at compile time, and is a huge selling point in my book.
  • No need for explicit types on variable declarations (i.e. automatic type inference, like var in C# 3.0).
  • Interfaces with support for "multiple inheritance", reminiscent of Haskell type classes and ex-C++0x concepts.
  • Method declarations separate from the types they operate on, so extension methods (also on interfaces) are trivially possible.
  • Garbage collected.
  • Fairly clean and seemingly quite consistent syntax.
  • Closures.
  • Easy to use, lightweight concurrency constructs (channels, goroutines and the select construct).
  • Fast! Fast compiling and fast code.
  • Decent Unicode support.
  • Some slightly ugly but really practical idioms (see Effective Go [4]), such as iota and the improved switch.
  • Comes from Google. Even if that doesn't say anything about the quality of the language itself, that fact still gives it momentum and publicity. That is something an open source project badly needs.
  • BSD licensed, no pesky GPL. Also good for momentum.


  • Lack of functional constructs like map and filter. Everything feels very imperative still. Python does a much better job here. But with the things present in the language, these constructs could be implemented as a library (i.e. not requiring syntactical support).
  • No generics (yet). The interface system partly makes up for it, but I think Go could really benefit from a generics system similar to Haskell's.
  • No overloading. We see in Haskell (liftM, liftM2, liftM3...) that this can be a pain.
  • Unlike variables, there's no type inference for methods and functions.
  • Not a very clean syntax (e.g. like Python). Feels like C with less braces.
  • No mutually recursive imports.
  • Simple-minded garbage collector. But that's being worked on.
  • Interfaces can be implemented implicitly. You just define all the methods needed. That seems convenient at first sight. But if you rename a method without knowing that it was needed to implement some interface... boom. (Same problem as with duck typing, but less so, because errors are detected at compile time.)

Bottom line: I think Go is an interesting development. There are few languages that offer such a rich feature set but still compile directly to machine code. There are no ground-breaking new developments, but Go does bring together some concepts that haven't been brought together before. I'm curious to see how the language will fare in practice.


The need to use make() in certain places strikes me as a "con" for the language. Creations and/or initialization via the new operator in all cases is a lot clearer and more familiar pattern - Sean
I did consider including this, but figured it would not be a problem for anyone but absolute beginners. I'm mostly trying to determine how Go will fare in the hands of an experienced Go programmer. - Thomas
(4) I think Interfaces are a huge Pro. There should be no 'boom' as the error is catched at compile time. - Kosta
(1) @Kosta: It depends on your point of view. I have actually changed my mind about this point since I wrote this post, so I see what you mean :) - Thomas
[+33] [2009-11-11 05:03:15] community_owned

A type-safe language with concurrency support, garbage-collection, a succinct C-like syntax and compiles 120,000 lines of code in about 8 seconds on a Mac laptop. The C/C++ edit-compile-link cycle has essentially been "eliminated".

Let's throw in that it was designed by a couple of famous former Bell Lab guys for a little buzz.

Hmmmm....I'd say we have a winner.

Compiling 120,000 lines of code in 8 seconds is a really poor performance. - ntd
(10) Winner? Not till the authors pass the beard test: :-) - csl
It's just C/C++ having a amazing slow compilation, other languages compile way faster. - Dykam
(2) Another interesting note - by doing away with some unnecessary and rarely used features and reworking packages and linking rules, Go will allow for much faster automated code analysis - Chris King
(37) One of the authors is ON that beard page you linked to. - nos
There are plenty of options if you want fast compilation (especially if you just want faster than C++, but still want a C++-like language or features.) One of Delphi's big selling points for many years was the speed of its compiler. It's still blazingly fast. Every so often I switch from C++ and write a Delphi program and it's still cool to press F9 (the Run key) and have it just run pretty much immediately. In fact quite a bit of what I've read of Go so far reminds me of what is being done in the Delphi language recently or in its roadmap. - David M
Our 240,000 lines of code C# solution compiles in 7 seconds (on a PC, I have no idea how fast that would be on a Mac laptop ;)) - Marek
@Marek: C# compile speed does not count until you include the CIL to x86 compilation step also. - Zan Lynx
@Dykam: Please don't use the term "C/C++". Compile C with a C compiler, and you'll notice it's 1-2 orders of magnitude faster, depending on how much stupid crap you're doing with the nastier "features" of C++. My last project measured a 15 fold difference between the two, in C's favor. - Matt Joiner
@Matt Joiner, C is indeed faster to compile, but 1-2 orders of magnitude is still very slow. - Dykam
[+28] [2009-11-11 15:40:11] Nemanja Trifunovic

One problem I have with Go is that they speak of it as a "system" language. In my mind, a system language is something you write kernels or real-time stuff with, and mandatory non-deterministic garbage collection rules out Go for most such tasks. Then it turns out that by "system language" they really mean "server applications". Sure, Go looks fine for that purpose, but not many people consider it system programming.

(4) +1 Good point. Server applications is not what comes to mind when speaking of a "system language". - StackedCrooked
(10) Man, there's a lot of "systems language work" that does NOT qualify as real time. Probably 90% or more of it. - Nosredna
(1) @Nosredna. That's why I said "or real-time". - Nemanja Trifunovic
(1) No, I disagree, they mean writing systems as sets of lightweight communicating processes. You can write a kernel using this abstraction. - LB
(12) I disagree, actually. Systems programming, in my mind, is "applications that don't interface with a user". I think daemons fall under the purview of "system" programming, as the alternative is "application" programming. You won't find a daemon worth its salt written in an application programming language -- I can think of a bunch written in C. - Jed Smith
(4) I interpreted "system language" as "this is not just another web scripting language", for anyone who looked at it for a few seconds and thought "yawn... another C#". - Graeme Perrow
(2) Isn't the web browser an integral part of the OS that definately can't be removed? I seem to remember something about that. - Martin Beckett
@mgb are you talking about windows? - hasen j
(1) I've been trying to find a better systems programming language than C/C++ for ages, this may be it. - Longpoke
Go is another iteration of Alef/Limbo which are the systems languages the Plan 9 and Inferno OS respectively. - Pete Kirkham
But anyway, in most applications you'll ever build, you'll implement a garbage collector, so why? better let the compiler do that for you. - Zippoxer
[+20] [2009-11-11 00:27:43] Lance Roberts


Ars-Technica [1]

PC World [2]

Google Open Source Blog [3]

Tech Talk Video [4]

Go with Google - Yet Another Language! [5]

Getting started with Google's Go [6]


(5) You should add the tech talk: - hasen j
Got it, thanks. - Lance Roberts
and Go with Google - Yet Another Language!… Getting started with Google's Go… - mikej
@mikej, thanks, got it. - Lance Roberts
[+18] [2009-11-11 03:18:49] hasen j

First thought: wow, D done right! Proper mix of Python and C.

After watching the TechTalk [1]:

  • Syntax is a bit ugly (could be prettier)
    • Don't like := syntax
    • You still need for i = 0; i < 10; i++?? seriously?
    • Too many braces, stars, ampersands.
  • The interface thing is brilliant! Can't wait to use it.
  • The channel concept is interesting, not sure what to think about it though.

I've seen the idea for the way they did interfaces before when discussing various OOP languages' shortcomings. But this is the first language I've seen that does it. So not brilliant so much as first to market. - jmucchiello
(7) At least it's not Interger::Iterator::non_constant_forward i=Interger::Iterator::begin() ... - Martin Beckett
(9) The old ugly for;; is there, but at least there's a "foreach" style for too: for key,value := range someCollection { ... } - Grumdrig
(4) I dare you to find something more flexible than the old ugly for. - György Andrasek
@Jurily: The Python for manages to be clean - Matt Joiner
Ugly syntax is subjective and based primarily on your experience. I've grown to dislike the huge indentation of C#, Java, etc after using go. At least it forces a brace style and naming convention, ending two ridiculous age old debates. i := is optional, you can use var i = instead. for can be for key, value := range someSliceOrMap, and in the "old" syntax all sections are optional. If you don't want to initialize any variables, just use for ; i < 10; i++ { ... }. If you wish for a while-style loop, you can use use for i == 0. Infinite loops are even cleaner: for { ... }. - crazy2be
[+17] [2009-11-11 17:17:14] OscarRyz

I have just seen the introductory video [1]

This I what I liked ( from what I understood )

  • Braces are used ALWAYS [2]!

    I have always had problems with that in production code. It may be considered as an small improvement, but once, I spend >3 hrs. debugging an error caused by a misplaced if. It is a nightmare.


  if x > 0  
       return 0;


  if x > 0 return 0;


  if  x > 0   { 
      return 0;


  if x > 0   { return 0; }


Visible outside the package:

func Print(v ...) { 

Not visible outside the package

func print( v ... ) {

Yes, it may be an small improvement in the code syntax too, yet, important and a easy way to create public methods/attributes etc. and finish with a lot of discussions.

  • Interface [4] you can plugin "anything" that accomplish the interface ( like in duck type if it says quack is a duck ) and yet have compile time checking for safety.

So the interface declare the quack method

type Quack interface {

And then we can may create a function using that type:

func callIt( duck Quack ) {

To use it we only need "something" that respond to the message, for instance, a Duck and a Person they perform the function DoQuack diferently

type Duck struct {
    count int

func( d* Duck ) DoQuack() {
    for i:= 0; i < d.count ; i++ {
        fmt.Print("quack!" )

type Person struct {}

func ( o* Person ) DoQuack() {
    fmt.Printf("Ehem, I'll try it... quack?\n")

Finally the check if the "struct" complies with the interface is performed by the compiler when the type is used:

func main() {
    var quack Quack
    quack = &Duck{} 
    callIt( quack )
    callIt( quack )
    callIt( quack )
    quack = &Person{}
    callIt( quack )    


Ehem, I'll try it... quack?
  • Syntax

Something I didn't quite like is the syntax ... :-S I don't know how to explain it, but at this point ( 2009 ) programming languages should just flow. Go syntax, makes me stop and think twice what each line is. Probably that's just matter of getting use to it.

There are plenty of features, like the channels and the goroutines ( similar to threads ) that look pretty cool, but I think It would take me some more time to grasp them.

Finally from a sample from the install page:

I can see that: real programmers use cat [5]!!!

$ cat >hello.go <<EOF
package main

import "fmt"

func main() {
    fmt.Printf("hello, world\n")
$ 6g hello.go
$ 6l hello.6
$ ./6.out
hello, world



(3) I really wish they had used a Python-esque syntax :( - Longpoke
(2) <aol/> And to satisfy SO's 15char min limit: I really thought the same. Why not use Python syntax, but just not be as dynamic? I'd suspect there'd be some "market" there. - jae
sigh, I thought the same - Kugel
I disagree. Python's syntax really is not good for writing function literals IMHO - Kosta
We are not referring only to function literals, but the rest of it ( a simple if comes to my mind ) - OscarRyz
(1) Yay for mandatory braces. Optional braces was my very, very, very least favorite aspect of C (and most of its descendants). - Adam Crossland
@jae: I'd buy that. Lets do it. - Matt Joiner
[+16] [2009-11-11 13:55:27] Peter Perháč

Hey - this looks like a real smasher!

… concurrent

Go promotes writing systems and servers as sets of lightweight communicating processes, called goroutines, with strong support from the language. Run thousands of goroutines if you want—and say good-bye to stack overflows.

[ Go website [1]]

Could Go really be the end of this wonderful experience? I will miss S.O.! SO MUCH!


(2) And just doesn't have the same ring to it. - ceo
(12) I'm thinking this sounded funnier in your head :) - San Jacinto
Go still has a call stack and overflows can happen just like in C. - Andrey Vlasovskikh
[+16] [2009-11-12 07:20:51] Graham

Go is to C as Google Wave is to Email.

That means, "Go" and "Wave" are both Google's answer to "what would X be like if it were invented today?" (X = system progamming language or email)

When they say Go is for "system programming", I see Go as the best language thus far for software that runs in userspace but does not directly interface to users. That is daemons like httpd, udev, d-bus, upstart etc would be most conveniently written in Go. Classic unix command-line tools would also be easier to write in Go, except they've already been done in C and don't need the concurrency. Notice that Go is not for scripting nor GUIs, and in the interest of portability there is no way to add assembly code for writing a kernel, and you don't want garbage collection in a kernel language anyway.

Also, Go is designed for concurrent programming on a multiprocessor system - so its not meant for your old mobile phone but your desktops and servers. The "hello world" binaries at around 600KiB is oversized for embedded work, and garbage collection won't do in low-memory environments. But we may see it on mobile computing devices like Android phones.

The 600KiB "hello world" is due to static linking - I believe dynamically linked binaries will be much smaller and suitable for phones. - Graham
My app compiled as 1.3M statically, and 71KB if it was done against the dynamic go libs. 71KB (with debug symbols), smashes the C++ equivalent. - Matt Joiner
Good analogy... - Matt Joiner
[+12] [2009-11-12 04:15:11] Frank

No one has mentioned yet: Go has already a huge amount of libraries [1]! Including XML parser, unicode support, zip compression, json, regexp, bignum, etc. And for everything else you can link your external C code. It looks like it would be easy to start big Go projects right away.


(1) Indeed! And I can rebuild all of them from scratch in under 10 seconds (actually clocked at 6 sec on my laptop using make -j3) - Mark Renouf
Pity they have abysmal performance. - Matt Joiner
[+12] [2009-11-11 19:51:18] Grumdrig
  • The lack of type hierarchy ("static duck typing") is rather brilliant, I think. Why didn't anybody think of that sooner? EDIT: Why didn't I know about this sooner? (Thanks, @Nemanja)

  • The channel concept looks really cool and will make lots of hard things easy.

  • Garbage collection, given their claim of 10%-20% penalty, is a hugely worth it. So much uninteresting C/C++ code is juggling references, and paradigms with GC can be so much cleaner.

  • Some of the syntax will take some getting used to. Confused by &'s and *'s right now.

  • Reversing the order of names and types in declarations (vs C) is the right thing to do and took some guts.

EDIT: One more point. Having now played with it for a bit, I'm disappointed you can't define methods on classes outside the local package. E.g. this doesn't work:

func (v int) square() int {
  return v * v;
two := 2;
four := two.square();

(Probably, some people are glad of that, and would be even if my example were more sensible.)

To add methods, you have to "alias" the type and name it explicitly:

type Number int
func (v Number) square() Number {
  return v * v;
var two Number = 2;
four := two.square();

(4) The proper name for "Static duck typing" is structural subtyping and it is not exactly a new thing: - Nemanja Trifunovic
Why is reversing the order of names and types the right thing to do? I thought they just did it to be different, But maybe you see a real reason? - Frank
As they state in "They're only backwards if you're used to C. In C, the notion is that a variable is declared like an expression denoting its type, which is a nice idea, but the type and expression grammars don't mix very well and the results can be confusing; consider function pointers." There's a couple explcit reasons given there also. It does require a "var" keyword though. - Grumdrig
The tutorials cover go quickly but also in interesting detail in examples. See Tut 2 for methods -
[+11] [2009-11-11 10:57:41] community_owned

I'm really in 2 minds about it. I think I've looked at a large number of languages over the years, loved some, loathed others, always looking for the "perfect" one (where is it??).

I really, really love that people want to try their ideas out. I don't care if it goes nowhere from that POV, but a lot of great products have come from scratching an itch. I'm not really sure that a new language will actually solve things as expected -- it will probably take a lot of time and effort to shake-out those niggly bugs and issues, especially as it's meant to be a close-to-the-hardware language (isn't it?).

These days, I've come to the conclusion that no single language will adequately solve any problem, and people should use several languages together for several types of systems -- e.g. C for low-level/very-fast "driver" code, wrapped by a TCL/Perl/Ruby/Python glue language. Maybe with an Erlang/Scala back-end MQ service, and a Haskell parser/DSL for the less technical to write their plugins/snippets/blah.

I don't know, that example's very made-up, and I know there are a lot of folks who hate the idea of learning a new language, but it does annoy me that so me teams, companies and corporations are still so badly afflicted with tunnel-vision over languages.

[+9] [2009-11-11 11:31:15] Ólafur Waage

Hello World compiles to a bit over 500KB on a linux machine. How will a system designed by this look like where simple tools are half a MB in size.

(2) is it possible to link to "libgo" or similar to reduce that? -
You found that out two hours before I did. Perhaps the compiler is not working too well yet? Also it is statically linked I think, so perhaps this will be reduced drastically in future. - community_owned
(7) It's the runtime being added to the executable. So libraries won't have this problem. - Ólafur Waage
(1) It's because of considerations like that (OMG 500KB is sooooo huge) that you get that many libc errors in Linux where you have to install 10 different versions. - Vincent
(10) Ah yes, the old complaint about Lisp. It turned out not to be important in larger applications, since the relatively large runtime size allowed a lot of additional programming with relatively small increase in the memory footprint. In other words, this is primarily relevant for toy programs, not programs that you'd expect to be a megabyte or larger. - David Thornley
Tsk, tsk, @David Thornley, it's very important if you're going to be writing a lot of "hello world" apps. - Nosredna
(5) @David: but for system-level programs, this is not trivial. - Paul Nathan
@David. Theere are many very serious programs that need to be small in size. Think controllers and embedded development in general. - Nemanja Trifunovic
(5) @Nemanja Trifunovic: You're not planning to use a garbage collected, multithreaded language on an embedded microcontroller, are you? - Thomas
(2) The go runtime is a static library. They just need make a shared lib out of it. standard system tools become very big if you link statically to libc as well. - nos
@Thomas: Why not? Smalltalk and Lisp have been used for exactly that purpose for decades. - Jörg W Mittag
Nah, this is just the default static linking in use. My app compiles statically as 1.3M, and 71KB against libgo. - Matt Joiner
[+7] [2009-11-11 05:12:06] user208418

Super-fast erlang for the masses? :) Seriously ... I like the emphasis on concurrency-oriented programming. Also it's important to remember that systems languages are not the same as application programming languages - a much smaller user-base with far more specific needs.

What will be interesting is when the operating system built on Go comes out ... C is to UNIX as Go is to ... ? We'll see. Who was it that said: History don't repeat, but it sure does rhyme?

(1) I don't think it's got out-of-process protocols like Erlang has. But it's probably only a matter of time till it has. Since this is Rob Pike, maybe he'll borrow Styx from Plan9? - csl
That would be Mark Twain: - Cristián Romo
Go doesn't have exceptions. A huge part of Erlang is its handling of failures, errors and exceptions. They don't really compare on other points than message passing. - I GIVE TERRIBLE ADVICE
[+7] [2009-11-11 00:31:34]

When I read about it I see a lot of inspiration from Python (a language I like) although I can't see it mentioned explicitly as an inspiration.

  • No inheritance or explicit interfaces; interfaces are duck typed (but checked at compilation) makes for something very interesting!
  • mapping type is part of the language, map, reminds me of Python's very powerful dict.
  • Array slice syntax a[1:3], and you query a collection's length with len(m) [1]
  • Acknowledgement of coroutines

(5) It's difficult to see what is so Python-specific about those points. - community_owned
(6) @Kinopiko: I don't use the word specific anywhere. -
If you claim these features are taken from Python then perhaps it seems as if are claiming that these features are specific to Python. - community_owned
They aren't duck typed, but just checked for. Duck typing is for dynamic languages. - Dykam
@Dykam what is your definition? I think this fits pretty well with duck typing: The interface is just declaring the methods.. no need to specify which interface a type implements or so, in go. I don't see why its exclusively for dynamic languages, but if you can force that into the definition, you are right -- it's not duck typed. These are not exact parallels, it is just similarities. -
The wiki page about Duck typing says me it is a dynamic language feature. - Dykam
+4294967295 for coroutines - Longpoke
Go looks to me to be pretty heavy in syntax. That's anything but Python-inspired. - jae
jae: Python is more than just the syntax. I didn't say it took all, or even much from python. -
[+7] [2009-11-14 19:08:45] Jesse

Go should be a C replacement and as such be suitable for embedded systems development. A language that is at its core:

  • simple
  • fast
  • produces small executables (when desired)
  • sane syntax (I would consider Go's an improvement)
  • modern

Why can't Go combine the flexibility, safety, and richness of Standard ML or Haskell with the low-level expressiveness of C? For some reason it stops short.

Provide a compiler flag that strips out features for software that can't use fancy runtime stuff, like kernels for example. Go is a system language that doesn't have, even basic, ASM support? Poo. Languages like D are trying, but at the end of the day D feels like C++ redux; same ideas, same "tack-it-on" design process.

The BitC language [1] looked promising, but I fear it may die a slow death since its main driving force and creator has left for Microsoft to pursue related endeavors.

C is an old work horse, for sure. But I think it's time to put it out to pasture (or taken to the glue factory depending on who you talk to) and replaced with something modern.


(2) FYI, BitC's main driving force got behind the wheel again early 2010: - mattbh
[+7] [2010-04-30 23:31:39] Hotei

I've been programming for more than a few years and I'll make a prediction based on that experience. 'Go' will be the next "C". It's not the "be all end all" language, but in the next 5 years it will take over a HUGE chunk of the programming community's attention.

Go's not perfect, but even at this stage of (im)maturity it's extremely impressive. The compilers work. They're fast. It's simple to write code to solve interesting (non-trivial) problems. The resulting code is adequately fast on one CPU. The same code can benefit from multi-CPU cores if they're available. The problem and resulting design of course need to be 'parallel' amenable, but the actual speed gains are (in my own experience) stupendous on appropriate problems. The library code is evolving (adding functions) but the basic stuff is already quite good in the areas you'd expect to need.

NOTE: AMD64 6 core CPU at 3.2 ghz for $300. as of 2010. In 2012 that might be 128 core CPU for the same price. ( for example -> ) Will your current C/C++ code adapt automatically to take advantage of those new CPUs? My go code can - without any rewrite.

I've only used go for about 3 weeks but I'm ready to go out on a limb and say : Go is the Next Big Thing(tm) :-)


(1) Yes, this is the beginning of something big. - Jeff Allen
You won't have 128 core until 2017. - Matt Joiner
[+6] [2009-11-11 22:09:53] luiscubal

Concurrency is a big plus. Syntax support for easy threading might be the next big thing.

Meanwhile, "no windows" is problematic.

The syntax will be a real barrier preventing adoption. Then again, Ruby and PHP have some weird syntax issues(PHP's $var thing, for example) and seem to be going just fine.

As soon as more libraries start showing up(GUI for the desktop, databases for the server), Go might actually have a chance.

[+6] [2009-11-11 11:47:45]

I'm not unhappy about go's supported platforms:

  • Linux
  • Mac OS X

(on x86, amd64 and ARM)


(1) Because it's an experimental language it doesn't support a lot of platforms yet. - community_owned
(5) the point is which platforms it supported first and which it didn't. a natural choice, of course (for people with *nix backgrounds like the developers). -
(13) Skipping Windows seriously limits the deployment base of Go programs. - Spike Williams
(26) I rather like that it ignores crap platforms like Windows, and sticks to the good ones. - hendrixski
(2) @hendrixski - you mean the ones used by < 10% of people... - Jason
(5) I rather like that it ignores platforms like Windows so I won't waste my time testing it. - Stringer Bell
(10) The fact that Windows isn't supported is a feature. That means the language is cleaner and doesn't require tons of compatibility hacks that will barely ever get used. The number of Windows developers who need something like Go is vanishingly small. - Bob Aman
@Jason, those < 10% probably include > 90% of "system" programmers. - hasen j
(2) I'm amazed how many people honestly think that lack of Windows support helps language uptake. Get a reality check, people! - Dmitri Nesteruk
(1) Smug UNIX users, sigh. - Skurmedel
Nah that BS, they should ship a win version with support for VS. Otherwise many people just will not have a look at it. Sure google internally doesn't need a win version, but it limits how popular the language can become.. - Nils
popularity = quality⁻¹. The more people don't support Windows, the more it will die, this is a good thing. I'm disappointed that they chose to support legacy OS like Linux and joke OS like mac though. - Longpoke
Windows compiler (erGo) coming up: - Alexander
[+6] [2009-11-11 14:07:06] Stefan Ernst

Google employees clearly have too much time on their hands.

.. I need to apply asap.

I like how there is already a fairly big standard lib, I havent tried it yet though.

(4) Application process = invent the worlds most popular language, then improve the most popular os, then get another 35years of experience - then apply - Martin Beckett
(1) You know, not everyone at Google is a rock star legend programmer who invented a language or wrote an operating system. But they are picky. - Mark Renouf
[+6] [2009-11-11 14:11:33] Derek

A language that supposedly combines the ease of development of a scripting language with the performance (almost) of C sounds like a dream come true to me. :)

Add to that the fact that it's worked on by two guys who made some very useful, long-lived products, and I suspect they may know what they're talking about.

So here's my question: do they use this language when they have the choice? The designers, as well as other Google engineers. If so, they will make it useful and usable, and it must do some good things already for them to choose it.

(2) They used it to make the golang web server. - Nosredna
[+5] [2009-11-11 00:51:50] corydoras

Yet another programming language. It doesn't at first look seem to provide any major breakthroughs in terms of either productivity or performance.

I am just not sure in what situations using it would be appropriate except for perhaps small personal projects.

From looking at the basic tutorials it seems to simply be a new replacement for c in the same way c++ and objective-c replace/extend c.

[+5] [2009-11-11 02:35:31] György Andrasek

Sounds like Google's version of Ada, but I won't jump to conclusions just yet. Let's hope the standard won't be 900 pages long.

i love ada := operator :) and concurrency facilities. A pity they didn't put a bit more of ruby syntax on the recipe. - fnieto - Fernando Nieto
(4) How would this be the Google version of Ada when ADA is the strongest typed language I've ever known??!! - Jorge Córdoba
(1) @Jorge while I completely agree with you, consider that Ada has built-in concurrency mechanisms (called tasks), array slicing, pointers without pointer math, the concept of packages (although I seem to remember Ada requiring something similar to a .h), and no implicit type conversion. These are all characteristics of Go. - San Jacinto
The standard is here: and is the best source after the tutorial. This is NOT the case for most other standardized languages. - Matt Joiner
@Matt Joiner: The language was literally one day old when I wrote this. Basically all the information we had was an hour long Google Talk video and some sample code. - György Andrasek
[+5] [2009-11-14 01:20:55] Maurice Gilden

I have played around with Go for two days now. Its syntax is a bit weird and needs some time to get used to. I always want to put parentheses around my if and for statements and leaving out the semicolon feels just wrong. But after a short adaptation phase I already get some lines of code down that just work the way I've imagined it.

My main criticism so far is about the tools provided. The compiler (6g) has no options like gcc or most other compilers I know do. There's no debug or release mode, no speed/size optimization and even the strip symbols option in the linker (6l) seems to break the executable and is thus unusable. Ok, I can live with that. It's not like I aim for best performance or smallest executable. Having a fast compiler is more important.

I love D partly because it has unittesting and ddoc as integral part of the language. So I was excited at first when I heard that Go has these things as well. But so far I can't get either of them to work, and that's mainly because they are NOT part of the language.

godoc is a program, that creates a (HTML) documentation from all the packages that come with Go. But it's nearly impossible to get it to work if you have your own program, that doesn't reside inside the GOROOT subdirectories.

gotest is actually only a batch script that uses the Makefile(s) to compile the tests and run all methods that match a certain pattern. Yeah...Makefiles. I hate those. I don't use them. And it's not possible to use gotest without them. So my first little project is a build tool that makes Makefiles obsolete. From there to gotest2 shouldn't be hard.... ;)

Some more thoughts:

  • I don't know why the language has 'goto' if they don't include other things with the explanation that it would just lead to more bugs...
  • No dynamic arrays (and no simple array concatenation). They have containers in the library, but that doesn't feel the same.
  • goroutines, they work great...adding 100k elements to a vector results in a few thousand casualties (overwritten elements) but no crash. I can already see the bugs this will create, but I still think it's a great feature.
  • Channels. Seem to make writing any type of server a lot easier.
  • Source code doesn't look as clean as Java or D.
  • I'm missing some things in the documentation. The general usage of a certain package for example. The _test.go files for that package are often more helpful.
  • writing := where you should have written = can easily lead to bugs that are hard to spot (depending on font, font-size and tiredness).
  • I don't miss assertions or exceptions, yet. try-catch blocks look better than a second return value and an if block, but it's doing the same. And I can probably write an assertion function in 5 minutes that crashes my program if false.
  • I don't use generics/templates in any language if I can avoid it. I just don't like them. And I most certainly will not miss them. But others may. They seem to have a huge fan-base out there.

+1 for being the first comment that i've seen that is from real experience. - Josiah
Great that you actually tried it. I don't agree with your comparisons to Java, and several of your complaints have actually since been addressed. - Matt Joiner
Yeah, I should probably rewrite it a bit. This post is over a year old and I've done a lot more with Go in that time... ;) - Maurice Gilden
[+5] [2009-11-14 16:44:28] Nosredna

Jeff Bone's awesome Go rant. A great read.

It's merely the latest of a series of languages from these same people (former god-like heroes to me) --- most recently Limbo, each successive one of which implements the same ideas in barely, idiosyncratically, every-so-slightly different ways.

And so for 20 years now these folks --- the shining lights, in many ways, of "practical" programming language, operating systems, and general systems research --- have continued to fail to "get" the fundamental practical needs of everyday programmers working in The Real World. "Go" is just another language written first for the compiler and only secondarily for the programmer --- and stuck in a 70s mindset* about the relationship of that programmer to the (digital) world within which they live and work!

(5) He didn't seem to have a single coherent thing to say about Go. Just noise. - community_owned
@Kinopiko - it's a rant, but there are some valid points being made once you separate them from the rant artifacts. - Kev
[+3] [2009-11-13 06:13:05] Christian

Being Google I would have expected that that choose a name that's easily googleable. Really, is it that hard to find a unique name that actually lets people Google for resources about the language?

(1) Is C a name that’s easily googleable? I’m tired of stupid but easily googleable names (Is Samsung’s new mobile platform really called 'bada'? Luckily the’ll drop it soon enough). - Nikolai Ruhe
C was developed before Google was around. Those guys had an excuse at picking a bad name. - Christian
Google "go language" - trinithis
[+3] [2009-11-17 16:13:49] Indranil Banerjee

No Generics. So you see things like this in

func SortFloats(a []float)

SortFloats sorts an array of floats in increasing order.

func SortInts(a []int)

SortInts sorts an array of ints in increasing order.

func SortStrings(a []string)

SortStrings sorts an array of strings in increasing order

There is a generic Sort routine... your data structure must model the Interface interface present within the sort.go source file. - fbrereto
Look at how it's implemented: func SortInts(a []int) { Sort(IntArray(a)) } This is not a hack, it's a convenience function. - György Andrasek
[+3] [2009-11-12 15:43:04] Tim Post

I, for one, welcome our Go overlords.

I've seen a lot of people taking issue with the := operand, but it should not be too strange to anyone who has written more than a basic makefile. I've been looking for something that more or less merges C and Python in an agreeable way. I found a language named Blue [1], which looks like its getting to that point but is developing rather slowly. Blue is also interpreted, which was a minus for me.

I think I can get up and running with Go in a month or less. I'm still seeing stars (literally, *) when studying the syntax, and my C brain instantly wants to think pointer arithmetic. So, yeah, its going to take getting used to.

My biggest complaints will probably come when I switch from C to Go to PHP within the same 48 hours while working on multiple projects. But, well, that's why we have aspirin, I suppose.


[+3] [2009-11-11 04:09:07] ZJR

It gives me an uneasy feel it got the green light out of frustration with the python core performance.

Much in the same way chrome was announced as an alternative to the tragic memory leaks firefox2 was suffering at the time.

If that's the case, too bad it doesn't retain Python syntax.

(4) Go is not really an alternative to Python, it's more an alternative to C++/Java/C#. - Alec Thomas
(1) Revisionist history? Firefox 3.0: June 17th 2008. Chrome 1.0: September 2nd 2008. - Breton
You're right. They where coexisting. But I remember I was still using Firefox 2 at the time of the announce. And was disappointed of firefox behaviour, and had switched back and forth browsers for months. Could be, but here I cannot really recall exactly... that Firefox 3 was really unstable until Firefox 3.1? I remember 3.1 was a very welcome update, (and kinda heavy, for a .1) not really sure why. Can someone confirm/deny? - ZJR
(1) That was my experience too. Firefox 3.0 was fast, later updates slowed it down significantly but the overall quality of 3 was far greater than 2. - Matt Joiner
[+3] [2009-11-11 01:56:38] keithwarren7

This language, as Rob says in the google tech talk is meant as a systems language. Realistically the number of true systems programmers in the dev ecosystem is probably less than 5% of the whole. Dont get me wrong, I LOVE the fast compile time etc but what is needed is a language that is simple, that reduces the complexity of the development process. I dont know that there is a silver bullet. I think Ted Neward hit the nail on the head in a discussion about Agile - "We are in desperate need of simplicity in this industry. Whoever gets that, and gets it right, defines the "Next Big Thing"." I think that in that context GO is yet another language and not the next big thing we are looking for.

(1) The other 95% being web development? Hook Go up to a database, throw together a nice support framework and pow you have your PHP killer. - Thomas
[+3] [2009-11-11 12:05:46] Scott Wales

I would be interested to see how go's concurrency model will scale to clustered computing. The 'goroutine' system seems interesting.

[+3] [2009-11-11 05:32:13] Frank

It compiles really fast! See this short youtube video [1].


Am I the only one that really couldn't care less about compile time? I mean, I don't want to sit there for a week (happened to me a few years ago when compiling KDE on a Pentium 4 1.8 GHz with 768 MB of RAM), but I don't know of any language that I would avoid simply because the compile time was too high. When choosing a language, I'm more worried about things like target platform, code readability, available libraries, etc. I've never even considered compile time. - senfo
[+3] [2009-11-11 14:40:16] Trillian

There some interesting stuff such as the goroutine stuff and the "static duck typing" (which I'm actually quite curious about, I have to check that video). But, please, no generics, exceptions, method overloading or operator overloading? The common standard library packages which look like bare wrappers above the c stdlib? Bah! I'm not impressed.

I was glad most of that stuff was gone. Interfaces look better. Of course, I'll have to write something big to be sure, but I like the idea. - Nosredna
[+3] [2009-11-11 15:57:14] StackedCrooked

I like the minimalistic approach. It seems like they have identified a number of core crucial issues and then created a language that deals with just those while holding back syntactic sugar.

[+3] [2009-11-11 16:21:58] deft_code

I think Go will be a great language if it can survive its obscurity phase. However, I don't see it as a replacement for c++. It does several things right, concurrency is big win, and procedural syntax.

However, one of the stated goals is replace c++, and be a system programming language. I don't think it meets those goals well.

Garbage collection is generally a sign of an application language. In don't see how a language can claim it's a system language and yet require a garbage collector.

Duck typing is giving python headaches. C++ templates are having a simlar issue they are trying to solve with concepts. There needs to be a way to explicitly say what interface a type needs to fulfill. I'm not advocating Java/C# style interfaces, but they need to solve that sooner than later.

Also as a c++ programmer, I can't move to a new language that doesn't offer templates. Java/C# generics are ok but I prefer D2/C++ style full power templates.

(10) "Garbage collection is generally a sign of an application language. In don't see how a language can claim it's a system language and yet require a garbage collector." Traditionally. And I once thought that commercial consumer apps would always be written in assembly language. - Nosredna
(2) Telling someone who sells an operating system written in a garbage collected systems language that one cannot write an operating system in a garbage collected systems language, is kind of strange, don't you think? - Jörg W Mittag
@Jorg, what OS is that? - Matt Joiner
@Matt Joiner: the Inferno operating system was designed and implemented by a group including Rob Pike, in the Limbo programming language which is a garbage collected systems programming language designed by Rob Pike, who is of course also one of the designers of Go. - Jörg W Mittag
@Jorg: I hoped perhaps you meant a mainstream OS, but thanks for the information. - Matt Joiner
[+2] [2009-11-11 15:04:10] Sarah Vessels

Reading "Go's type system has no hierarchy, so no time is spent defining the relationships between types" ( FAQ [1]) sounds scary to me. Whether I go to statically typed C# or dynamically typed Ruby, I can have my classes and my inheritance and my interfaces/mixins. That's how I think, and I don't know how I'd do creating a large-scale application with no inheritance.

The lack of generic types and exceptions is also odd to me, and feels like a step backward ( language design FAQ [2]).


The lack of generic types is a problem indeed. But you can still inherit (even multiply) amongst interfaces. - Thomas
(1) The lack of generics is explicitly mentioned in the Google TechTalk. The problem is simply that it is not at all obvious how generics should work in Go. And since generics are going to make Go's currently very straightforward type system massively more complicated, they want to make sure that that complication is worth it. IOW: they have to get generics "right". (cough Java cough) - Jörg W Mittag
The main thing it's lacking is "implementation inheritance", which is something (some people would say) should be used with discretion in languages that do support it: prefer composition to inheritance. But you can actually get pretty close to implementation inheritance by using an anonymous field inside a struct. - poolie
[+2] [2009-11-11 17:37:58] Paul Nathan
  • The only definitive improvement I see is the interface and type systems being untangled.
  • The concurrency model looks like it will cause profound performance issues related to data access.
  • Pretty much everything but the interface system is doable in C++ with the appropriate libraries/functions.
  • Type system is probably less expressive than C++, especially the lack of overloading.
  • They are correct in OO systems discussions having a focus on object modelling instead of solution finding.
  • Wait, another replacement for C++ with garbage collection?

The typing approach has a certain value, I suspect, and would be interesting to explore at least.

I would conclude - here and now, in my opinion - I don't see a serious future for this language outside of a webserver market having to support many many lightweight threads. I may be quite wrong, of course.

Thoughts based off of: , , .

[+2] [2009-11-11 17:45:21] blesh

What can it really do for me (that I care about) that some other language I already know can't already do?

Until Google (or someone) comes up with a language that I can do something really cool in one line like...


... I don't think I'll consider it to be anything else but yet another language.

I mean, even if it could do that, without Generics I can't imagine how it's going to be more efficient to code anything. I'll have to have a separate GetBeer method to get me a Great Lakes IPA or a PBR. Or I'll have to return generic beer and cast it as something else. And who wants to drink generic beer?

(3) I've already designed it: public class Computer{ public void MakeMeASandwich() { // Todo: implement this } } - Neil N
(1) just needs a little tweaking and it will be done, thats all - Neil N
perl -e "sub MakeMeASandwich { ... }" - Paul Nathan
(1) public class Computer{ public void MakeMeASandwich() { throw new Exception("Please sudo."); } } - luiscubal
(1) @Paul Nathan: But what if I don't want a sub? Can I do: perl -e "hoagie MakeMeASandwich { ... }"? - Dennis Williamson
You know there's someone at Google now working on using data gathered from Google Earth, my searches, and my Gmail account to predict what sort of sandwich I want, and they're all: "Damn! They're on to us!" "Sir! Pastrami server #561 is down!" "Well hotswap that biznatch and get me a ..." "Your coffee sir." "Thank you, computer". - blesh
[+2] [2009-11-12 17:31:14] paulo

Lack of exceptions because of multiple return values is a mistake for me.

Interface system is good.

Pointers are bad, but necessary for a system language.

Finally array checked arrays in o.s. language. FFS people.

Agnostic about how the garbage collection can scale with parallelism. Java can get 5% in code that is well written but java has decades of JIT experience.

No JIT -> probably good, but precludes some optimizations probably including the very useful escape-analysis.

Lack of parametric types is huge mistake, capable of sinking evolution of the language to the application domain.

Syntax has a good idea (names first), but lousy execution sometimes.

Inheritance... I like polymorphism, i hate inheritance. So the decision to separate the interfaces from it is HEVAN.

Overloading is a huge source of bugs both in programs and in compilers. Good riddance.

Map embedded type. Sucks if no alternative is possible to declare. And without generic types it will not. Parametric Types, for me but not for you bahhh!

[+2] [2009-11-11 21:42:22] adam straughan

I like the 'sort of duck typing', reminds me of an answer I gave for what I'd like in C# 4.0 (

hey ho. Oh and I was interested until, "no windows". I've seen references indicating it is possible, but I've got other things that need my time.

[+2] [2009-11-26 23:11:50] Norman Ramsey

The language is kind of what I would expect as Rob Pike's next language. Rob's done a great body of work, and this is a good logical next step. But what has me green with envy is the lightning-fast compiler. I wish I could compile C, Haskell, and ML one-tenth that fast! Luckily I write a lot of code in Lua [1] which also compiles blindingly fast (albeit to bytecode).


[+1] [2009-12-19 15:51:06] viky

yet another programming language, this time by google!! Actually there is already a language with the same name, so it is slightly confusing having more than one language with the same name.

Whoaaoaoaoaa!!!! - trinithis
[+1] [2010-03-01 20:55:37] Software Monkey

I think it looks like it has huge potential - there are several very interesting concepts in there, not the least of which is GC and language support for concurrency: "don't communicate by sharing data, share data by communicating".

But frankly (and I am no MS fanboy) it's irrelevant until it is available for Windows, and probably even Mac. For me it's irrelevant until it also runs on the various hand-held and phone devices out there.

(1) It is available for Mac - Dave Berk
It was available for Mac from day zero, and a windows port has been part of the main Go distribution for some time now. - uriel
[+1] [2010-03-31 22:03:14] Ronny Brendel

Everything postet before is very correct and comprehensive, but I haven't seen this:

  • no Conditional Compilation. The Argument is you don't need it. Your built system should do it, or in other words: use file granular conditional compilation. I am not convinced on this. ( I discovered much copy and paste code where only single casts were changed :/)

  • no assertions. The argument is that assertions are often misused for real error handling. This is certainly correct, but personally I like assertions (And evangelize their proper use).

  • no constant parameters, functions. The argument - as with assertions - is that const is often times misused or too difficult. Certainly right, but still I think it's a great thing.

I don't see that omitting these things as a solution, but postponing difficult decisions. I hope it doesn't get in the way of the language. I really really like Go.

The cool things:

  • gofmt as a prevention for style discussions. I spent much time defining my / a good style on c, so I like the idea of having a consistent style across all code. (even by force)
  • There are so many other little things that make me like this language. (It's just too many)

I have to admit that the con points mentioned above held me back to code even a single line. All I did for now is reading up and studying the mailing list discussions. Nevertheless, when a project which needs a system language comes I will give it a try.

(1) No consts? Or do you mean as function parameter? - Dave Berk
functions and parameters - thanks for the hint - Ronny Brendel
[+1] [2009-11-12 23:45:38] Keith Nicholas

What would be good is a new native code compiled language that is not C / C++ / D / Pascalish.

Especially for embedded systems.

This answer doesn't connect to google's Go, even though it would not be difficult to make it do so. -
[+1] [2009-11-12 15:13:21] Jan Aagaard

Seeing := as a shortcut to declare and assign a value to variables took me back to some of the first programming experiences I had, since they were in Pascal. :o)

[+1] [2009-11-11 18:09:07] ima

Yet another language with a built-in algorithm. Great for short examples and nothing but pain for tasks that don't exactly fit into provided system of threading with channels.

I challenge you to provide a concurrency example that channels solve poorly. - Matt Joiner
[+1] [2009-11-11 18:34:56] Binod Singh

I would be interested to see when it will have IDE support and will be available for windows also.

It already has emacs support. I'm sure eclipse and others are being written by other hobbyists as we speak. - Frank
IDEs are for huge clunking languages like Java and C++. You don't NEED an IDE for a slim language. - Matt Joiner
[+1] [2009-11-11 18:44:26] Earlz

Well I think it's a neat looking language and the concurrency bits are extremely nifty. Also the removal of millions of paren's are great too(I'm programming in C#! Not Lisp! why must I have 3 different casts with 8 different sets of parens!?)

That being said. It's just another language. There are not any points yet that make it viable to compete with C/C++. The language is decently better. Decently better will not cover the expenses of retraining and all that though.

I do like that this is a lower level language(runs on the actual machine) yet has garbage collection.

I think it would be neat to test just how good it is at handling low level things by writing a kernel in it. (course parts will be bootstrapped with C, but still)

Writing a kernel where you are using a programming languages GC and threading objects? This doesn't sound reasonable. - Lothar
It's been done.. It just takes a bit more bootstrap code to get going. - Earlz
[+1] [2009-11-11 10:37:21] Himadri

The initialization :


It would be better if "=" is used instead of ":=" to represent an initializing declaration.

I liked the Minimization of use of parenthesis in "for" and "if" statement

 for i := 0; i < 10; i++ {

  if s==0 {   }

(3) I like having a separate operator, since it avoids the problem of accidentally creating a new variable because of a typo. It might take some getting used to though. - Matthew Crumley
[+1] [2009-11-11 06:21:12] trace

its quite similar to C++, which made me wanna check it out, I think the language is carefully planned, but I still think its too early to be used. Might wanna wait until it gets to 1.5 before I decide whether to study it or not.

[0] [2009-11-11 17:06:25] dwj

I think this says it all:

say good-bye to stack overflow(s)

Go still has a call stack and overflows can happen just like in C. - Andrey Vlasovskikh
Meant as a self-referential (this site) joke. - dwj
[0] [2009-11-16 16:05:39] ragsagar

function for finding factorial

func Factorial(n int) (fact int) {
  if n == 0 {  fact = 1;  }
  else {  fact = n * Factorial(n - 1);   }

[0] [2009-11-27 10:05:55] Zen

I don't understand why compiling time can be so important for Google. Someone can explain, please?

The iota keyword seems to me really weird. It's a sort of automatic-pseudo-variabile to be used in const, in order to emulate enums.

I think that enums are simpler and cleaner than the iota sintax.

I would prefer, btw, a more expressive metalanguage rather than this strange thing. Or better, a reflection structure, that let use the language itself as its own metalanguage. I understand that reflection is expensive, it requires, I think, more steps to compile, and bigger structures (meta structures are required as well). I don't think that a preprocessor could be considered as an innovative idea.

I agree with enums over iota. - trinithis
(1) iota is for generating the values of constants with steps other than 1. enum is stuck on 1, or manual assignment. hell, c/c++ don't even support non-int enum types yet, and c++0x is still years away. - Matt Joiner
[0] [2011-01-11 20:40:41] Kejia柯嘉

I mark go's syntax good. The better syntax languages I used are lisp, python, and xml. If programmers are looking for the middle point between machine-code and natural English, they are near that point; but, if we are looking for the golden point closer to natural English from machine-code, go is around that point.

Many years ago, java released programmers from memory-management; today, go will release us from cpu-management.

[-3] [2009-11-21 19:49:30] acidzombie24

Without going into a rant, i think i will never use it.

(5) Tell us why. Give us information, not bare opinions. - reinierpost
There are too many reason. Not all of them are specifically about the language (reasons why i dont think it will go mainstream). I could probably come up 2dozen or more reasons and to say any would look like flamebait without a long explanation. - acidzombie24
@acidzombie24: Just give a reason. I've used it, but until I did my excuse would be "C and Python are good enough, and better supported." - Matt Joiner
You simply hate the language. You don't really know why :\ (that's the bad thing about hate) - Zippoxer
@reinierpost, @Matt, @Zippo i'll highlight it. "2dozen or more reasons and to say any would look like flamebait without a long explanation" - acidzombie24
@acidzombie24: We're not interested in your opinions. We're interested in facts, in your reasons for them, to help us evaluate languages for ourselves. We're technical people here, not social crowders. - reinierpost
@reinierpost: Lets take singletons for example. Even with facts one can not convince another if its a bad thing or not. I seen numerous people try and done so myself. I do have reasons/facts but like i said, it requires too much of an explainable. judging by votes 3 ppl agree with me and 6 ppl dont (or dislike the answer). - acidzombie24
@acidzombie24 you can put separate reasons in separate answers - reinierpost