News for hackers. Stuff that matters.

A comment on A year with Go. Parent comment

Re:A year with Go by threeseed on Friday June 05, 2015 @08:07PM (#9668981)
Compile times are largely irrelevant if you use something like JRebel, Play, Tomcat or the many other frameworks that support hot reloading. And Java is far broader and more flexible at concurrency than Go with libraries like Quasar, LMAX Disruptor and the many HFT contributed ones.

Let's also not forget that Java is significantly faster, has every library under the sun, has a dependency system that actually makes sense and you have seamless interop between multiple languages e.g. Ruby, Python, Scala, Clojure.

Anyone who thinks Go is an upgrade to Java is woefully misinformed.

[ Parent | on HN ]
Re:A year with Go by ascendantlogic on Friday June 05, 2015 @09:28PM (#9669198)
"Let's also not forget that Java is significantly faster"

Citations please. While I am not necessarily saying I don't believe you (because a properly tuned JVM is lightning fast), making a statement like this without numbers to back it up is a gaping hole in your argument.

[ Parent | on HN ]
Re:A year with Go by nkozyra on Friday June 05, 2015 @10:09PM (#9669309)
As always, it depends on what you're measuring. I find it to be largely a wash

http://benchmarksgame.alioth.debian.org/u64q/go.html

Keep in mind this is comparing Go 1.4, I'd expect 1.5 to do better.

[ Parent | on HN ]
Re:A year with Go by TheDong on Saturday June 06, 2015 @12:06AM (#9669614)
You say that, but because 1.5 is written in Go, it actually does significantly worse on some benchmarks and actual programs.

See: https://talks.golang.org/2015/state-of-go-may.slide#11

[ Parent | on HN ]
Re:A year with Go by pcwalton on Saturday June 06, 2015 @01:02PM (#9671443)
Note that the benchmarks game is going to count compile time against Java, but not against Go, since Go is AOT compiled and Java is JIT'd. If your app is a long-running server, you should take the benchmarks game numbers with a grain of salt.
[ Parent | on HN ]
Re:A year with Go by igouy on Saturday June 06, 2015 @08:08PM (#9672838)
JVM start-up, JIT, OSR etc take very little time relative to most of the workloads shown on the benchmarks game.

http://benchmarksgame.alioth.debian.org/play.html#java

The notable exception (not included in summary measurements) is the few tenths of a second run-time for meteor-contest. Of that few tenths of a second: JVM startup takes 95%, JIT and OSR another 4.9%.

Whatever kind-of app you have, you should take general statements about program performance with a grain of salt, there's even a page for that --

http://benchmarksgame.alioth.debian.org/dont-jump-to-conclus...

[ Parent | on HN ]
Re:A year with Go by igouy on Friday June 05, 2015 @11:09PM (#9669462)
Keep in mind Go 1.5 has not been released yet :-)
[ Parent | on HN ]
Re:A year with Go by threeseed on Saturday June 06, 2015 @12:02AM (#9669598)
Not the best but the Techempower one is one example:

https://www.techempower.com/benchmarks/#section=data-r9

And arguably more real world than microbenchmarks.

[ Parent | on HN ]
Re:A year with Go by jusssi on Saturday June 06, 2015 @05:03AM (#9670198)
There are cases where the Go compiler generates horrors, and the only workaround is to write your code in asm.

Here's one example:

// imagine a for-loop around this

s := foo[i:i+4]

s[3], s[2], s[1], s[0] = s[0], s[1], s[2], s[3]

The reasonable assumption is that the second line generates either zero, one, or four bounds checks on s. However, the Go compiler likes to be sure, and turns it into 8 bounds checks.

I agree it's not a typical for a server to spend the majority of it's time swapping bytes. In the rare case that happens, you're going to hate the compiler for not being smarter.

EDIT: fixed formatting of the example

[ Parent | on HN ]
Re:A year with Go by woah on Friday June 05, 2015 @09:26PM (#9669192)
Some people like things that are minimal and good enough. Also, there is a huge swath of engineers who just really dislike writing Java.
[ Parent | on HN ]
Re:A year with Go by caoilte on Friday June 05, 2015 @08:27PM (#9669037)
Adrian Cockcroft does and I don't disrespect his opinion even though I'd far rather functional languages won the developer mindshare myself.

We shouldn't be under-selling how light the Go footprint is. In the long run it may be one of the few languages to compete with unikernels.

[ Parent | on HN ]
Re:A year with Go by Jweb_Guru on Friday June 05, 2015 @10:07PM (#9669303)
> In the long run it may be one of the few languages to compete with unikernels.

Can you please clarify what this means? I don't really understand what it would mean for a language to compete with a unikernel.

[ Parent | on HN ]
Re:A year with Go by Thetawaves on Saturday June 06, 2015 @12:17AM (#9669643)
Most of the benchmarks I have found show go to be faster at cpu things and java to be faster at memory things.

This is no surprise considering that go is a compiled language and the java garbage collector has had decades of very smart people working on it.

[ Parent | on HN ]