5 ms·

What do you mean by "better than Go for industry purposes"? I don't understand what "industry purposes" means and in what aspects Java is better than Go in you

What do you mean by "better than Go for industry purposes"? I don't understand what "industry purposes" means and in what aspects Java is better than Go in your opinion (I can think of some myself, but I'm interested in your perspective).

kyrra 7mo ago
Not the GP, but for really large code bases, Go is missing a few features that I've noticed: 1) No immutable types. My work team is a huge user of immutable data stuctures in Java to make sure data passed around to other teams isn't changed. Go doesn't really have a good way to do this. 2) Refactoring can be really annoying (or at least really noisy) because of public/private being defined by capitalization of method/field names. 3) Error handling isn't great. I love Go's errors being just normal values, but the `error` interface is awkward when trying to figure out what kind of errors can be thrown without having in-depth knowledge of the kinds of errors that can be returned. We regularly need to make different decisions depending on the kind of error returned. Knowing which errors can be returned in Go is not defined by the method being called (only in comments).
- oefrha 7mo ago
  > No immutable types (in Go) The typical answer is opaque types with only readonly methods exported. Not elegant, but it’s there. I guess it’s arguably not a “good way” to do it.
  - joeblubaugh 7mo ago
    In fact it was “the Java way” for many years and “useless getters” was always a big complaint about Java.
    - oefrha 7mo ago
      Hey it's better in Go. In Java it's getFoo(). In Go it's just Foo(). Saves three bytes, and three keystrokes if you program by hand and don't autocomplete!
    - gf000 7mo ago
      I do agree to a certain degree, but with getters/setters you could properly hide/set to read-only fields.
- wbl 7mo ago
  I think you want sum types which admittedly Go doesn't have in a matchable way. However complex error recovery is an anti pattern for Go.
  - gf000 7mo ago
    > However complex error recovery is an anti pattern for Go. Bit of snark from my side, but that's exactly what makes it less good of a fit for "industry purposes". Go's error handling is possibly the worst out of any "modern" language, it basically copied C's errno which is not something you should have ever done.
    - wbl 7mo ago
      Why exactly do you have complex error analysis happening above a component that has the error? That's anti modular.
      - gf000 7mo ago
        Because almost my definition you can't handle errors in the component, otherwise you would have a conditional and not an error. E.g. if I do some IO like "make a copy of these files" and get an error/exception, it's only the caller or maybe even that caller's caller that can properly deal with this condition (e.g. to decide that we will skip the erroneous files or retry).
    - peterashford 7mo ago
      This was exactly my experience when I first read about Go. I was so excited until I found they were repeating the c experience of check every bloody return value separately. That was the worst feature of c - why copy it
- dinkumthinkum 7mo ago
  This is not a dig at Go and this will be controversial but I so struggle to see what problem or area Go is solving outside of CSP. It's a nice language it just feels far too simple and I am really convinced of it as a systems language over Modern C++ and if you want that alternative then we have our rather oxidized friend that seems to more substantial. That's just my take.
  - peterashford 7mo ago
    I code Go at work. I've been using it for just over 3 years. I really like it. I prefer Java, but Go is a much more ergonomic C and its a very pragmatic language. Except for the *%!@ error system, that can burn in hell.
nradov 7mo ago
Ya, that seems to be a misunderstanding. "Industry purposes" covers a huge range of stuff. Go is pretty good for systems programming where Java isn't really an option due to the fundamental limits imposed by garbage collection and lack of pointers. Java is pretty good for higher-level application development where occasional GC pauses are tolerable (the GC pauses are rare and fast now, but they still rule out using Java for certain purposes).
- zokier 7mo ago
  Go has gc too and arguably worse one than Java
  - zadikian 7mo ago
    Yeah but I do like not having to give Go several flags to do something reasonable with its memory
    - oblio 7mo ago
      That's a very shallow argument.
      - zadikian 7mo ago
        If it were shallow, it'd be easy for them to fix
        oblio 7mo ago
        Backwards compatibility, every vim and emacs and bash enthusiast should know about it. It's easy for the USER to fix, since there are flags available. In the day of LLMs it's also easy to find out about those flags and what they do. And if it's so important, testing shouldn't be supremely hard, either.
        zadikian 7mo ago
zadikian 7mo ago
Exceptions
owlstuffing 7mo ago
Go can't compete with Java bc it's not in the same category as Java. - Java is a high-level, multi-paradigm programming language - Go is designed as a systems language to supersede C projects at Google Now Go identifies as a general purpose language that competes with Java? It's a free country, I guess.
- gf000 7mo ago
  How is Go not high level? What makes it "systems" language? That's just marketing. It is a language with a fat runtime, running a garbage collector. You just burn it into the binary and call it a day.
  - Tostino 7mo ago
    (just like modern Java can burn its runtime / GC into the binary)
    - Mawr 7mo ago
      No, not just like. You're downplaying significant differences between the two that do in fact matter. So much so in fact, that you're just wrong. Stop spreading misinformation.
      - gf000 7mo ago
        GraalVM indeed does a lot more than Go, it's a full optimizing compiler while Go does very little optimiations. But burning a JVM next to a jar file is not hard at all, one could make something like cosmopolitan.
- zadikian 7mo ago
  Go use cases overlap the most with Java. I think the reputation you mentioned comes from Google using a lot of C++ for high-level things others would likely do in Java, so they see Go as a replacement for C++ in some areas. (assuming you meant C++ not C)
