Go version 1 is released
blog.golang.org
blog.golang.org
I foresee the next version being considered harmful.
for those unaware: the mascot of Go is a gopher.
"Oh, I got the golaris! better get an ointment for this"
For root 2: Version 1, Version 1.4, Version 1.41, etc.
For those interested, you can run Go apps on Heroku using this buildpack: https://github.com/kr/heroku-buildpack-go
Note: you may need to use the #rc branch until its changes are merged in master
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.
The right tool for the right job and all that.
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.
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.
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?
[Edited: added "of error handling"]
FWIW, the go dashboard (https://godashboard.appspot.com/) has a number of interesting projects.
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.
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...
EDIT : I found an example on the golang site. If you're not interested in JSON, it will be more suited to your need : http://golang.org/doc/effective_go.html#web_server
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)
}
for _, ami := range amis {
go bra.EnrichitCouchePNG(ms.répertoireCartesBraldun(ami.IdBraldun, ami.Mdpr), couche, PNG_CACHE_SIZE)
}
répertoire
СпрСотр = СоздатьОбъект("Справочник.Сотрудники"); СпрСотр.Новый(); СпрСотр.Наименование = ФИО; СпрСотр.Должность = Должность; СпрСотр.Оклад = Оклад; СпрСотр.ДатаПриема = ДатаПриема; СпрСотр.Записать();
It's not surprising they were not able to expand to the Europe market.
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.
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.
Compose-Key e ' => é
Compose-Key e ` => è
Compose-Key e " => ë
Compose-Key e ^ => ê
Option-e e => é
Option-` e => è
Option-u e => ë
Option-i e => êI do wish the Thrift support was as good as the protocol buffer support, though. :)
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).
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.
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.
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!
Don't be afraid to read the code in the stdlib, is very readable.
SVGo paper from SVG Open 2011: (https://www.svgopen.org/2011/papers/34-SVGo_a_Go_Library_for...)
Samples: (http://www.flickr.com/photos/ajstarks/sets/72157623441699483...)
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 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.
Pity about the whole "not having generics" thing though.
Of course, most of the functional language DO have generics, and full type inference to boot, also.
So, in other words, Lisp doesn't have generics in the same way Python doesn't have generics.
Plus, you pay the overhead of boxing.
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.
What?
It provides an interactive in-browser panel to try out the language while presenting its features.
I know lots of Googlers hang out here, but your comment is buried pretty deep.
Can we now say that Google Chrome can be written in Go and it will be faster and/or stable ? ( not saying it is not already. ).
Congrats to the team, just started using go yesterday and loving it.
The major speed problem right now is GC, but that should be improving quickly.
(If you meant CPU speed, http://blog.golang.org/2011/06/profiling-go-programs.html :-)
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.
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.
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.
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.
In particular I apologize for bringing this up in every Go discussion.
[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.
http://blog.golang.org/2011/12/building-stathat-with-go.html
http://code.google.com/p/vitess/
There are more that we know of, and as they say that publicly we'll try to highlight them on the blog. Thanks.
http://go-lang.cat-v.org/organizations-using-go
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.
For example, I tried searching for how to use Go on Android. But "go android" returns all kinds of unrelated stuff.
Well done to whoever does the design and content.
godoc -http=:6060
Is designed to provide a Go-ish interface for win32.
GO IS AWESOME
GO IS A FUCKING WASTE OF TIME
HOW DO I MAKE JAVASCRIPT TALK TO GO?
Propsed Theme Song: I got my Go, Go, Go, Go (gadget flow) ... Lupe Fiasco (http://www.youtube.com/watch?v=vCf-ffDzopc)
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!
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.
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.
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.