Hacker News Reader

Comment by GFK_of_xmaspast | Hacker News Reader

As a C++ programmer, if I wanted that kind of stuff why wouldn't I switch to java.

You get the ability to use lightweight concurrency contexts (go-routines) + channels. Those are built in. The included library is very good.

But if you are used to generic programming and you think in terms of it, type handling in Go and might think it is a step backwards and Java might be close to what you'd want.

Even better, I think as C++, Rust is starting to look interesting. I am waiting for them stabilize it more (maybe get to beta 1.0 status), because I think it has some very cool things going for it.

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

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

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

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.

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

> 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