3 ms·

The article seems to make a lot of very dubious claims about Java. Especially when they started this project, Java performance was much better than go (Those d

by readams 11y ago

The article seems to make a lot of very dubious claims about Java. Especially when they started this project, Java performance was much better than go (Those double-digit second GC pauses weren't a concern with go?), and the Java garbage collection remains much more sophisticated than even current bleeding edge go. Also the claim that you have to add extra interfaces to Java is completely false. There's no reason at all you need to add pointless interfaces in Java. Java's type system is strictly more powerful than go's type system. This was actually a design choice in go to make the language easier. Java generics are also a huge boon when writing something like a database. Modern C++ also would have been an excellent choice for writing a database, and would have been much more productive than go.

59nadir 11y ago
> The article seems to make a lot of very dubious claims about Java. I was also stumped by this confidence in that Go is supposed to be better than Java performance-wise and I do think that the claims warrant some proof. However: > Modern C++ ... would have been much more productive than go. I'm not up to date on current C++, but this seems like a claim much like the ones you objected to. Could you elaborate on how C++ is a more productive language (in this case?)?
schmichael 11y ago
"What remains to be seen, of course, is how all of this Go code will perform." They're pretty clear and honest that Go's performance characteristics are an unknown and not the reason it was chosen.
- detrino 11y ago
  There is a clear bias. When talking about Java: > JVM garbage collection is notoriously expensive. > Java’s known performance issues made it unappealing. > However, in our past experience, we ported a large system from Java to Go, which greatly decreased its memory footprint and garbage collection overhead. When talking about Go: > What remains to be seen, of course, is how all of this Go code will perform. Yet: The JVM's GC is superior to Go's, Java tends to outperform Go, and a large memory footprint is a necessary evil for getting good performance out of any GC.
arthursilva 11y ago
> Modern C++ ..., and would have been much more productive than go. This is definitely not correct. Any GC language with even the most basic packaging support (go get etc.) is miles ahead of C++ productivity wise.
- dman 11y ago
  Depends on the problem at hand - if youre talking about code that is not performance / memory sensitive then sure.
- maccard 11y ago
  Why does package support make it more productive than c++? For most c++ libraries you download the source, build it (platform dependent) and set includes/libs and youre done. More so, you only tend to mess with dependencies infrequently, so who cares if it takes an extra 5 minutes once every 6 months?
pkulak 11y ago
I agree. I may be wrong, but I don't think there's anything intrinsically better about Go vs Java from a GC perspective. Go has a developer-accessible stack, so there may be more opportunity for tuning there, but they both do escape analysis and Java will put things on the stack for you if it determines that it can. They both have loads of really smart people working on GC, so I'd be really surprised if one was far better in that regard than the other.
- jerf 11y ago
  "I may be wrong, but I don't think there's anything intrinsically better about Go vs Java from a GC perspective." Go has a lot more things that can be value types than Java at the moment, which can help for some use cases, and doesn't do squat for others. I'd say it's easier to use Go in a way that lets you avoid the GC entirely, but only easier, not "easy", and when you are forced on to the GC Java will of course have the advantage, at least if you have enough RAM. It's more nuanced than "Java is always better"... which is to some extent precisely why Java is last I knew looking at adding value types, which would tip this discussion firmly back in Java's camp from a technical point of view, probably. (At least once it matured.) I'm not sure what the current status of that discussion is; all the discussions I can dig up in Google are still saying it may go in to Java 9. Anyone with a more up-to-date link, please let me know.

by readams 11y ago

59nadir 11y ago

> The article seems to make a lot of very dubious claims about Java. I was also stumped by this confidence in that Go is supposed to be better than Java performance-wise and I do think that the claims warrant some proof. However: > Modern C++ ... would have been much more productive than go. I'm not up to date on current C++, but this seems like a claim much like the ones you objected to. Could you elaborate on how C++ is a more productive language (in this case?)?

schmichael 11y ago

"What remains to be seen, of course, is how all of this Go code will perform." They're pretty clear and honest that Go's performance characteristics are an unknown and not the reason it was chosen.

detrino 11y ago
There is a clear bias. When talking about Java: > JVM garbage collection is notoriously expensive. > Java’s known performance issues made it unappealing. > However, in our past experience, we ported a large system from Java to Go, which greatly decreased its memory footprint and garbage collection overhead. When talking about Go: > What remains to be seen, of course, is how all of this Go code will perform. Yet: The JVM's GC is superior to Go's, Java tends to outperform Go, and a large memory footprint is a necessary evil for getting good performance out of any GC.

arthursilva 11y ago

> Modern C++ ..., and would have been much more productive than go. This is definitely not correct. Any GC language with even the most basic packaging support (go get etc.) is miles ahead of C++ productivity wise.

dman 11y ago
Depends on the problem at hand - if youre talking about code that is not performance / memory sensitive then sure.
maccard 11y ago
Why does package support make it more productive than c++? For most c++ libraries you download the source, build it (platform dependent) and set includes/libs and youre done. More so, you only tend to mess with dependencies infrequently, so who cares if it takes an extra 5 minutes once every 6 months?

pkulak 11y ago

I agree. I may be wrong, but I don't think there's anything intrinsically better about Go vs Java from a GC perspective. Go has a developer-accessible stack, so there may be more opportunity for tuning there, but they both do escape analysis and Java will put things on the stack for you if it determines that it can. They both have loads of really smart people working on GC, so I'd be really surprised if one was far better in that regard than the other.

jerf 11y ago
"I may be wrong, but I don't think there's anything intrinsically better about Go vs Java from a GC perspective." Go has a lot more things that can be value types than Java at the moment, which can help for some use cases, and doesn't do squat for others. I'd say it's easier to use Go in a way that lets you avoid the GC entirely, but only easier, not "easy", and when you are forced on to the GC Java will of course have the advantage, at least if you have enough RAM. It's more nuanced than "Java is always better"... which is to some extent precisely why Java is last I knew looking at adding value types, which would tip this discussion firmly back in Java's camp from a technical point of view, probably. (At least once it matured.) I'm not sure what the current status of that discussion is; all the discussions I can dig up in Google are still saying it may go in to Java 9. Anyone with a more up-to-date link, please let me know.