owlstuffing 7mo ago
"industry purposes" likely equates to "enterprise software development." And that assertion is 100% correct.

kyrra 7mo ago

Not the GP, but for really large code bases, Go is missing a few features that I've noticed: 1) No immutable types. My work team is a huge user of immutable data stuctures in Java to make sure data passed around to other teams isn't changed. Go doesn't really have a good way to do this. 2) Refactoring can be really annoying (or at least really noisy) because of public/private being defined by capitalization of method/field names. 3) Error handling isn't great. I love Go's errors being just normal values, but the `error` interface is awkward when trying to figure out what kind of errors can be thrown without having in-depth knowledge of the kinds of errors that can be returned. We regularly need to make different decisions depending on the kind of error returned. Knowing which errors can be returned in Go is not defined by the method being called (only in comments).

oefrha 7mo ago
> No immutable types (in Go) The typical answer is opaque types with only readonly methods exported. Not elegant, but it’s there. I guess it’s arguably not a “good way” to do it.
- joeblubaugh 7mo ago
  In fact it was “the Java way” for many years and “useless getters” was always a big complaint about Java.
  - oefrha 7mo ago
    Hey it's better in Go. In Java it's getFoo(). In Go it's just Foo(). Saves three bytes, and three keystrokes if you program by hand and don't autocomplete!
  - gf000 7mo ago
    I do agree to a certain degree, but with getters/setters you could properly hide/set to read-only fields.
wbl 7mo ago
I think you want sum types which admittedly Go doesn't have in a matchable way. However complex error recovery is an anti pattern for Go.
- gf000 7mo ago
  > However complex error recovery is an anti pattern for Go. Bit of snark from my side, but that's exactly what makes it less good of a fit for "industry purposes". Go's error handling is possibly the worst out of any "modern" language, it basically copied C's errno which is not something you should have ever done.
  - wbl 7mo ago
    Why exactly do you have complex error analysis happening above a component that has the error? That's anti modular.
    - gf000 7mo ago
      Because almost my definition you can't handle errors in the component, otherwise you would have a conditional and not an error. E.g. if I do some IO like "make a copy of these files" and get an error/exception, it's only the caller or maybe even that caller's caller that can properly deal with this condition (e.g. to decide that we will skip the erroneous files or retry).
  - peterashford 7mo ago
    This was exactly my experience when I first read about Go. I was so excited until I found they were repeating the c experience of check every bloody return value separately. That was the worst feature of c - why copy it
dinkumthinkum 7mo ago
This is not a dig at Go and this will be controversial but I so struggle to see what problem or area Go is solving outside of CSP. It's a nice language it just feels far too simple and I am really convinced of it as a systems language over Modern C++ and if you want that alternative then we have our rather oxidized friend that seems to more substantial. That's just my take.
- peterashford 7mo ago
  I code Go at work. I've been using it for just over 3 years. I really like it. I prefer Java, but Go is a much more ergonomic C and its a very pragmatic language. Except for the *%!@ error system, that can burn in hell.

nradov 7mo ago

Ya, that seems to be a misunderstanding. "Industry purposes" covers a huge range of stuff. Go is pretty good for systems programming where Java isn't really an option due to the fundamental limits imposed by garbage collection and lack of pointers. Java is pretty good for higher-level application development where occasional GC pauses are tolerable (the GC pauses are rare and fast now, but they still rule out using Java for certain purposes).

zokier 7mo ago
Go has gc too and arguably worse one than Java
- zadikian 7mo ago
  Yeah but I do like not having to give Go several flags to do something reasonable with its memory
  - oblio 7mo ago
    That's a very shallow argument.
    - zadikian 7mo ago
      If it were shallow, it'd be easy for them to fix
      - oblio 7mo ago
        Backwards compatibility, every vim and emacs and bash enthusiast should know about it. It's easy for the USER to fix, since there are flags available. In the day of LLMs it's also easy to find out about those flags and what they do. And if it's so important, testing shouldn't be supremely hard, either.
        zadikian 7mo ago

zadikian 7mo ago

Exceptions

owlstuffing 7mo ago

Go can't compete with Java bc it's not in the same category as Java. - Java is a high-level, multi-paradigm programming language - Go is designed as a systems language to supersede C projects at Google Now Go identifies as a general purpose language that competes with Java? It's a free country, I guess.

gf000 7mo ago
How is Go not high level? What makes it "systems" language? That's just marketing. It is a language with a fat runtime, running a garbage collector. You just burn it into the binary and call it a day.
- Tostino 7mo ago
  (just like modern Java can burn its runtime / GC into the binary)
  - Mawr 7mo ago
    No, not just like. You're downplaying significant differences between the two that do in fact matter. So much so in fact, that you're just wrong. Stop spreading misinformation.
    - gf000 7mo ago
      GraalVM indeed does a lot more than Go, it's a full optimizing compiler while Go does very little optimiations. But burning a JVM next to a jar file is not hard at all, one could make something like cosmopolitan.
zadikian 7mo ago
Go use cases overlap the most with Java. I think the reputation you mentioned comes from Google using a lot of C++ for high-level things others would likely do in Java, so they see Go as a replacement for C++ in some areas. (assuming you meant C++ not C)

owlstuffing 7mo ago

"industry purposes" likely equates to "enterprise software development." And that assertion is 100% correct.