Hacker News Reader

Comment by vowelless | Hacker News Reader

Go is less verbose than Java arguably. Multi-threadedness in Go is very straightforward. Native code binaries can be beneficial in some cases.

View on HN

For me, the killer feature of Go is that it produces executables that are quick to start up and run with a small memory footprint. It is great for utilities or agents or small daemons; where startup time or memory size are critical. It can also run without a JRE or other dependencies, which is nice if you are distributing software to end-users.

So I'm not sure I agree on your first two points. For me, lack of exceptions and generics means Go code is at least as verbose as Java, if not more so. Multi-threadedness is a wash for me; channels vs fork-join and executors are just not that different.

I think Java can produce native code today, but it isn't worth it for most scenarios where you would actually use Java. I think we'll see that change if Oracle ships an AOT compiler in "official Java".

Coming from a C++ heavy background, I do miss generics. But I have been trying to be cautious of bringing my C++ habits to Go, opting instead to embrace the alternate model Go brings to the table. spf13 goes over some of these points in his talk here: http://vimeo.com/115776445

I do not use exceptions in C++ so that was not a big change for me. Our code needs to be relatively deterministic (even though we are not hard real-time yet) and exceptions hamper with that goal.

I incorrectly used the word "multi-threadedness". Concurrency in go is very straightforward. Channels are extremely lightweight and are different from forking (which creates a new process with its own address-space).

I watched the entire video which was interesting, but I noticed that he is performing read operations on a map without any kind of read lock. That is not safe behaviour I am pretty sure :)

AOT compilers are available in many licensed JVMs, but one is planned for official Java around Java 10 time-frame.

http://cr.openjdk.java.net/~jrose/pres/201502-JVMChallenges....

Slide 12.

That would be amazing if Java didn't have AOT compilers. (See my other comment.)

> Native code binaries can be beneficial in some cases.

Available in Aonix, IBM J9, Jamaica JVM, Excelsior JET

Just because OpenJDK doesn't offer it, doesn't mean others don't.

Reply on news.ycombinator.com