5 ms·

If you think there's some virtue in writing verbose and inexpressive imperative code, what does Go provide in that department that you couldn't have got from Ja

by leoc 5y ago

If you think there's some virtue in writing verbose and inexpressive imperative code, what does Go provide in that department that you couldn't have got from Java 1.44?

ignoramous 5y ago
Well, at some level you could say Go (pre 1.18) is Java 1.44 but with speed as a differentiator. Development speed, build speed, deploy speed, and runtime speed. If Russ Cox ever proposes to rename Go to JavaScript, I guess no one would complain. ;)
Zababa 5y ago
Not having to wrap your imperative code in classes is a big plus.
jerf 5y ago
I have often thought that if you could travel back in time and make Java's interfaces work like Go, there would be no Go today. The first-order effects of that change may not seem like much, but the second-order effects of that change is profound. In Java, interfaces must temporally precede their implementations; in Go they don't have to. This turns out to be huge in practice. It turns out that huge swathes of all that boilerplate and frameworkitis that Java is so well known for are just trying to get around the consequences of that mistake, because all the interface-based structure has to be laid down in advance. It isn't the only difference between the two, but I think it would have consumed enough of the oxygen of the niche Go is currently in that Go might never have been born. In practice, I find Go to be just slightly harder than working with dynamically typed languages, rather than a huge step, and the benefits I get in return make me prefer it for almost any task above 200-ish lines. I definitely can not say the same about Java, because of this difference and the second-order effects it has on the entire ecosystem. It is still completely practical to create a production-level Go project by just cracking open a text editor and typing "package main" into your editor and typing away. I get the impression most people would not consider that a practical way to start a production-level Java project.
- kaba0 5y ago
  Java’s nominal typing is both better and worse at the same time - but go is not novel in that area, plenty of similar languages existed before as well, so I don’t think having it contributed to go’s success. As for your last paragraph, I feel like we often mean something different between a production-level go and java project. Non-IDE java development is entirely possible, but I think a prod project usually means something much larger than it does in case of go.
  - jerf 5y ago
    "plenty of similar languages existed before as well, so I don’t think having it contributed to go’s success." I struggle to think of one that has risen to the heights Go has risen. I'm a computer language polyglot and a bit of a language tourist, though not as much as some people. There's a huge churn of features out there in some language somewhere, that has never manifested in any top-level language like C++ or Java. (For instance, array-based programming has been experimented with quite a bit, but has never been in a top-grade language. The closest that I know of is NumPy.) Whether Go is a top-level language or not at this point is a matter of legitimate debate (depends a lot on your exact definition), but it's certainly knocking on it. The closest I can name are things like Python, but there is a fundamental difference between run-time duck typing and compile-time interface conformance, although they're certainly related.
    - kaba0 5y ago
      Half-telling, half-asking: isn’t type-scripts structural typing the same as Go’s, but overall much more powerful?
      - jerf 5y ago
        TypeScript hasn't risen to the level of Go. If you live in the JS world that may not be obvious, but in the general landscape it's not as prominent. A lot of people make a lot of fuss over how fast the programming world moves, but I'm a bit of a contrarian on that. There's a huge amount of churn at the very small scale, but when you get to that top-level set of languages, we're actually very conservative. For pete's sake, C is still a top-level language in 2021! It's finally on its way down, but it's got a long way to go to fall out of that criterion, unfortunately. This is why I didn't even necessarily label Go as a "top-level" language. It's only 12 years old, after. It's a whippersnapper of a top-level langauge. 25 years old makes for a young top-level language!
initplus 5y ago
Go is constantly being improved and refined compared to Java 1.44, there is a strong community of third party packages, you aren't shoehorned into the OOP box by basic language design, you get green threads in the form of goroutines while in Java land you are dealing with native threads & the issues they involve (curiously just learned Java <1.3 actually did use green threads, I suppose they were a casualty in the efforts to improve performance), the Go stdlib is much leaner but simultaneously much more useful compared to the Java 1.44 equivalent (even latest Java stdlib is missing basics like JSON!), date/time handling is sane compared to pre-Java 8 equivalent, etc. etc.
- kaba0 5y ago
  Comparing a moving thing to a static one is quite meaningless, but regarding third-party packages the JVM is parallel only to the python and node ecosystems.
- azth 5y ago
  Java is getting green threads by means of Project Loom, and value types by means of Project Valhalla. Not to mention it has sum types and pattern matching, something not available in golang. golang doesn't even have proper enums, quite astounding really.
Andys 5y ago
It is lighter and faster and requires no runtime.
- kaba0 5y ago
  Than Java 1.14? Yes. Lighter is true of current Javas as well, but faster is dependent on the program. Go can often prevent garbage from being generated in the first place, but when creating garbage is a must, Java will happily handle heaps up to a terabyte in size, and its GCs are simply the state of the art. Also, Go most definitely has a runtime, what runs the GC otherwise?
  - Andys 5y ago
    But its also faster to compile and use as a developer. And by runtime I mean there's no JVM. If you're used to Java you should probably just stick with it, but using Go is a huge relief to me.
    - jhgb 5y ago
      > And by runtime I mean there's no JVM That's an awfully restricted definition of "runtime": https://golang.org/src/runtime/ https://golang.org/src/runtime/
