We initially called Go a "systems language," because we wanted to use it to build systems software. What we mean by that is high-performance networked programs that run on multicore machines. The kind of server stuff people traditionally use C or C++ for. Since Go's release last November, we've seen interest in Go from a lot of different places. There was the high-performance computing crowd that we were targeting, but beyond that we saw a lot of users of interpreted languages who craved more speed with the same ease-of-use.
We're yet to see which major niche Go fills, if any. There's a growing community of people from different backgrounds using it, and they seem to enjoy it. I personally think it's a lovely language to write all kinds of code in. I recently rewrote our continuous build client in Go, and I found it a cinch to write it in clear, reliable, maintainable way. It's definitely worth checking Go out because, even though it ticks a lot of the same boxes as existing languages, it's quite different from anything else out there in many subtle ways. Certainly for writing server daemons it totally kicks ass.
It's easy to get started. The standard library is featureful (http://golang.org/pkg/), and there's a lot of good documentation (http://golang.org/doc/docs.html). As for integrating with existing code, Go comes with a tool called cgo (http://golang.org/cmd/cgo/) which allows you to write Go code that links with C code. It's pretty easy to use, and there are many third party libraries (http://godashboard.appspot.com/project) that use it. There's also Go support for SWIG for linking against C++ code.
In fact, Go looks like Java with an ActionScript 3.0 syntax.
Is there anything going on for it that Java doesn't have, or do better?
[Edit:
By the way, I keep hearing Go is an excellent language for writing daemons. Why is that? when it doesn't even have anything resembling exception handling, much less a condition system?
If you think that, then you need to take a closer look at Go, or Java, or both. In short: Go compiles to native code (no VM), it has a totally different type system (no classes, not everything is an 'object' like in Java), it permits fine control over memory layout and allocation, it has powerful concurrency primitives (goroutines and channels), and more. Do yourself a favour and look beyond the syntax. It really is very different to Java (or Actionscript?! that's one of the more bizarre comparisons I've heard).
Java compiles to native code too, when and where it matters.
I have looked at Go, as much as the spec would permit me, and what I found was a safe C (or a faster, native Pike) with better concurrency primitives and a dash of higher-order functional goodness.
With respect to the finer control over memory allocation; anything one couldn't have done with pools in a GC'ed language? I would love to see how Go handles intricate manual memory layout specification under heavy load, and how sufficiently smart the compiler/runtime is as it tries to guess the best GC strategy :-)
> With respect to the finer control over memory allocation
I think you are understanding it wrong. Go lets you control memory layout, think deciding how things are laid out in a struct. In Java you get indirection and pointers instead. System programming refers mainly to this ability of layout out your data in memory. This makes a world of difference when you are doing high performance code and can control cache locality.
Not really. You can use JNI but it's awkward, discouraged, and every JNI call has overhead -- so much overhead that in the Hadoop project, for example, it was faster to implement their own CRC32 than to use the built in one calling zlib.
> it permits fine control over memory layout and allocation
I had thought that Go had a built-in garbage collector that could not be disabled - is that incorrect? Can you build code that only touches memory with explicit malloc/free (or equivalent) calls?
I was very interested in Go when it was announced, but the GC rules it out for my problem domain (high-performance real-time games). If I can do explicit memory management then that makes it interesting again.
> Can you build code that only touches memory with explicit malloc/free (or equivalent) calls?
Yes you can. There is a package called 'unsafe' that lets you do pointer arithmetics and turn pointers into valid go types. It requires a bit of finesses, pointers from your own memory obviously wont be counted by the gc etc. Plus you need to make sure you only allocate with your own functions.
That said, the gc is getting along, it's hard to say when it hits a spot where you can use it for soft realtime applications. We just started doing high performance server coding in Go at Tinkercad and I used it while I still was at Google.
Java is not a systems language. You need a virtual machine to run Java (or at least that's the point).
Why is Go an excellent language for writing daemons?
I think[1] that it's because Go is light-weight language, but still a "systems language". Low memory use which are important for daemons, while being significantly less complex than C++, and more typed than C.
Building daemons in Java, .Net, python, ruby, whatever really takes an impact on memory usage[2]. And python, ruby also on performance. C++, C takes a impact on development time and/or type safety.
[1]: (I haven't really looked much into Go)
[2]: This of cause depends: If you already are using Java and thus have loading many of the libraries needed, I would guess the impact is significantly less.
1) You are very wrong about Java not being a systems language, in fact, it's a whole platform. Java supplants Posix, Win32 and whatever else that shipped from your OS vendor.
2) You haven't argued well for the daemon-friendly aspects of Go. Memory footprint is not a valid excuse; I have written daemons in shell-scripts, and they had smaller memory foot print than anything you would write in Ruby or Python, because the shell executable is always resident in memory ;-) In fact, with Go lacking any sort of exception handling mechanism, I think I trust Bash scripts more[1] ;-)
In this context systems language is difference from having access to the operating system. A systems language lets you write things like device drivers or operating systems.
The only "systems language" is one that an OS with its accompanying device drivers are written in.
Would you consider C a systems language? well, C is useless under a LispOS, for example. Ditto for Java. If you wrote the whole OS in Java, presto, Java would be the language to write device drivers.
I am tired of answering questions you can't be bothered answering yourself. It wouldn't bother me so much if you hadn't already formed such strong opinions already. If you're not interested in learning the language, then just be quiet. It's not useful to spread misinformation about something you don't understand.
I've been really excited about Go, but I've been stuck in one of those dilemmas where I don't really learn a language until I work on a tangible project with it, and I can't seem to come up with anything I need to write in Go.
I'm sure something will surface eventually, and I hope soon, because everything about Go makes me very excited about programming.
Has any headway been made on the issue of generic programming in Go? I haven't heard anything since the discussion on Russ Cox's blog about it a few months ago ( http://research.swtch.com/2009/12/generic-dilemma.html ). It would be very, very interesting if the techniques described by Stepanov in Elements of Programming could be applied in Go without a runtime performance hit or the destruction of Go's fantastic compile times (commenter Rivorus from the blog post seemed to think this was possible, and that even the baroqueness of C++ templates could be avoided).
e: Unfortunately I'm too busy with class and work lately to really learn more than a trivial amount of Go, but it's nice to hear news every so often so that I can remain abreast of developments and hopefully not be flat-footed when I do have time to dive in
Ideone is pretty cool, although it seems slower, and the editor doesn't indent.
Also, it's running a _really_ old version of Go. (http://ideone.com/spBzw) It's at least 400 revisions out of date. We intend to keep the golang.org Playground up-to-date.
I like the examples at the Go Playground.
Ideone uses gc-2010-07-14 so it seems to be quite ancient but ok - it is not the up to data version, but I really do not get your comment about speed (do you mean the execution time, response time or what?) and the indent feature (It seems to me there is no auto indent feature and the "Tab" key moves you to the examples list).
There's a bug in the interface code for non-Chrome browsers. In Chrome, the tab key works, and the text area auto-indents. It's a small comfort but it makes a world of difference for me.
There have been language changes as recently as this week. Go moves fast (although it's unusual for existing code to break).
Do you know of any that do come with source? I'd love to have a look.
http://codepad.org/about has a useful 'Paranoia' section: it was the starting point for me to build my own code-judging service. I couldn't find anything else at the time.
That's non-standard C++ so it might not be immediately useful, but I managed to find some nice info in the source on which system calls to consider dangerous.
