7 ms·

I don't see why you'd choose Go instead of a JVM language like Java, you get the language simplicity (plus features like Generics) and the performance upside to

by catfest 10y ago

I don't see why you'd choose Go instead of a JVM language like Java, you get the language simplicity (plus features like Generics) and the performance upside too.

riffraff 10y ago
Single small binaries are easy with go, very hard with java.
- incepted 10y ago
  > Single small binaries are easy with go With static linking? I don't think so.
  - dikaiosune 10y ago
    Compared to a JAR with many dependencies and no option for LTO?
    - pjmlp 10y ago
      Java 9 brings LTO via jlink.
    - mappu 10y ago
      Does golang have LTO? (maybe only in gccgo?)
    - sievebrain 10y ago
      You can make an executable "fat jar" with Capsule. It has a little shell script prepended to the JAR which means you can run it like "chmod +x foo.jar; ./foo.jar" You can do dead code elimination and other forms of LTO using ProGuard. Just watch out for code that uses reflection. Java 9 will include a less aggressive version of the same thing which performs various link time optimisations like deleting modules (rather than individual methods/fields), statically pre-computing various tables, and converting from JAR into a more optimised (but platform specific) format. That tool can also bundle a JRE in with your app, giving you an "tar xzvf and run" deployment model. It's not a single file, but it makes little difference in practice. The same tool can build DEBs, RPMs, Mac DMGs and Windows EXE/MSI installers with a bundled and stripped JRE too.
      - dikaiosune 10y ago
        I'm a big fan of Capsule, actually. My point was not that Java and the JVM ecosystem are terrible (I quite like them), but rather that there is a spectrum of size and complexity and that Go's static binaries seem to be on the simpler to build side of JARs and on the smaller side of JARs. Also, I don't think there's much of a case to be made that bundling a JRE with your JAR is small, even though the tooling might be simple and it might resolve many deployment issues.
    - prodigal_erik 10y ago
      Putting a jar on your classpath works just like depending on a shared library but with much stronger compatibility guarantees and better chances for optimization.
  - jsmthrowaway 10y ago
    You think wrong. It was the default of the compiler for a long time and only requires minimal work now.
- rat87 10y ago
  Also smaller memory usage.
- pjmlp 10y ago
  If you have the money, there are lots of commercial JVMs with compilers to native code. There are quite a few open source ones, but they aren't as stable. As always, Language != Implementation.
  - fosk 10y ago
    Could you recommend any that you have had experience with?
    - pjmlp 10y ago
      I just know them from Java conferences. Excelsior JET is the most well known one. Oracle actually also supports AOT but only on embedded systems, with the commercial JDK.
    - sievebrain 10y ago
      RoboVM is one that compiles AOT ARM binaries, it's intended for the iPhone but it runs on MacOS too. Avian is a JIT compiling JVM but one which is much smaller than HotSpot. It has a mode where it statically links your JAR into the binary itself, so you get a single self contained executable. With ProGuard and other optimisations like LZMA compression built in, such binaries can be remarkably small. Try their example: https://readytalk.github.io/avian/#-xamples https://readytalk.github.io/avian/#-xamples It's a full blown GUI app that demonstrates the full range of widgets available, is cross platform, and yet is only about 1mb in size.
      - bmaupin 10y ago
        RoboVM can also compile to OS X and Linux: Usually this means iOS and the ARM processor type but RoboVM is also capable of generating code for Mac OS X and Linux running on x86 CPUs. [0] There are several forks of the latest open-source version of RoboVM. This one in particular is targeting desktop/server usage: https://github.com/ashleyj/aura https://github.com/ashleyj/aura See also: https://news.ycombinator.com/item?id=7579737 https://news.ycombinator.com/item?id=7579737 [0] http://docs.robovm.com/advanced-topics/compilation.html http://docs.robovm.com/advanced-topics/compilation.html
danellis 10y ago
That comes with a big memory cost, though. Also huge startup time, so not suitable for command line tools.
- pjmlp 10y ago
  Just get an AOT compiler, plenty to choose from. Also since Java 8 with tiered compilation, I wouldn't consider a few ms a huge startup time.
