> Everything that Go has is already in Java.

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 :-)

I wish you all the best.

> 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.

Edit, found the link: http://marc.info/?l=git&m=124111702609723

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.

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.

IOW, "systems" is a relative term.

You are wrong about Go lacking exceptions. See panic/recover/defer in the spec.

Are these exceptions typed and/or checked?

FWIW, the FAQ itself says it doesn't have proper exception handling:

"Why does Go not have exceptions?"

http://golang.org/doc/go_lang_faq.html

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.

See Rob Pike's talk: http://www.youtube.com/watch?v=5kj5ApnhPAE to understand Go in relation to Java.