I've just been told about a new programming language, Go, 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):
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.
map, reminds me of Python's very powerful dict.a[1:3], and you query a collection's length with len(m) 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.
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.
http://blogs.tedneward.com/2009/10/12/quotAgile+Is+Treating+The+Symptoms+Not+The+Diseasequot.aspx
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.
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: http://www.youtube.com/watch?v=rKnDgT73v8s. Before that, I was skeptical.
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.
First thought: wow, D done right! Proper mix of Python and C.
After watching the TechTalk:
:= syntaxfor i = 0; i < 10; i++?? seriously?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.
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:
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.
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.
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?
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.
YACL
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.)
The initialization :
s:=0;
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 { }
}
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.
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.
I'm not unhappy about go's supported platforms:
(on x86, amd64 and ARM)
(Schadenfreude)
I would be interested to see how go's concurrency model will scale to clustered computing. The 'goroutine' system seems interesting.
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.
Could Go really be the end of this wonderful experience? I will miss S.O.! SO MUCH!
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.
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.
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.
Reading "Go's type system has no hierarchy, so no time is spent defining the relationships between types" (FAQ) 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).
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.
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.
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.
I have just seen the introductory video
This I what I liked ( from what I understood )
Braces are used ALWAYS!
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.
wrong
if x > 0
return 0;
or
if x > 0 return 0;
right
if x > 0 {
return 0;
}
or
if x > 0 { return 0; }
always!!
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.
So the interface declare the quack method
type Quack interface {
DoQuack()
}
And then we can may create a function using that type:
func callIt( duck Quack ) {
duck.DoQuack()
}
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() {
d.count++
for i:= 0; i < d.count ; i++ {
fmt.Print("quack!" )
}
fmt.Print("\n")
}
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 )
}
prints:
quack!
quack!quack!
quack!quack!quack!
Ehem, I'll try it... quack?
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:
http://golang.org/doc/install.html
I can see that: real programmers use cat!!!
$ cat >hello.go <<EOF
package main
import "fmt"
func main() {
fmt.Printf("hello, world\n")
}
EOF
$ 6g hello.go
$ 6l hello.6
$ ./6.out
hello, world
Nice
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: http://golang.org/doc/effective%5Fgo.html , http://golang.org/doc/go%5Ffor%5Fcpp%5Fprogrammers.html , http://golang.org/doc/go%5Flang%5Ffaq.html .
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...
Computer.MakeMeASandwich();
... 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?
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've only watched the talk, read the FAQ and skimmed some other stuff on the website; not actually tried it. But here's my take.
Pro:
var in C# 3.0).select construct).iota and the improved switch.Con:
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).liftM, liftM2, liftM3...) that this can be a pain.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.
I would be interested to see when it will have IDE support and will be available for windows also.
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)
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();
I like the 'sort of duck typing', reminds me of an answer I gave for what I'd like in C# 4.0 (http://stackoverflow.com/questions/138367/most-wanted-feature-for-c-4-0/253441#253441)
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.
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.
The gopher is probably the best programming language mascot ever.
No one has mentioned yet: Go has already a huge amount of libraries! 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.
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.
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)
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, 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.
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!
What would be good is a new native code compiled language that is not C / C++ / D / Pascalish.
Especially for embedded systems.
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?
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:
Jeff Bone's awesome Go rant. A great read.
http://www.xent.com/pipermail/fork/Week-of-Mon-20091109/054578.html
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!
Go should be a C replacement and as such be suitable for embedded systems development. A language that is at its core:
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 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.
function for finding factorial
func Factorial(n int) (fact int) {
if n == 0 { fact = 1; }
else { fact = n * Factorial(n - 1); }
return;
}
No Generics. So you see things like this in http://golang.org/pkg/sort/
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
I discovered this language today while searching Google for "safe compiled language", in the hopes of finding a crossbreed of C++ and Python. Three of the first ten results pointed to Go. I think this says something (unless the search is rigged :)
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 which also compiles blindingly fast (albeit to bytecode).
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.
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.
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.
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:
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.
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 -> http://news.bbc.co.uk/2/hi/technology/8392392.stm ) 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) :-)
Hotei