- catfest 10y ago
  I don't think startup time is an issue, and memory is definitely manageable - check out LMAX Disruptor (https://lmax-exchange.github.io/disruptor/ https://lmax-exchange.github.io/disruptor/)
- sievebrain 10y ago
  Java startup time is ~50msec, which for command line tools is fine.
  - kgabis 10y ago
    Unless you run them in a loop, which is not that uncommon.
omginternets 10y ago
>you get the language simplicity And the most complex toolchain imaginable. This is what turns me off to Java, personally, but I think my case is fairly representative.
- catfest 10y ago
  The toolchain is what's so awesome about Java - moving to a language like Go means you lose so much, it's painful.
  - imtringued 10y ago
    Which is why it's mostly developers that previously used dynamic languages. They didn't have sophisticated IDEs.
- adrianN 10y ago
  Nobody forces you to use a complex toolchain for Java. You can use javac and ed if you like. But Java is sufficiently simple and sufficiently popular for pretty awesome tooling to be available. Refactoring Java code is a breeze because your IDE understands the code perfectly.
- discreteevent 10y ago
  A text editor, javac and java that's what I used for a few years when I started using it. I wrote a lot of code like that. I don't see why you couldn't?
- sievebrain 10y ago
  If popular Java toolchains are the most complex you can imagine, I assume you have never encountered autotools, or really any toolchain for a large C++ project. Toolchains normally mean build systems, debuggers, profilers, editors and other things. Java itself doesn't require any build tool at all, you could do it all with a custom shell script. The next step up after that is an IDE like IntelliJ where you press "new project" and just start writing code. The IDE's build system will do it all for you. There is no complexity. But most people want features like dependency management, IDE independence, command line builds, ability to customise the build with extra steps and so on. That's when you upgrade to something like Gradle (or maybe Maven if you like declarative XML). That'll give you dependency resolution with one-line-one-dependency, versioning, automatic downloads, update checking and other useful features. Many IDEs can create a Gradle project for you. When I first encountered Java it seemed the most popular build tool was Maven, which looked very over complex at first due to its poor docs and love of inventing new words, but pretty quickly found that it wasn't so bad in reality. Gradle avoids the custom dictionary and uses a much lighter weight syntax. It's pretty good.
thegenius2000 10y ago
Language simplicity? I disagree, Java is only agreable if you're comfortable with (1) being forced to work in an OOP-only environment and (2) using the JVM. And while you can argue for the upsides of both of these (which I believe are few and far between) they certainly add a great deal of clunky complexity, which many programmers are fleeing to Golang to avoid.
reycharles 10y ago
> you get the language simplicity I remember the Go language specification to be about as long as the table of contents for the Java language specification. On the other hand, Brainfuck is an extremely simple language, too.
- masklinn 10y ago
  > I remember the Go language specification to be about as long as the table of contents for the Java language specification. I'm not sure where you got that from. On my browser and screen, the JLS8 TOC[0] is 16 pages high which brings me about 20% into the Go language spec[1]. But then again that's a completely inane appeal to emotions: because it's a specification for cross-platform and cross-implementation compatibility (not a user-targeted documentation): * the JLS is exactingly precise, the JLS's "lexical structure" section is about 3 times longer than GoSpec's "Lexical Elements", the JLS's "Execution" section is about 6 times longer than GoSpec's "Program initialization and execution" * the JLS contains entire sections which don't get a mention in GoSpec, like binary compatibility concern, or the language's entire execution model (calling a function gets a page in gospec, it gets 20+ in the JLS) and its multithreaded memory model The JLS is longer because its goal is that you be able to reimplement a Java compiler and runtime just from it, it's Java's entire rulebook. Go's language spec is a much fuzzier document targeted towards language users — much like e.g. Python's language reference — there is no way you can write a clean-slate implementation just from the language spec. [0] https://docs.oracle.com/javase/specs/jls/se8/html/index.html https://docs.oracle.com/javase/specs/jls/se8/html/index.html [1] https://golang.org/ref/spec https://golang.org/ref/spec
  - reycharles 10y ago
    You are absolutely right, it's a silly comparison. The Go language spec is indeed vague. I did this comparison a while ago. It wasn't very accurate. The Go spec has probably changed. Unfortunately, it seems they don't keep older specs around(!) If I adjust the font size in the ToC of the JLS I get 23 pages and the Go Spec is 84 pages (27%). Not quite "about the same length", still. I took a compiler course in university where we implemented a compiler for a subset of java 1.3 (I believe), and the next year I was a TA in the compiler course. I got to read the (older) JLS quite a lot. I do find Java to be a more complicated language than Go. This does not mean I find it simpler to write programs in Go (c.f. Brainfuck).
