3 ms·

sorry but the scala version is actually pretty pretty dumb. also go is not better than all of these languages. what we learned here, is actually that go is eas

by merb 11y ago

sorry but the scala version is actually pretty pretty dumb. also go is not better than all of these languages. what we learned here, is actually that go is easier since you only have one common way to do this task. go has goroutines, but go doesn't have runnables, futures, actors, completionstages, executioncontexts. GO has GOMAXPROCS and not dispatchers, thread pools, etc.. Also the JVM eve Java only code would actually beat golang in many ways, but thats nothing you should be scared of. Golang is 1 1/2 year old, the JVM lives like 20+ years and they spent numerous times about the GC implementations (they could be even changed so that you could use a better GC for conurrency or for parallelism or for synchronous execution). Go is good for the task it is created. Other languages maybe tend to be more general so that you could do many things and due to their years of knowledge they are actually more optimized than go could be / they could be more optimized than go could be.

otterley 11y ago
> go doesn't have runnables, futures, actors, completionstages, executioncontexts Some of us (most of us, I would contend) who have been successfully programming highly concurrent software without them for 20+ years are totally OK with that.
- pcwalton 11y ago
  > Some of us (most of us, I would contend) who have been successfully programming highly concurrent software without them for 20+ years are totally OK with that. I work on parallel software every day and I would not be OK with having threads and channels as my only tools. I would agree that they're usually the best thing to reach for initially, but it's essential to be able to have low-level control over the scheduling if you want to get good parallel performance out of the hardware. I have workloads that today result in 3x speedups on 4 cores but would become slower than the sequential algorithm on 1 core if I were to rip out the highly-tuned parallel scheduler and replace it with threads and channels. To be fair, though, I'm working on CPU-bound software and if my workload were I/O bound I'd likely have a different outlook on this.
lsllc 11y ago
Actually, Go is at least 6 years old; the original announcement was Oct 30, 2009: https://youtu.be/rKnDgT73v8s https://youtu.be/rKnDgT73v8s
- merb 11y ago
  yeah sorry however I would actually use go version 1 as a reference. everything before was changing just too often, there was go fix however still many changes. also everything before 1.0 wasn't targeted too much about performance. also I can remember how much the template spec changed. thats what I used these days quite heavily. I have a book about go that dates 2011, and I think that was go 0.7 as far as I remember.
  - lsllc 11y ago
    Fair enough; in that case Go 1.0 is just about 4 years old: https://blog.golang.org/go-version-1-is-released https://blog.golang.org/go-version-1-is-released
