Hacker News Reader

Comment by mahmud | Hacker News Reader

Everything that Go has is already in Java.

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?

This is the Go spec: http://golang.org/doc/go_spec.html

]

View on HN

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

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] ;-)

[1] http://linux.die.net/man/1/trap

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.

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.

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

Reply on news.ycombinator.com