fauigerzigerk 10y ago
Memory usage and as a consequence of that excessive GC pauses. I'm not looking at any JVM language again before they introduce value types in a couple of years (maybe).
- mcculley 10y ago
  I build soft real time simulation systems in Java. GC pauses haven't been a problem since 1.2 was released around 2000. Memory usage isn't a concern either for big applications, as there's not a lot of overhead in the runtime. There is the fact that one can't embed value types directly in objects, but I don't find that a problem in practice.
  - fauigerzigerk 10y ago
    Then your experience is very different from mine and that of many other people who resort to all sorts of off-heap solutions and distributing stuff across multiple VMs. I guess it depends a lot on the specific use case.
    - sievebrain 10y ago
      You can get 10msec pauses or less with heaps >100GB with HotSpot if you tune things well and use the latest GC (G1). If you want no GC pauses at all, ever, well, Go can't do that either. But if you are willing to pay money to Azul, you can buy a JVM that can. It also concurrently compacts the heap, which Go's GC does not. The issue is not Java. The issue is the quality of freely available garbage collectors, which are very good, but not pauseless.
      - fauigerzigerk 10y ago
        >You can get 10msec pauses or less with heaps >100GB with HotSpot if you tune things well and use the latest GC (G1). For what percentile of collections? I'm not wasting my time with incessant GC tuning only to delay that 5 minute stop the world pause for a bit longer. It's still going to hit eventually. For projects that might grow into that sort of heap size I use C++ (with an eye on Rust for the future). You are right that Go is not a panacea for very large memory situations, but you can do a lot more before Go even needs that amount of memory. The point is that languages without value types, such as Java and JavaScript, waste a huge amount of memory and generate a lot more garbage, thereby exacerbating all other related issues, including GC. I have done quite a lot of testing for our workloads. Java memory usage is consistently two to three times higher than that of Go or C++. I'm unwilling to waste our money on that.
eva1984 10y ago
Java itself is, IMHO, quite straightforward. But setup a java toolchain, building, deploying, and a lot of other configuration if some heavy framework is involved, is non-trivial. Gradle is like a must for modern Java application, and mastering itself takes some efforts. Go, when coming to toolchain, it is pretty much battery-included, best-practice-builtin, sometimes even a little forced. Language wise, Java recently has seem a more aggressive adoption of new and modern features, which is quite welcome for me personally, but it is still more LOC comparing to Go. I think Go is the new Python for light to middle complexity web service, with fewer people. Java is more for mature stuff, for larger scale collaboration.
- sievebrain 10y ago
  A build.gradle file that lists a few dependencies is like maybe 7 or 8 lines of code, which can almost all be cargo culted. You only need to start consulting the Gradle manual once you start doing things like defining custom build tasks or wanting to use custom plugins. Go's toolchain doesn't even bother with versioning. That's like the opposite of batteries-included, forced-best-practices. But of course it will seem simpler than a tool that does handle these basic things. If you want the benefits of Java with a lighter syntax then look at Kotlin.
  - vorg 10y ago
    > A build.gradle file that lists a few dependencies is like maybe 7 or 8 lines of code, which can almost all be cargo culted ...and that code is written in Apache Groovy. Strange why they'd bundle a Turing-complete scripting language for their build file DSL when it's only 7 or 8 lines long.
- twic 10y ago
  > Java [...] is still more LOC comparing to Go My experience is the exact opposite: Go takes more lines to do something than Java. I would say that in large part, this is because the error handling restricts expressions to a rather small size, and then because without streams, collection manipulation has to be written out longhand.

