4 ms·

In my experience, Go is a lot more attractive as an upgrade from Ruby or Python. It's a very steep downgrade from Java on all points imaginable: type system, ex

In my experience, Go is a lot more attractive as an upgrade from Ruby or Python. It's a very steep downgrade from Java on all points imaginable: type system, exceptions, genericity, garbage collector and runtime, tooling, IDE's, etc...

nostrademons 11y ago
It's an upgrade in terms of compile times, deployment simplicity, conciseness, concurrency, etc. Some people care about such things.
- threeseed 11y ago
  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.
  - caoilte 11y ago
    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.
    - Jweb_Guru 11y ago
      > 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.
  - woah 11y ago
    Some people like things that are minimal and good enough. Also, there is a huge swath of engineers who just really dislike writing Java.
  - ascendantlogic 11y ago
    "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.
    - nkozyra 11y ago
      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 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.
      - igouy 11y ago
        Keep in mind Go 1.5 has not been released yet :-)
      - TheDong 11y ago
        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 https://talks.golang.org/2015/state-of-go-may.slide#11
      - pcwalton 11y ago
        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.
        igouy 11y ago
        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 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-conclusions.html http://benchmarksgame.alioth.debian.org/dont-jump-to-conclus...
  - Thetawaves 11y ago
    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.
- rlonstein 11y ago
  > It's an upgrade in terms of compile times, deployment simplicity, conciseness, > concurrency, etc. Some people care about such things. I remember the days of going for coffee while the compiler chugged away but I wonder what compiles people do on a regular basis that take such time? I just rebuilt SBCL here on a mid-2012 MBP and it took less than 6 wallclock minutes in the background including download and whatever else I was doing: real 5m12.752s user 4m33.393s sys 0m27.579s I personally use D when possible, but waiting on compiles is usually secondary to the amount of time I spend thinking or exploring.
0xdeadbeefbabe 11y ago
> IDE's Lack of an IDE is a feature not a bug. Edit: or it is a symptom of a feature. No one has written one yet because they are happy with what they have. > tooling Do you mean you need an IDE that speaks the language to write anything efficiently? Do you mean your first day on the job is spent setting up tools? Wrong philosophy in my opinion; I could imagine something better.
- chc 11y ago
  Having tools that can spot errors early, help you track them down quickly and help you comprehend, organize and refactor your code can be very useful with a large codebase, and I don't think it's fair to characterize that as "you need an IDE that speaks the language in order to write anything efficiently."
  - neoyagami 11y ago
    Like gosublime?
    - chc 11y ago
      Yes, Gosublime is a good example of how tooling can be helpful, though from what I can tell it is somewhat less helpful than what you'd expect in a decent IDE (e.g. no refactoring support, the interface is mainly dropdowns, weak support for finding definitions and usages).
      - NateDad 11y ago
        Really, all I need is gofmt on save, and even that is mostly because I've gotten so used to it that I drop ugly unformatted dreck into my editor and let gofmt clean it up. I worked full time for year without go to definition, mostly because full text search is almost as good most of the time, due to how regular formatted go code is. I don't really use anything else, mostly because I don't need anything else and I have better things to do than install editor plugins.

nostrademons 11y ago

It's an upgrade in terms of compile times, deployment simplicity, conciseness, concurrency, etc. Some people care about such things.

threeseed 11y ago
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.
- caoilte 11y ago
  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.
  - Jweb_Guru 11y ago
    > 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.
- woah 11y ago
  Some people like things that are minimal and good enough. Also, there is a huge swath of engineers who just really dislike writing Java.
- ascendantlogic 11y ago
  "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.
  - nkozyra 11y ago
    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 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.
    - igouy 11y ago
      Keep in mind Go 1.5 has not been released yet :-)
    - TheDong 11y ago
      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 https://talks.golang.org/2015/state-of-go-may.slide#11
    - pcwalton 11y ago
      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.
      - igouy 11y ago
        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 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-conclusions.html http://benchmarksgame.alioth.debian.org/dont-jump-to-conclus...
- Thetawaves 11y ago
  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.
rlonstein 11y ago
> It's an upgrade in terms of compile times, deployment simplicity, conciseness, > concurrency, etc. Some people care about such things. I remember the days of going for coffee while the compiler chugged away but I wonder what compiles people do on a regular basis that take such time? I just rebuilt SBCL here on a mid-2012 MBP and it took less than 6 wallclock minutes in the background including download and whatever else I was doing: real 5m12.752s user 4m33.393s sys 0m27.579s I personally use D when possible, but waiting on compiles is usually secondary to the amount of time I spend thinking or exploring.

0xdeadbeefbabe 11y ago

> IDE's Lack of an IDE is a feature not a bug. Edit: or it is a symptom of a feature. No one has written one yet because they are happy with what they have. > tooling Do you mean you need an IDE that speaks the language to write anything efficiently? Do you mean your first day on the job is spent setting up tools? Wrong philosophy in my opinion; I could imagine something better.

chc 11y ago
Having tools that can spot errors early, help you track them down quickly and help you comprehend, organize and refactor your code can be very useful with a large codebase, and I don't think it's fair to characterize that as "you need an IDE that speaks the language in order to write anything efficiently."
- neoyagami 11y ago
  Like gosublime?
  - chc 11y ago
    Yes, Gosublime is a good example of how tooling can be helpful, though from what I can tell it is somewhat less helpful than what you'd expect in a decent IDE (e.g. no refactoring support, the interface is mainly dropdowns, weak support for finding definitions and usages).
    - NateDad 11y ago
      Really, all I need is gofmt on save, and even that is mostly because I've gotten so used to it that I drop ugly unformatted dreck into my editor and let gofmt clean it up. I worked full time for year without go to definition, mostly because full text search is almost as good most of the time, due to how regular formatted go code is. I don't really use anything else, mostly because I don't need anything else and I have better things to do than install editor plugins.