8 ms·

> ...but no one would have adopted it if it weren't. It's a C-like language with GC, that compiles to native code supported by an efficient runtime, and can wo

> ...but no one would have adopted it if it weren't. It's a C-like language with GC, that compiles to native code supported by an efficient runtime, and can work effectively with parallel/concurrent code. In many ways it's Java done right, or a more intuitive (and from certain POVs, preferable) alternative to Haskell and Ocaml. That would seem to be enough to drive adoption.

apta 7y ago
> In many ways it's Java done right Not quite: * no generics * error prone error handling * non tunable GC * null pointers * golang interfaces are messy and can't be used to tag structures * golang time package is garbage and lots more Java today is superior to golang in almost every front.
- grumpydba 7y ago
  Memory usage, compile time, simplicity, readability and deployment story are notable fronts in which go is several miles ahead.
  - apta 7y ago
    Java will use however much memory is assigned to it, since it defaults to throughput performance (though now with G1 and Shenandoah that can also be tuned)[1]. Compilation times are not that different, especially when using incremental compilation. I worked on large projects in both languages, and for any non-trivial code base, the difference isn't that far off. I'd argue that readability is better in Java due to things like non-clutter due to error handling, and the existence of generics. Deployment has been solved for a while now with building shadow jars[1]. [1] Not to mention offerings like: https://quarkus.io/ https://quarkus.io/
    - grumpydba 7y ago
      You mention a lot of workarounds and knobs though. And the excessive use of layers of abstractions in the Java world is scary.
      - apta 7y ago
        Large projects are complex. The JVM is designed to be a platform for developing general purpose software, which is why it provides options for tuning and whatnot. golang only comes with a low latency GC, which basically means you cannot use golang if you're looking for high throughput.
        grumpydba 7y ago
        > golang only comes with a low latency GC, which basically means you cannot use golang if you're looking for high throughput. I you're looking for high throughput you just need to allocate less. Or use unsafe. And it's totally doable.
        apta 7y ago
        So you "only" have to make significant, error prone (by using unsafe) code changes as opposed to tuning a couple of parameters for the GC to account for a different workload? Again, this shows the superiority of the JVM here. And the same approaches can be done in Java (e.g. self-managed off heap allocations), even more-so when they introduce value types.
        grumpydba 7y ago
        Object pools are really easy. Unsafe is only for extreme cases. Some cache libraries use it. You don't have to code it yourself. Yes this is better than relying on the end user/admin to tune things. It is more predictable.
        apta 7y ago
        Managing allocations is way more than just object pooling. The following code in golang allocates "n" on the heap: func main() { n := 1 fmt.Println(n) } Object pooling won't help here. The new GCs on the JVM have very few parameters to tune, I think Shenandoah or ZGC have only two parameters to set up, can't get much simpler.
yjftsjthsd-h 7y ago
Then why did D never take off?
- nonsense1234 7y ago
  For a long time D wasn't open source, didn't work very well on Windows, had a very limited standard library, and had poor IDE support. There's also a large divide in the community around garbage collection vs manual memory management.