by catfest 10y ago

I don't see why you'd choose Go instead of a JVM language like Java, you get the language simplicity (plus features like Generics) and the performance upside too.

riffraff 10y ago

Single small binaries are easy with go, very hard with java.

incepted 10y ago
> Single small binaries are easy with go With static linking? I don't think so.
- dikaiosune 10y ago
  Compared to a JAR with many dependencies and no option for LTO?
  - pjmlp 10y ago
    Java 9 brings LTO via jlink.
  - mappu 10y ago
    Does golang have LTO? (maybe only in gccgo?)
  - sievebrain 10y ago
    You can make an executable "fat jar" with Capsule. It has a little shell script prepended to the JAR which means you can run it like "chmod +x foo.jar; ./foo.jar" You can do dead code elimination and other forms of LTO using ProGuard. Just watch out for code that uses reflection. Java 9 will include a less aggressive version of the same thing which performs various link time optimisations like deleting modules (rather than individual methods/fields), statically pre-computing various tables, and converting from JAR into a more optimised (but platform specific) format. That tool can also bundle a JRE in with your app, giving you an "tar xzvf and run" deployment model. It's not a single file, but it makes little difference in practice. The same tool can build DEBs, RPMs, Mac DMGs and Windows EXE/MSI installers with a bundled and stripped JRE too.
    - dikaiosune 10y ago
      I'm a big fan of Capsule, actually. My point was not that Java and the JVM ecosystem are terrible (I quite like them), but rather that there is a spectrum of size and complexity and that Go's static binaries seem to be on the simpler to build side of JARs and on the smaller side of JARs. Also, I don't think there's much of a case to be made that bundling a JRE with your JAR is small, even though the tooling might be simple and it might resolve many deployment issues.
  - prodigal_erik 10y ago
    Putting a jar on your classpath works just like depending on a shared library but with much stronger compatibility guarantees and better chances for optimization.
- jsmthrowaway 10y ago
  You think wrong. It was the default of the compiler for a long time and only requires minimal work now.
rat87 10y ago
Also smaller memory usage.
pjmlp 10y ago
If you have the money, there are lots of commercial JVMs with compilers to native code. There are quite a few open source ones, but they aren't as stable. As always, Language != Implementation.
- fosk 10y ago
  Could you recommend any that you have had experience with?
  - pjmlp 10y ago
    I just know them from Java conferences. Excelsior JET is the most well known one. Oracle actually also supports AOT but only on embedded systems, with the commercial JDK.
  - sievebrain 10y ago
    RoboVM is one that compiles AOT ARM binaries, it's intended for the iPhone but it runs on MacOS too. Avian is a JIT compiling JVM but one which is much smaller than HotSpot. It has a mode where it statically links your JAR into the binary itself, so you get a single self contained executable. With ProGuard and other optimisations like LZMA compression built in, such binaries can be remarkably small. Try their example: https://readytalk.github.io/avian/#-xamples https://readytalk.github.io/avian/#-xamples It's a full blown GUI app that demonstrates the full range of widgets available, is cross platform, and yet is only about 1mb in size.
    - bmaupin 10y ago
      RoboVM can also compile to OS X and Linux: Usually this means iOS and the ARM processor type but RoboVM is also capable of generating code for Mac OS X and Linux running on x86 CPUs. [0] There are several forks of the latest open-source version of RoboVM. This one in particular is targeting desktop/server usage: https://github.com/ashleyj/aura https://github.com/ashleyj/aura See also: https://news.ycombinator.com/item?id=7579737 https://news.ycombinator.com/item?id=7579737 [0] http://docs.robovm.com/advanced-topics/compilation.html http://docs.robovm.com/advanced-topics/compilation.html

danellis 10y ago

That comes with a big memory cost, though. Also huge startup time, so not suitable for command line tools.

