Congrats to the Go team! I've been looking forward to this release for a while. Go makes it easy to do some very complex things, and much of this can be attributed to the wonderfully built standard library.
I've been using Go for 2 years now. It's been a lot of fun. It certainly brought fun back into programming for me. Very happy to see the 1.0 release hitting the public. Congratulations to the Go team and contributors for a job very well done!
Good question. And one I can't easily answer to be honest. In most respects I suppose this is very much a subjective matter.
For me it's the language's simplicity. There are no hidden surprises in the spec. It's short, clean and easy to memorize. The syntax is clear and (for the most part) un-intrusive. Some of it's idioms really force you to think about what you have learned in other languages. And then either forget any of that ever happened, or at the very least become a critical thinker about the usefulness of these things. For example: the standard inheritance based OOP model.
Go simply allows me to 'get shit done' fast and without having to jump through hoops. It's very much like a breath of fresh air in what was quickly becoming a stale and obnoxious development environment (for me at least).
Edit: I would add that I do not particularly like evangelising about anything; that includes Go. It is beautiful for what it is. but by no means should it be considered a silver bullet. If your current tool chain(s) and language(s) work for you, by all means continue to use them. Go has its strengths and its weaknesses that should always be considered at the same time.
I don't like to spend time on irrelevant things like "why the binary does not link", "in which shared library this undefined symbol is located" or "how to parse XML", or even plain "why it does not work".
With Go I _usually_ have a predictable process of writing a program, when simple things are simple and complex things are reachable. It makes me happy.
Isn't that just because parsing XML in Go is difficult bordering on impossible? Or are you saying there's some other language that forces you to think about XML when you don't want to?
My point was that with Go, I have consistently predictable experience. Its standard library is still not the most powerful across the Zoo, but if it has support of something, I know that I can use it w/o a book "libxml2 for dummies".
It works - easy as pie. No problems building, linking or worrying about dependencies. (it should be noted that this is a common property of hobby projects)
It's fast, which is nice for the small boy (or girl) in all of us. It is gratifying to make software that can run like blazes.
I get the control over memory layout that I really want. By day I am a Java dev, by night I used to hack Erlang. Neither of these allows me to lay out an array of structs contiguously in memory. I did this for a quad-tree implementation and got 2X speed up on read operations. This means that all the stuff I am reading about CPU architecture, cache-lines and latency etc. can be experimented with in an easy to use environment. That's just pure fun and gratification.
Comprehension. In Java I recently wrote a SOAP server (I know, lame) and it took me an hour of XML fiddling before a more informed person told me that we do that with annotations now.
"Which annotations?
These magical ones.
Ah thanks"
That is a server in Java. At the end I was as ignorant as when I began. But I had the annotations and I had a server. This is bullshit. Programming without learning is like eating without tasting anything. In Go I am learning as I code - this is ecstasy. When I am confused I can jump straight into the library source code, ever tried that in a JEE server? It is painful.
Websockets are fun. Go supports websockets in the easiest way I can imagine.
Errors. Explicit errors in Go are just great. Verbose, yes. But, the clarity of this approach surprised me. All the networking code I have written in Java seemed mysterious. I would hack away and end up with a block of code that would fail from 'somewhere' inside. Errors have taught me a great deal about the different ways my networking code can fail. This is possibly my favourite part of Go (which makes me sound a bit boring).
Green threads are great. I'm sure plenty has been said about this. And message passing too. I won't say more about that.
Closures are marvellous. I have to say that I had a lot of reservations about closures in an imperative language. But if you are careful they are as safe as anything else (in that soup of mutable state). And so much fun.
It should be noted that a lot of my complaints about Java can be remedied. I can read a book about the latest JEE annotations (I did start reading one). I could study the Java networking code better and learn about things that way. But the crucial point is that Go allows me to do all of this while I do what I like best. Hacking. I can build systems and learn at the same time.
I too like Go. But I disagree with some of your analysis.
Java annotations aren't magical; at least no more magical than functions/methods. They're part of packages/libraries and should be documented. You can even write your own annotations.
I'm still not convinced that the lack of exceptions is a benefit of Go. The verbosity of error handling is problematic and seems indicative of a need for a better abstraction. And with respect to your issue of Java exceptions -- I don't know what you mean by "somewhere inside". Did you examine the stack trace?
Succinct, powerful, but readable syntax, but without the feelings of guilt associated with spending significant time in a high level language. At least it's that way for me. :)
I've written a few relatively small (a few K LOC) Go projects, and my experience has been quite positive.
The libraries are really well designed and impressively complete.
With goroutines and the fact that most things work with io.Reader/io.Writer, plugging different components together and having them work efficiently is pretty easy.
I love gofmt (sweet sweet consistency), and despite some early reservations, I'm quite happy with what the go tool provides.
The couple servers I have written in Go have been great, in that they were pretty easy to write in a straightforward way, and they ended up impressively fast. The speed is actually somewhat seductive; I've been unnecessarily microoptimizing some things, just because I see what sort of speed is possible without leaving the language.
I also find that due to gofmt, the constraints of the language, and the aesthetic leadership of the Go team (along with, likely, a self-selection in those writing Go right now), third party Go libraries are very readable.
When I'm trying to understand a data structure or a protocol, I often look for source code; python used to be my preference, but in part thanks to types, I now find Go to be my first choice.
I do wish the Thrift support was as good as the protocol buffer support, though. :)
I've been putting together a small blogging application with Go just for fun on the side to pick up the language and work on my web design.
Its a great language, I'm not using it for half of its capabilities but it very much feels well thought out and the community is very helpful.
Key pieces:
-My code isn't much more complex than my ruby or python.
-The stdlib is pretty fantastic.
-Right now tutorials and 'blogs' are all over the place with compatibility for go, rule of thumb if it says "goinstall" in the guide probably a good sign its an older guide.
-All network communications use epoll in the backend so you get lots of the fun things you would normally get from something like node.js without callback soup.
Ideally go would probably work for a web service or building some backend networked code, or even a simple command line utility. Right now there is not much in the way of GUI code outside of websites which is unfortunate cause I'd like to use the goroutines with some graphics ideas I've had.
Do you know of any recent tutorials on writing web applications in Golang? I saw a slideshow from two years ago, but the content seemed to be fairly abstract for a framework.
It really depends on your needs and the type of application you're making. For example my applications, apart serving a few static html, css and js files, just answer to JSON or JSONP queries. That can be done in a dozen lines of code, all the remaining code will be related to your application logic.
So you just need to look at the net/http API, and at a few code samples. I cannot find the the old golang wiki codelab sample (has it gone away with Go1 ?), so here's an example of a JSONP server that you can reduce to a few lines if you remove the specific application logic and the profiling hook :
https://github.com/Canop/braldop/blob/master/go/src/braldops...
go1 has been my goto language for a while now. I don't even understand why, but everything makes a lot of sense. It compiles about as fast as python and I have an easy time making quite efficient code.
Concurrency is obviously very good and that extends to parallelism quite easily. For example, I wrote go-heatmap ( https://github.com/dustin/go-heatmap ) and found I could shave a few seconds off of the colorization phase of a fairly large image I generate hourly by running every column (or row, I forget which) in parallel on my 4 core atom box.
The build/packaging system is everything maven wishes it could be. It's practical to create, publish and use small third-party things (such as my humanize package: https://github.com/dustin/go-humanize ) because the build system just deals with the dependency for you (even transitively) just based on import statements. "go list -json" in a source directory (or pointed to a namespace) will tell you all kinds of things about what your code uses, including transitive dependencies.
I deploy go code I use every day on OS X and Linux, 386, 64 and ARM. I can build all of these programs from any one of these systems so quickly and easily you wouldn't think they're native binaries. In fact, it just took me 20s to build a Windows cross compiler and all of the standard library (with which I built my kmz_example program from go-heatmap on OS X in .49s and now I've got a kmz_example.exe I don't know what to do with).
I made a few web application servers (mostly for games) and it's been a real pleasure, not to mention that my programs run for months handling millions of queries (mostly json) without the slightest problem.
Using the go tool to get libraries, build, compile, test, benchmark, is like a dream.
An example of what I found kind of marvelous : I had sometimes queries leading to the call to a function updating a lot of things in a kind of specific database. That is the browser had to wait about 1 second because there was in the query handling code something like this :
for _, ami := range amis {
bra.EnrichitCouchePNG(ms.répertoireCartesBraldun(ami.IdBraldun, ami.Mdpr), couche, PNG_CACHE_SIZE)
}
I just made a tiny change and the work was done after the answer was sent to the browser :
for _, ami := range amis {
go bra.EnrichitCouchePNG(ms.répertoireCartesBraldun(ami.IdBraldun, ami.Mdpr), couche, PNG_CACHE_SIZE)
}
This small go was the only needed thing (the "database" being yet protected by a mutex)
Never gave much thought to Go's UTF8 support, but this makes me think that it might've been better limited just to the string literals. The last thing I want is to patch other person's code by copy-pasting original variable and function names, because all I have is a standard US keyboard locale.
I've said it before and I'll say it again: Somebody really just needs to clone Apple's input method on Linux and Windows. Then you don't need to copy and paste — "é" is just one more keystroke than normal "e", option-e-e. This alone solves probably 95% of the international issues I encounter to the satisfaction of everyone involved.
On X11, the keymap can be set to "US International" which is the same as a stock US layout but with deadkeys and an AltGr key. I find it to be even easier than Apple's input method.
You're right, I should have mentioned that. I admit to only having learned about that recently, but it didn't sound quite right to me. You really like it better? As I understand it, the US International keymap makes any character that might be used as a deadkey always act as a deadkey, right? Because that sounds a little annoying for programming. In a Ruby program, even a French or Spanish one, probably most of the ` and ~ characters are going to be syntax, not diacritics. (But like I said, I haven't gotten to try it, so I might have gotten the wrong impression.)
I found it annoying enough that I now use US International without deadkeys. And definitely "Alt gr-o" is a lot easier than the "Option-e o" that I'm forced to use on the school's Macs.
Actually that's my configuration of choice, being Spanish, I use a UK keyboard + AltGr and it's perfect. I find the UK layout more comfortable for programming, and still can type Spanish when needed.
This is just the same for me in Norway. The Norwegian layout has open curly brace on AltGr + 7, which is very painful when programming. US with AltGr is so nice, but it just makes me more of a weirdo up here..
On Lion and later, it's even easier. Just hold down the e key and you get a list of the various accented versions.
Granted, it doesn't work in the Terminal, or certain other apps that don't use the standard text edit widgets (e.g. MacVim, TextMate), but in those apps you can continue to use the old ⌥e+e trick.
I don't know if I'll be able to go on with that. When I was coding in smalltalk and at the very beginning of java I was happy to use the full power of my speaking language in my programs but I had to give up my accents because most tools were unable to handle them.
Now that (on linux) most tools deal correctly with UTF-8, I try again, at least on programs that I'm sure I won't share with people not understanding French (for example French MMORPG). Time with tell but I don't take this risk at work.
We used it to write our own simple distributed computing software after realizing hadoop was too complicated (and thus bug prone) for our embarrassingly parallel needs.
It took us less time to get the system written, stable and up and running then it had to get hadoop setup (different developers so not a fair comparison but still).
It feels like python with the good parts of C on linux (most things are file like object) and I plan on using it more and more as the ecosystem of available libraries matures.
I've built a production entity resolution system using 100% Go. It implements a map/reduce model with many workers and multiple (for failover) masters. All data is held in memory for speed purposes. Things that are amazing about go: fun and fast to develop in; beautifully designed (rockstart founding team, than you!); RPC, net channels, and maps and strings, to name a few. The ability to quickly create servers to host business logic. Interfaces and "inheritance" model are both very elegant and clean. Compile times rock. Everything was built with the standard Go (pre 1) install; not a single other package was needed--the very complete standard lib is a blessing.
Two "could be better" points. Go has a hard memory limit per instance of ~ 15 GB; bad when you want to pin lots of data in memory. Russ says this issue is being tracked (2142) and will get fixed after Go 1 gets out the door. So patience will fix this one.
Second, there needs to be more examples of Go code out int the wild for others to share and look at. Using the template package got me stuck, for example, and seeing code cleared up my issue but that was hard to find. This we can all help with by using Go and talking about it. Again patience takes care of this issue as well.
Other than these items, do yourself a favor and start using the magic that is Go!
I have written a bit of Go. It strikes me as sort of the Unix of programming languages. It's very opinionated, takes some overarching concepts, mostly channels and interfaces, then proceeds to thoroughly not care what you think about it: refuses to have generics, lambdas and tail-call recursion like a pro. The polar opposite of design by committee. It even enforces a True Brace Style to keep the parser simple!
Technically, it looks good to me. The toolchain is excellent. It looks ready for production. Programming in it is fun. It fixes most issues of compiled languages. Go has mostly replaced Haskell, for me.
Why would you move from Haskell to Go? There's a night-and-day difference between them. I don't understand why you'd switch to a language because of the features it's lacking, unless you think those features are a bad thing (and I have yet to see a reason why generics and TCO are a bad thing).
Of course they are not a bad thing. It's just that Go has character. It doesn't have generics or C++-style classes just because every other language has them. I respect that.
As someone with no formal training or experience with compiled languages, I really like Go (as compared to trying to teach myself C recently). Months ago, when I first checked out the language, I was able to write a simple bot that sits in an IRC channel and responds to its name. It took me a little over an hour to write, using the online docs as a reference (https://gist.github.com/1123352).
I created SVGo, a Go package for generating SVG. (http://github.com/ajstarks/svgo) I use it for programming visualizations, and other creative coding tasks. For example, I use the goplay command and a browser, to "sketch with code", showing the code and resulting picture in one view -- I make a change, hit a keystroke and immediately see the result. (http://www.flickr.com/photos/ajstarks/6198774781/in/set-7215...)
I have been (slowly) developing a chess engine in go [1] (still a long way to go, no pun intended!)
What I like most about go is its simplicity and cleanness while still allowing you to program somewhat close to the metal. In fact, it often feels considerably more like a higher level language than a systems language.
The go tool is quite fantastic too. My chess engine project folder contains 41 go files, including a number of files containing tests (named XXX_test.go) which contain functions named TestXXX. My entire test + build process is:-
~/gocode/src/weak$ go test ./... && go build
Go is like a very delicious trifle - the further into it you go, the more delicious things you find. The quality is clear throughout.
Go is very unassuming. You start by wondering what the big deal is + getting annoyed with the minor differences from other C-syntax languages before slowly progressing towards quite liking it, then eventually once you grok how simple + elegant and well engineered it is you come to love it.
Tinkercad, http://tinkercad.com, a cloud based solid CAD runs Go for the cluster component. We have a dozen or so different services running in the cluster. Most are distributed for performance and fault tolerance. All the distributed code is written in Go, there is some C for performance critical inner loops.
I built a location service that allows people to play games with people who are nearby. I built a small geo-location service and a messaging server for the games. The servers are tiny and fairly simple. The games themselves are written in Javascript. Good times.
Well, they got (at least) one thing exactly right: Doing away with the "toolchain". Having one command that can figure out how to build your code, including downloading external dependencies, is really nice.
Pity about the whole "not having generics" thing though.
With interfaces, it's pretty simple to replicate patterns like a Container<Comparable> or Channel<Reader>, to borrow common Java syntax. Personally, I like how it forces you to think about parametricity whenever you want polymorphism, like most functional languages.
But, unless I'm missing something, it's missing the supporting bits you get in a nice functional language, like algebraic datatypes and pattern matching, which make that style much more pleasant.
Of course, most of the functional language DO have generics, and full type inference to boot, also.
Up until the point you want to return an object from your container, sure. Then you have to return a Comparable and the user has to downcast it into the right object.
Been playing with the weekly versions of Go for a couple weeks now. Highly enjoying it, my biggest pet peeve was that every library had a master and "weekly" branch which required me to manually pull down the weekly. Shouldn't be long and I can move to master!
Not sure, I am very much new to the new "go" command and how it works. Everytime I did a go get on a repo it would get the wrong version. I'd just cd into the 3rdparty dir and then pull/checkout the weekly branch and be ok.
I figured their had to be a better way but I was pretty focused on getting projects done.
And to be specific this was on non-standard libraries the standard libraries provided by go worked out of the box.
The go command will use the right version but only if the person writing the library has bothered to tag the version to use. Many people don't. Part of the point of Go 1 is to stabilize the language. We're committing to slowing down the rate of churn and to not changing the APIs in backwards incompatible ways for the lifetime of Go 1 (1.1, 1.2, and so on), so now there should be much less problem with just using tip/HEAD/whatever in the repositories without tags.
I'm still wishing that we could embed Go into a multithreaded c application, just like we can with the JVM and Mono. I would like to use Go as a "scripting" language. I have seen a thread in the mailing list that someone was working on it on a personal basis, but I can't find it anymore. It doesn't seem to be in high demand.
I have working, tested, high performance software in C. Throwing all that away and taking the risk of having Go underperform or be buggier than my previous solution is just not acceptable.
> I'm still wishing that we could embed Go into a multithreaded c application, just like we can with the JVM and Mono. I would like to use Go as a "scripting" language.
In my experience Go is probably 5-10x faster than C or C++. I estimate that programs that take me half an hour to write in Go would take me about 2½ hours in C and 5 hours in C++.
The language is interesting, at the very least -- concurrency primitives are nice, and the interface-based type system works for most cases (generic containers notwithstanding).
The major speed problem right now is GC, but that should be improving quickly.
The day Androïd will be written in go, we will see a significant performance boost and battery lifetime extension.
I don't program for Androïd just because I can't bare eclipse. An IDE as simple and efficient as QtCreator would generate a conversion tsunami.
The day when Google supports Android native app development in Golang, will be the day when Golang goes mainstream. But I don't bet on this thing happening.
Chrome will still be (mostly) C++ for a while. Even if they rewrote V8 and the UI; WebKit is still C++ and I doubt Google plans on ditching it without a very good reason.
I see a lot of very good reasons for Google not to lose time rewriting Chrome in Go, even without thinking about webkit, but do you have a reference to support this "200ms" assumption ? I never observed this in my programs (which doesn't have the kind of brutal allocations that a browser must have) so I'm curious.
ootachi does seem to like to pop into discussions about Go, throw around statements about Go's GC as if they were facts, despite never having used Go.
A 200ms GC pause is entirely possible for a busy, unoptimised server. The question you should be asking, though, is whether it's a problem. And if (and only if) it's a problem, whether the programmer has tried to reduce allocations. The easiest way to reduce GC time is to produce less garbage.
Now you've moved the goal posts. You can write free lists manually in Java as well. Doing so is incredibly awkward in Java or Go, compared to C++ where placement new makes it fairly straightforward (and moreover, you can use reference counting without too much trouble either). You can also use a real-time GC for Java, and you don't have that option in Go. This is perhaps uncharitable, but you're basically saying "our GC is bad, but you can work around it so it's okay".
Furthermore, you're implying that I'm saying something false ("as if they were facts"), but acknowledge that it is "possible". So I'm actually not seeing where I was wrong.
And I have used Go. I didn't like it. I realize I'm in the minority, but there are valid reasons for disliking Go.
You wrote "200ms GC pauses are completely unacceptable for a web browser." That's a bald unqualified statement. 200ms GC pauses are possible in some situations, but you say it as if it's inevitable and unfixable. It's not.
A garbage collected environment does not mean that generating garbage is harmless. Even in the presence of a (hypothetical) perfect GC, generating garbage would still be a major overhead. Go's GC is simpler than Java's GC, and has plenty of room for improvement, but you have much greater control over whether your code generates garbage in Go, which means that the suboptimality of Go's GC is much less significant.
I don't really care whether you like Go or not, or whether you use it. But you keep saying stuff about it that is either untrue or at least misleading. It's almost as if you have an axe to grind.
How do you have greater control over whether your code generates garbage in Go? The only difference between Java's memory model and Go's memory model is that, in Go, you can put structs inside other structs (and unsafe code I guess, and note that you can get some of the "structs inside other structs" benefit from inheritance in Java). That's it. The stack/heap distinction is no different between Go and Java.
The idea that "the suboptimality of Go's GC is much less significant" is just wrong -- Go has the exact same memory model as Java, only it's less well equipped to deal with it than Java is because its GC is so suboptimal. I'm just countering the oft-quoted statement that Go's memory model is somehow closer to the metal than that of Java -- it isn't.
To optimize allocations in Java, you use free lists and make fewer variables escape so they can be stack allocated. To optimize allocations in Go, you use free lists and make fewer variables escape so they can be stack allocated. Java has a wealth of allocation profiling tools available at its disposal. Go has some too. Go doesn't provide anything over Java here.
For me it's OK. I hadn't see this before and I feel that a discussion without those who don't like Go would be dangerously poor. Thanks for your contribution.
Hitting 1.0 should convince more people to use it in production. However, getting any new language in an organization is always a struggle. Is there a list of organizations that currently use it in production?
[Update]
A few high-tech companies were listed. I was hoping more for big pharma or finance? There are some super convervative firms out there. Even Google, for example, will only allow a few languages in their firm.
Note that this was before Go even had a stable release, and while the language was still evolving very fast, I'd expect more companies outside the "hi-tech" to adopt it now that it is stable.
This is great news. The best part of it for me is that now my more conservative colleagues might dip their toes in the water. Combine that with the Vitess project and Go is not just a great language. It's viable.
"Initial reactions to Go 1 have been overwhelmingly positive, particularly (and not surprisingly) on community sites like Hacker News, a Y Combinator-run reddit clone populated by self-acknowledged hipster hackers." Hah: http://webdev360.com/google-releases-go-1-to-rave-reviews-41...
And it's self-contained in the sense that when you code you may simply launch it locally :
godoc -http=:6060
Of course this will be less needed now that the API are stable but that what really useful those last months, when my go weekly was almost never exactly like the one described at golang.org nor tip.golang.org. I'll still use it in planes and trains though.
There should be a lot of complementary answers. Here's one.
Go is a fun language to make concise server programs that will run with no surprise (no exception hiding bugs), that you will compile without looking for something else to do during the waiting, that you'll be able to profile easily, that will include foreign libraries easily, and that will run reasonably fast (and they will feel astoundingly fast because you won't have to wait for them to start).
I'm disappointed that after starting from scratch they created a "modern" language that requires a module import just to print (and corresponding extra syntax for that namespace when making the call).
How could this not have seemed incredibly clunky after using it for just a little while? It's the same frustration one feels when simple print-outs fail in C++ because you forgot to "#include <iostream>". Sometimes you just want to print stuff no matter what file you're in. Languages should make it almost impossible to fail at extremely common tasks. It's these little things that make Python and Perl enjoyable to program in, and these little things that every new language should begin with!
One of the design goals of Go is that the language is small. There's nothing so special about string formatting that it should be part of the language proper, and it would add a lot of complexity to the spec if it were.
With that said, there are built-in print and println functions that write to stderr, which are useful for debugging. That would seem to address your complaint. The fmt package is a lot more fully-featured than the built-ins though.
Thanks for pointing it out. I wish they used that in their "hello, world" example because 'println("hello, world")' leaves a much better first impression of simplicity.
I generally like to see things kept simple. But formatting is a common need and they've actually made things less simple by providing both fmt.Println() and println(). It means the same program will inevitably contain both, depending on who did the editing. There are times when a feature is so basic that it really should have exactly one way to do it, and I think printing is in that category.
Your position is not very pragmatic, and taking such a hard line is rarely productive.
The fmt package does a lot of stuff. Check out the link I provided above. To put all that stuff into the language spec - and then foist responsibility of writing and maintaining that code onto every implementation of the language - would be crazy. So it seems a good idea that the fmt package should exist and that it should be written in Go.
On the other hand, it's nice to be able to print when working on low-level libraries where fmt is not available (syscall, os, etc). The print and println functions service this need, and that's really all they're used for apart from temporary debugging prints.
It would be a mistake to use the built-in println in the hello world example because it would demonstrate precisely the wrong use of the built-in functions. Hello world should print to standard output and it should use the standard means of formatting strings. In Go, that is fmt.
There are a few of such compromises in Go (not many, though). Sometimes you need to put your ideals to the side in the name of simplicity and pragmatism.
I foresee the next version being considered harmful.