- simias 7y ago
  I don't necessarily agree with the parent's point but D managed to fumble early on and never managed to catch up ever since. Around the time it got released (in the early 2000's) I was a C++ coder and I remember being very interested, only to immediately dismiss it as soon as I learned that it wasn't fully open source. I'm sure other devs didn't mind as much as I did but it definitely stunted growth early on. By the time they fixed this "issue" there was a lot of competition in that space and I never bothered looking back.
- deleted 7y ago
  [deleted]
kd0amg 7y ago
Go shot past similar languages because Google's backing got lots of instant attention from people who would never even hear of something like Nim or Clay.
mattnewton 7y ago
I don’t understand the comparison to Haskell or Ocaml; those languages are not C like and have a much different philosophy on the responsibilities of the language and type system.
- 0815test 7y ago
  Haskell is not C like? You can write Haskell with curly brackets and semicolons, just like Go! I rest my case. No, but seriously, you didn't get what I was saying there. The whole reason Go might be of interest is that it is loosely C-like in a way that Haskell and Ocaml are not.
  - deleted 7y ago
    [deleted]
  - mattnewton 7y ago
    That true, and I still don’t get what you are saying here. In my mind, they are different languages which appeal to different developers and fit with different requirements. I don’t see it as an alternative to Haskell any more than any Turing-complete language is technically an alternative.

apta 7y ago

> In many ways it's Java done right Not quite: * no generics * error prone error handling * non tunable GC * null pointers * golang interfaces are messy and can't be used to tag structures * golang time package is garbage and lots more Java today is superior to golang in almost every front.

grumpydba 7y ago
Memory usage, compile time, simplicity, readability and deployment story are notable fronts in which go is several miles ahead.
- apta 7y ago
  Java will use however much memory is assigned to it, since it defaults to throughput performance (though now with G1 and Shenandoah that can also be tuned)[1]. Compilation times are not that different, especially when using incremental compilation. I worked on large projects in both languages, and for any non-trivial code base, the difference isn't that far off. I'd argue that readability is better in Java due to things like non-clutter due to error handling, and the existence of generics. Deployment has been solved for a while now with building shadow jars[1]. [1] Not to mention offerings like: https://quarkus.io/ https://quarkus.io/
  - grumpydba 7y ago
    You mention a lot of workarounds and knobs though. And the excessive use of layers of abstractions in the Java world is scary.
    - apta 7y ago
      Large projects are complex. The JVM is designed to be a platform for developing general purpose software, which is why it provides options for tuning and whatnot. golang only comes with a low latency GC, which basically means you cannot use golang if you're looking for high throughput.
      - grumpydba 7y ago
        > golang only comes with a low latency GC, which basically means you cannot use golang if you're looking for high throughput. I you're looking for high throughput you just need to allocate less. Or use unsafe. And it's totally doable.
        apta 7y ago
        So you "only" have to make significant, error prone (by using unsafe) code changes as opposed to tuning a couple of parameters for the GC to account for a different workload? Again, this shows the superiority of the JVM here. And the same approaches can be done in Java (e.g. self-managed off heap allocations), even more-so when they introduce value types.
        grumpydba 7y ago
        Object pools are really easy. Unsafe is only for extreme cases. Some cache libraries use it. You don't have to code it yourself. Yes this is better than relying on the end user/admin to tune things. It is more predictable.
        apta 7y ago
        Managing allocations is way more than just object pooling. The following code in golang allocates "n" on the heap: func main() { n := 1 fmt.Println(n) } Object pooling won't help here. The new GCs on the JVM have very few parameters to tune, I think Shenandoah or ZGC have only two parameters to set up, can't get much simpler.

yjftsjthsd-h 7y ago

Then why did D never take off?

nonsense1234 7y ago
For a long time D wasn't open source, didn't work very well on Windows, had a very limited standard library, and had poor IDE support. There's also a large divide in the community around garbage collection vs manual memory management.
simias 7y ago
I don't necessarily agree with the parent's point but D managed to fumble early on and never managed to catch up ever since. Around the time it got released (in the early 2000's) I was a C++ coder and I remember being very interested, only to immediately dismiss it as soon as I learned that it wasn't fully open source. I'm sure other devs didn't mind as much as I did but it definitely stunted growth early on. By the time they fixed this "issue" there was a lot of competition in that space and I never bothered looking back.
deleted 7y ago
[deleted]

kd0amg 7y ago

Go shot past similar languages because Google's backing got lots of instant attention from people who would never even hear of something like Nim or Clay.

mattnewton 7y ago

I don’t understand the comparison to Haskell or Ocaml; those languages are not C like and have a much different philosophy on the responsibilities of the language and type system.

0815test 7y ago
Haskell is not C like? You can write Haskell with curly brackets and semicolons, just like Go! I rest my case. No, but seriously, you didn't get what I was saying there. The whole reason Go might be of interest is that it is loosely C-like in a way that Haskell and Ocaml are not.
- deleted 7y ago
  [deleted]
- mattnewton 7y ago
  That true, and I still don’t get what you are saying here. In my mind, they are different languages which appeal to different developers and fit with different requirements. I don’t see it as an alternative to Haskell any more than any Turing-complete language is technically an alternative.