pjmlp 10y ago
Just get an AOT compiler, plenty to choose from. Also since Java 8 with tiered compilation, I wouldn't consider a few ms a huge startup time.
catfest 10y ago
I don't think startup time is an issue, and memory is definitely manageable - check out LMAX Disruptor (https://lmax-exchange.github.io/disruptor/ https://lmax-exchange.github.io/disruptor/)
sievebrain 10y ago
Java startup time is ~50msec, which for command line tools is fine.
- kgabis 10y ago
  Unless you run them in a loop, which is not that uncommon.

omginternets 10y ago

>you get the language simplicity And the most complex toolchain imaginable. This is what turns me off to Java, personally, but I think my case is fairly representative.

catfest 10y ago
The toolchain is what's so awesome about Java - moving to a language like Go means you lose so much, it's painful.
- imtringued 10y ago
  Which is why it's mostly developers that previously used dynamic languages. They didn't have sophisticated IDEs.
adrianN 10y ago
Nobody forces you to use a complex toolchain for Java. You can use javac and ed if you like. But Java is sufficiently simple and sufficiently popular for pretty awesome tooling to be available. Refactoring Java code is a breeze because your IDE understands the code perfectly.
discreteevent 10y ago
A text editor, javac and java that's what I used for a few years when I started using it. I wrote a lot of code like that. I don't see why you couldn't?
sievebrain 10y ago
If popular Java toolchains are the most complex you can imagine, I assume you have never encountered autotools, or really any toolchain for a large C++ project. Toolchains normally mean build systems, debuggers, profilers, editors and other things. Java itself doesn't require any build tool at all, you could do it all with a custom shell script. The next step up after that is an IDE like IntelliJ where you press "new project" and just start writing code. The IDE's build system will do it all for you. There is no complexity. But most people want features like dependency management, IDE independence, command line builds, ability to customise the build with extra steps and so on. That's when you upgrade to something like Gradle (or maybe Maven if you like declarative XML). That'll give you dependency resolution with one-line-one-dependency, versioning, automatic downloads, update checking and other useful features. Many IDEs can create a Gradle project for you. When I first encountered Java it seemed the most popular build tool was Maven, which looked very over complex at first due to its poor docs and love of inventing new words, but pretty quickly found that it wasn't so bad in reality. Gradle avoids the custom dictionary and uses a much lighter weight syntax. It's pretty good.

thegenius2000 10y ago

Language simplicity? I disagree, Java is only agreable if you're comfortable with (1) being forced to work in an OOP-only environment and (2) using the JVM. And while you can argue for the upsides of both of these (which I believe are few and far between) they certainly add a great deal of clunky complexity, which many programmers are fleeing to Golang to avoid.

reycharles 10y ago

> you get the language simplicity I remember the Go language specification to be about as long as the table of contents for the Java language specification. On the other hand, Brainfuck is an extremely simple language, too.

masklinn 10y ago
> I remember the Go language specification to be about as long as the table of contents for the Java language specification. I'm not sure where you got that from. On my browser and screen, the JLS8 TOC[0] is 16 pages high which brings me about 20% into the Go language spec[1]. But then again that's a completely inane appeal to emotions: because it's a specification for cross-platform and cross-implementation compatibility (not a user-targeted documentation): * the JLS is exactingly precise, the JLS's "lexical structure" section is about 3 times longer than GoSpec's "Lexical Elements", the JLS's "Execution" section is about 6 times longer than GoSpec's "Program initialization and execution" * the JLS contains entire sections which don't get a mention in GoSpec, like binary compatibility concern, or the language's entire execution model (calling a function gets a page in gospec, it gets 20+ in the JLS) and its multithreaded memory model The JLS is longer because its goal is that you be able to reimplement a Java compiler and runtime just from it, it's Java's entire rulebook. Go's language spec is a much fuzzier document targeted towards language users — much like e.g. Python's language reference — there is no way you can write a clean-slate implementation just from the language spec. [0] https://docs.oracle.com/javase/specs/jls/se8/html/index.html https://docs.oracle.com/javase/specs/jls/se8/html/index.html [1] https://golang.org/ref/spec https://golang.org/ref/spec
- reycharles 10y ago
  You are absolutely right, it's a silly comparison. The Go language spec is indeed vague. I did this comparison a while ago. It wasn't very accurate. The Go spec has probably changed. Unfortunately, it seems they don't keep older specs around(!) If I adjust the font size in the ToC of the JLS I get 23 pages and the Go Spec is 84 pages (27%). Not quite "about the same length", still. I took a compiler course in university where we implemented a compiler for a subset of java 1.3 (I believe), and the next year I was a TA in the compiler course. I got to read the (older) JLS quite a lot. I do find Java to be a more complicated language than Go. This does not mean I find it simpler to write programs in Go (c.f. Brainfuck).