grey-area 5y ago
Epic troll, but there is life outside The Kingdom of Nouns.

by leoc 5y ago

If you think there's some virtue in writing verbose and inexpressive imperative code, what does Go provide in that department that you couldn't have got from Java 1.44?

ignoramous 5y ago

Well, at some level you could say Go (pre 1.18) is Java 1.44 but with speed as a differentiator. Development speed, build speed, deploy speed, and runtime speed. If Russ Cox ever proposes to rename Go to JavaScript, I guess no one would complain. ;)

Zababa 5y ago

Not having to wrap your imperative code in classes is a big plus.

jerf 5y ago

I have often thought that if you could travel back in time and make Java's interfaces work like Go, there would be no Go today. The first-order effects of that change may not seem like much, but the second-order effects of that change is profound. In Java, interfaces must temporally precede their implementations; in Go they don't have to. This turns out to be huge in practice. It turns out that huge swathes of all that boilerplate and frameworkitis that Java is so well known for are just trying to get around the consequences of that mistake, because all the interface-based structure has to be laid down in advance. It isn't the only difference between the two, but I think it would have consumed enough of the oxygen of the niche Go is currently in that Go might never have been born. In practice, I find Go to be just slightly harder than working with dynamically typed languages, rather than a huge step, and the benefits I get in return make me prefer it for almost any task above 200-ish lines. I definitely can not say the same about Java, because of this difference and the second-order effects it has on the entire ecosystem. It is still completely practical to create a production-level Go project by just cracking open a text editor and typing "package main" into your editor and typing away. I get the impression most people would not consider that a practical way to start a production-level Java project.

kaba0 5y ago
Java’s nominal typing is both better and worse at the same time - but go is not novel in that area, plenty of similar languages existed before as well, so I don’t think having it contributed to go’s success. As for your last paragraph, I feel like we often mean something different between a production-level go and java project. Non-IDE java development is entirely possible, but I think a prod project usually means something much larger than it does in case of go.
- jerf 5y ago
  "plenty of similar languages existed before as well, so I don’t think having it contributed to go’s success." I struggle to think of one that has risen to the heights Go has risen. I'm a computer language polyglot and a bit of a language tourist, though not as much as some people. There's a huge churn of features out there in some language somewhere, that has never manifested in any top-level language like C++ or Java. (For instance, array-based programming has been experimented with quite a bit, but has never been in a top-grade language. The closest that I know of is NumPy.) Whether Go is a top-level language or not at this point is a matter of legitimate debate (depends a lot on your exact definition), but it's certainly knocking on it. The closest I can name are things like Python, but there is a fundamental difference between run-time duck typing and compile-time interface conformance, although they're certainly related.
  - kaba0 5y ago
    Half-telling, half-asking: isn’t type-scripts structural typing the same as Go’s, but overall much more powerful?
    - jerf 5y ago
      TypeScript hasn't risen to the level of Go. If you live in the JS world that may not be obvious, but in the general landscape it's not as prominent. A lot of people make a lot of fuss over how fast the programming world moves, but I'm a bit of a contrarian on that. There's a huge amount of churn at the very small scale, but when you get to that top-level set of languages, we're actually very conservative. For pete's sake, C is still a top-level language in 2021! It's finally on its way down, but it's got a long way to go to fall out of that criterion, unfortunately. This is why I didn't even necessarily label Go as a "top-level" language. It's only 12 years old, after. It's a whippersnapper of a top-level langauge. 25 years old makes for a young top-level language!

initplus 5y ago

Go is constantly being improved and refined compared to Java 1.44, there is a strong community of third party packages, you aren't shoehorned into the OOP box by basic language design, you get green threads in the form of goroutines while in Java land you are dealing with native threads & the issues they involve (curiously just learned Java <1.3 actually did use green threads, I suppose they were a casualty in the efforts to improve performance), the Go stdlib is much leaner but simultaneously much more useful compared to the Java 1.44 equivalent (even latest Java stdlib is missing basics like JSON!), date/time handling is sane compared to pre-Java 8 equivalent, etc. etc.

kaba0 5y ago
Comparing a moving thing to a static one is quite meaningless, but regarding third-party packages the JVM is parallel only to the python and node ecosystems.
azth 5y ago
Java is getting green threads by means of Project Loom, and value types by means of Project Valhalla. Not to mention it has sum types and pattern matching, something not available in golang. golang doesn't even have proper enums, quite astounding really.

Andys 5y ago

It is lighter and faster and requires no runtime.

kaba0 5y ago
Than Java 1.14? Yes. Lighter is true of current Javas as well, but faster is dependent on the program. Go can often prevent garbage from being generated in the first place, but when creating garbage is a must, Java will happily handle heaps up to a terabyte in size, and its GCs are simply the state of the art. Also, Go most definitely has a runtime, what runs the GC otherwise?
- Andys 5y ago
  But its also faster to compile and use as a developer. And by runtime I mean there's no JVM. If you're used to Java you should probably just stick with it, but using Go is a huge relief to me.
  - jhgb 5y ago
    > And by runtime I mean there's no JVM That's an awfully restricted definition of "runtime": https://golang.org/src/runtime/ https://golang.org/src/runtime/

grey-area 5y ago

Epic troll, but there is life outside The Kingdom of Nouns.