geodel 11y ago
I am scared that Java takes an order of magnitude more memory than Go with its 20+ years of optimization and all. Java's GC does not appear to be significantly better than Go's one. Also Go's runtime and GC both written in Go, something Java has not been able to do so yet. So Java appears less general purpose to me. Yes Java has humongous number of libraries and frameworks but that is expected of a popular language that is 20+ years old.
- pcwalton 11y ago
  > Java's GC does not appear to be significantly better than Go's one. Java's GC is generational, allowing bump allocation in the nursery. That is a huge advantage.
  - geodel 11y ago
    Considering Go is showing under ~10ms GC pauses. Java's advantage seems theoretical rather than real world. I work in Java at my job and I have not seen such low GC pauses in Java ever. edit: Also considering huge garbage idiomatic Java libraries and user code generates, Generational GC in Java is a basic requirement not a powerful advantage over Go.
    - pcwalton 11y ago
      Bump allocation in the nursery is a huge advantage. There's a reason why fast Go code goes out of its way to avoid allocations (notice that the benchmark tool contains an allocation profiler), and it's because allocations are expensive when you don't have a generational GC. If you do have a generational GC, then allocations are incredibly cheap: just a pointer bump and check. It's like 4 or 5 instructions compared to the dozens in a typical malloc. With that kind of collector, you don't have to spend nearly as much time tuning your program to avoid allocations. This is the reason why Java has been slow to add value types: when you have a bump allocator, they really aren't needed as much (which is not to say they aren't needed at all). In the HotSpot VM, you can tune the GC to get any type of max garbage collection pause you want (-XX:MaxGCPauseMillis). This is basic functionality that any concurrent garbage collector supports. The downside, of course, is that pauses will happen more frequently, reducing throughput. That is why just saying "it's under 10 ms, so it's really fast" is very misleading: when your GC is interruptible, you can of course get any max pause time you want. But the GC may not be able to keep up with your allocation rate, and it may start being invoked too often. That's why you need to not just look at latency, but throughput--something that sound bites won't capture.

by merb 11y ago

otterley 11y ago

> go doesn't have runnables, futures, actors, completionstages, executioncontexts Some of us (most of us, I would contend) who have been successfully programming highly concurrent software without them for 20+ years are totally OK with that.

pcwalton 11y ago
> Some of us (most of us, I would contend) who have been successfully programming highly concurrent software without them for 20+ years are totally OK with that. I work on parallel software every day and I would not be OK with having threads and channels as my only tools. I would agree that they're usually the best thing to reach for initially, but it's essential to be able to have low-level control over the scheduling if you want to get good parallel performance out of the hardware. I have workloads that today result in 3x speedups on 4 cores but would become slower than the sequential algorithm on 1 core if I were to rip out the highly-tuned parallel scheduler and replace it with threads and channels. To be fair, though, I'm working on CPU-bound software and if my workload were I/O bound I'd likely have a different outlook on this.

lsllc 11y ago

Actually, Go is at least 6 years old; the original announcement was Oct 30, 2009: https://youtu.be/rKnDgT73v8s https://youtu.be/rKnDgT73v8s

merb 11y ago
yeah sorry however I would actually use go version 1 as a reference. everything before was changing just too often, there was go fix however still many changes. also everything before 1.0 wasn't targeted too much about performance. also I can remember how much the template spec changed. thats what I used these days quite heavily. I have a book about go that dates 2011, and I think that was go 0.7 as far as I remember.
- lsllc 11y ago
  Fair enough; in that case Go 1.0 is just about 4 years old: https://blog.golang.org/go-version-1-is-released https://blog.golang.org/go-version-1-is-released

geodel 11y ago

I am scared that Java takes an order of magnitude more memory than Go with its 20+ years of optimization and all. Java's GC does not appear to be significantly better than Go's one. Also Go's runtime and GC both written in Go, something Java has not been able to do so yet. So Java appears less general purpose to me. Yes Java has humongous number of libraries and frameworks but that is expected of a popular language that is 20+ years old.

pcwalton 11y ago
> Java's GC does not appear to be significantly better than Go's one. Java's GC is generational, allowing bump allocation in the nursery. That is a huge advantage.
- geodel 11y ago
  Considering Go is showing under ~10ms GC pauses. Java's advantage seems theoretical rather than real world. I work in Java at my job and I have not seen such low GC pauses in Java ever. edit: Also considering huge garbage idiomatic Java libraries and user code generates, Generational GC in Java is a basic requirement not a powerful advantage over Go.
  - pcwalton 11y ago
    Bump allocation in the nursery is a huge advantage. There's a reason why fast Go code goes out of its way to avoid allocations (notice that the benchmark tool contains an allocation profiler), and it's because allocations are expensive when you don't have a generational GC. If you do have a generational GC, then allocations are incredibly cheap: just a pointer bump and check. It's like 4 or 5 instructions compared to the dozens in a typical malloc. With that kind of collector, you don't have to spend nearly as much time tuning your program to avoid allocations. This is the reason why Java has been slow to add value types: when you have a bump allocator, they really aren't needed as much (which is not to say they aren't needed at all). In the HotSpot VM, you can tune the GC to get any type of max garbage collection pause you want (-XX:MaxGCPauseMillis). This is basic functionality that any concurrent garbage collector supports. The downside, of course, is that pauses will happen more frequently, reducing throughput. That is why just saying "it's under 10 ms, so it's really fast" is very misleading: when your GC is interruptible, you can of course get any max pause time you want. But the GC may not be able to keep up with your allocation rate, and it may start being invoked too often. That's why you need to not just look at latency, but throughput--something that sound bites won't capture.