fauigerzigerk 10y ago

Memory usage and as a consequence of that excessive GC pauses. I'm not looking at any JVM language again before they introduce value types in a couple of years (maybe).

mcculley 10y ago
I build soft real time simulation systems in Java. GC pauses haven't been a problem since 1.2 was released around 2000. Memory usage isn't a concern either for big applications, as there's not a lot of overhead in the runtime. There is the fact that one can't embed value types directly in objects, but I don't find that a problem in practice.
- fauigerzigerk 10y ago
  Then your experience is very different from mine and that of many other people who resort to all sorts of off-heap solutions and distributing stuff across multiple VMs. I guess it depends a lot on the specific use case.
  - sievebrain 10y ago
    You can get 10msec pauses or less with heaps >100GB with HotSpot if you tune things well and use the latest GC (G1). If you want no GC pauses at all, ever, well, Go can't do that either. But if you are willing to pay money to Azul, you can buy a JVM that can. It also concurrently compacts the heap, which Go's GC does not. The issue is not Java. The issue is the quality of freely available garbage collectors, which are very good, but not pauseless.
    - fauigerzigerk 10y ago
      >You can get 10msec pauses or less with heaps >100GB with HotSpot if you tune things well and use the latest GC (G1). For what percentile of collections? I'm not wasting my time with incessant GC tuning only to delay that 5 minute stop the world pause for a bit longer. It's still going to hit eventually. For projects that might grow into that sort of heap size I use C++ (with an eye on Rust for the future). You are right that Go is not a panacea for very large memory situations, but you can do a lot more before Go even needs that amount of memory. The point is that languages without value types, such as Java and JavaScript, waste a huge amount of memory and generate a lot more garbage, thereby exacerbating all other related issues, including GC. I have done quite a lot of testing for our workloads. Java memory usage is consistently two to three times higher than that of Go or C++. I'm unwilling to waste our money on that.

eva1984 10y ago

Java itself is, IMHO, quite straightforward. But setup a java toolchain, building, deploying, and a lot of other configuration if some heavy framework is involved, is non-trivial. Gradle is like a must for modern Java application, and mastering itself takes some efforts. Go, when coming to toolchain, it is pretty much battery-included, best-practice-builtin, sometimes even a little forced. Language wise, Java recently has seem a more aggressive adoption of new and modern features, which is quite welcome for me personally, but it is still more LOC comparing to Go. I think Go is the new Python for light to middle complexity web service, with fewer people. Java is more for mature stuff, for larger scale collaboration.

sievebrain 10y ago
A build.gradle file that lists a few dependencies is like maybe 7 or 8 lines of code, which can almost all be cargo culted. You only need to start consulting the Gradle manual once you start doing things like defining custom build tasks or wanting to use custom plugins. Go's toolchain doesn't even bother with versioning. That's like the opposite of batteries-included, forced-best-practices. But of course it will seem simpler than a tool that does handle these basic things. If you want the benefits of Java with a lighter syntax then look at Kotlin.
- vorg 10y ago
  > A build.gradle file that lists a few dependencies is like maybe 7 or 8 lines of code, which can almost all be cargo culted ...and that code is written in Apache Groovy. Strange why they'd bundle a Turing-complete scripting language for their build file DSL when it's only 7 or 8 lines long.
twic 10y ago
> Java [...] is still more LOC comparing to Go My experience is the exact opposite: Go takes more lines to do something than Java. I would say that in large part, this is because the error handling restricts expressions to a rather small size, and then because without streams, collection manipulation has to be written out longhand.