3 ms·

Please don't call it java lite. Yes, it targets many of the same projects you might write in java, and it has garbage collection, but it's very different from

by NateDad 13y ago

Please don't call it java lite. Yes, it targets many of the same projects you might write in java, and it has garbage collection, but it's very different from java in the feel and the resultant code, and nothing "lite" about it.

pron 13y ago
Not to get into an argument, but I find Go and (modern) Java almost identical. Not in exact features (they treat interfaces and exceptions differently), but in the general philosophy of the language (i.e. "blue collar") and the level of abstraction. Go is simpler than Java, so I agree with the "lite" as well. I would use Go for simple, relatively small, self-contained projects, and Java for bigger, heavy-duty stuff. The languages are so similar that I hardly feel it when I switch from one to the other. Obviously, you can't compare small Go projects to huge Java monstrosities that were written in the old Java style (lots of XML configuration etc.), but modern Java and Go are hardly distinguishable (in approach; not syntax). Maybe I'm particularly prone to this view because I've implemented true fibers (goroutines) and channels for the JVM, so I sometimes transliterate Go code to Java (the resulting code is always of similar length, perhaps with a slight advantage to Java, now with Java 8's streams and such).
- azth 13y ago
  > so I sometimes transliterate Go code to Java (the resulting code is always of similar length, perhaps with a slight advantage to Java, now with Java 8's streams and such). How does performance compare?
  - pron 13y ago
    As usual, that depends. Java performs better on function calls (because of the JVM's inlining JIT) and garbage collection. But because fibers are not native to the JVM, they do incur some overhead. If the fibers perform no work, then you're essentially just measuring the overhead, and Go would perform better. The more work is done, the more the advantage goes to Java. With regards to IO, fiber-blocking IO currently uses the JVM's asynchronous NIO (which uses epoll/kqueue) under the covers, unchanged. But Java's async NIO is intended to be thread-safe, so there is lots of unnecessary synchronization going on there. The result is about 7% slower than Go. Again, the more computation work you do, the more the performance swings in favor of Java. We can do much better with IO by plugging our own NIO provider (Java's dynamic linking everywhere is awesome), but because the performance is really good as it is, it's not a top priority for us at the moment. EDIT: the reason I would use Java over Go for all the "serious stuff" isn't primarily performance, though. It's the incredible monitoring and profiling capabilities, hot code swapping and other stuff that's possible with full dynamic linking.
    - azth 13y ago
      Thanks for the insightful reply. :)
- NateDad 13y ago
  I work on Juju, a 240k loc Go project which spans 4 executables across multiple machines all working in concert, coordinating through a replicated Mongo database. It's pretty big. Go was designed by people at Google for large projects. Saying it's only good for small ones is selling it short.

by NateDad 13y ago

pron 13y ago

Not to get into an argument, but I find Go and (modern) Java almost identical. Not in exact features (they treat interfaces and exceptions differently), but in the general philosophy of the language (i.e. "blue collar") and the level of abstraction. Go is simpler than Java, so I agree with the "lite" as well. I would use Go for simple, relatively small, self-contained projects, and Java for bigger, heavy-duty stuff. The languages are so similar that I hardly feel it when I switch from one to the other. Obviously, you can't compare small Go projects to huge Java monstrosities that were written in the old Java style (lots of XML configuration etc.), but modern Java and Go are hardly distinguishable (in approach; not syntax). Maybe I'm particularly prone to this view because I've implemented true fibers (goroutines) and channels for the JVM, so I sometimes transliterate Go code to Java (the resulting code is always of similar length, perhaps with a slight advantage to Java, now with Java 8's streams and such).

azth 13y ago
> so I sometimes transliterate Go code to Java (the resulting code is always of similar length, perhaps with a slight advantage to Java, now with Java 8's streams and such). How does performance compare?
- pron 13y ago
  As usual, that depends. Java performs better on function calls (because of the JVM's inlining JIT) and garbage collection. But because fibers are not native to the JVM, they do incur some overhead. If the fibers perform no work, then you're essentially just measuring the overhead, and Go would perform better. The more work is done, the more the advantage goes to Java. With regards to IO, fiber-blocking IO currently uses the JVM's asynchronous NIO (which uses epoll/kqueue) under the covers, unchanged. But Java's async NIO is intended to be thread-safe, so there is lots of unnecessary synchronization going on there. The result is about 7% slower than Go. Again, the more computation work you do, the more the performance swings in favor of Java. We can do much better with IO by plugging our own NIO provider (Java's dynamic linking everywhere is awesome), but because the performance is really good as it is, it's not a top priority for us at the moment. EDIT: the reason I would use Java over Go for all the "serious stuff" isn't primarily performance, though. It's the incredible monitoring and profiling capabilities, hot code swapping and other stuff that's possible with full dynamic linking.
  - azth 13y ago
    Thanks for the insightful reply. :)
NateDad 13y ago
I work on Juju, a 240k loc Go project which spans 4 executables across multiple machines all working in concert, coordinating through a replicated Mongo database. It's pretty big. Go was designed by people at Google for large projects. Saying it's only good for small ones is selling it short.