5 ms·

> once you want to go venture outside the safety of the walled garden you can't. The language is specifically designed to keep you as safe as possible. > Bad f

> once you want to go venture outside the safety of the walled garden you can't. The language is specifically designed to keep you as safe as possible. > Bad for the motivated engineer. Sounds to me like it's really just bad for the engineer who wants to show off how smart they are through the overcomplicated custom abstractions they build. Condescending response to condescending comment aside, I understand that those custom abstractions can occasionally be great and have their place, but in practice their value usually starts reversing (yes, reversing, not diminishing) once you need to onboard many engineers frequently (junior or senior alike), which is the case for a big part of tech projects (think big tech, high growth startups, but also open source projects where you want first-time contributors to be able to dive in and solve their issue quickly). And I'm saying this as a motivated engineer who loves playing with various languages but uses Go for most serious things.

c_crank 3y ago
For serious work, Java has a bigger list of features, both on the primitive side and the abstract, that let you handle a lot more use cases than Go simply because Go doesn't have the tools for them. So long as you stay away from Spring Boot and Hibernate, Java doesn't have to be all about BeanFactories. (Funny aside - somehow, Google managed to turn Rust into abstraction hell: https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/src/factory/factory_store_providers/src/main.rs https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/s...)
- bborud 3y ago
  But do you really need those features? Or is it just force of habit? Learning how to express oneself consistently and with no more fluff than is strictly needed is much harder than people think. I admire people who can solve complex problems by simple means. I'm not terribly impressed by people whose obsessions drive them to write code with low readability. What features does Java have, and Go lack, which represent a real problem? With emphasis on the word "real".
  - c_crank 3y ago
    Being able to tune the JVM properties for GC lets you build a reliable RTOS in Java. Checked exceptions offer stronger guarantees of error handling. Generics (something they did add to Go after years) let you build reusable methods without relying on a ton of boilerplate. None of these features cause the indigestibility of the bloated Java frameworks.
    - bborud 3y ago
      I've written quite a bit of software that has to deliver consistent latency and low jitter in Java and that isn't easy to do. It usually comes with big limitations as to what you can do. It is not just a matter of "tuning" the GC properties. It takes a lot more than that. Java is no more suited for realtime applications than Go. I work a bit on industrial realtime systems that actually do make certain guarantees, and neither the JVM nor the Go runtime are anywhere near anything you would want to touch with a ten foot pole for those kinds of applications. And if by RTOS you mean "embedded" then no, Java isn't suitable for that either since the runtime is huge and it typically needs a bit of RAM headroom to work properly. Checked exceptions only guarantee that someone will have to write code that catches those exceptions. It does not come with any guarantee that they will do anything meaningful with them. You still have to make sure that errors are handled by having code review practices that ensure error handling. It is no more a guarantee that a checked exception will be handled properly than it is a certainty that errors returned from function calls in Go will be heeded. This is engineering reality vs academic fantasy. I kind of agree on generics although, as you point out, Go has generics now. That being said, when sensibly applied, you will spend more time using generic types (like collection types etc) than creating them. Generics is something one typically wants to use sparingly since writing generic code is a lot harder than people like to think. I've seen a few projects where the code ended up being extremely hard to reason about because someone went overboard with generics in the design. I don't know yet if Go's approach to generics is good. I haven't used it enough (I don't need it that often), and it doesn't exactly seem like people are going overboard using it. Yet. This is also the first time I've had someone make the argument that Go has more boilerplate than Java.
      - 3y ago
zer8k 3y ago
I think my problem really comes down to the fact experimentation with Go is fundamentally impossible. It's like trying to experiment with another highly opinionated framework. It's usefulness for producing something that works well quickly is great. The second you want to take some time to explore it simply punches you in the face and sends you to the back of the line. In some sense, I guess, Go just offends me.
- cube2222 3y ago
  Experiment with what, explore what? Your comment is very general, and doesn't make much sense - Go is just fine for prototyping. If you mean PL research and being able to experiment with custom methods of abstraction and DSLs then yes, indeed, there's not much to do. Which, as I mentioned above, is a feature in most cases.
  - zer8k 3y ago
    I got downvoted because I guess "experiment" was too loose of a term. Indeed, I mean being able to modify the system to suit you. Go, instead, is a system that molds you in it's image. Which is why I believe it's the next iteration of Java and not something like C or C++. It's just simply not "open" enough to create a novelty that enhances it in a way that Google approves of.

c_crank 3y ago

For serious work, Java has a bigger list of features, both on the primitive side and the abstract, that let you handle a lot more use cases than Go simply because Go doesn't have the tools for them. So long as you stay away from Spring Boot and Hibernate, Java doesn't have to be all about BeanFactories. (Funny aside - somehow, Google managed to turn Rust into abstraction hell: https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/src/factory/factory_store_providers/src/main.rs https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/s...)

bborud 3y ago
But do you really need those features? Or is it just force of habit? Learning how to express oneself consistently and with no more fluff than is strictly needed is much harder than people think. I admire people who can solve complex problems by simple means. I'm not terribly impressed by people whose obsessions drive them to write code with low readability. What features does Java have, and Go lack, which represent a real problem? With emphasis on the word "real".
- c_crank 3y ago
  Being able to tune the JVM properties for GC lets you build a reliable RTOS in Java. Checked exceptions offer stronger guarantees of error handling. Generics (something they did add to Go after years) let you build reusable methods without relying on a ton of boilerplate. None of these features cause the indigestibility of the bloated Java frameworks.
  - bborud 3y ago
    I've written quite a bit of software that has to deliver consistent latency and low jitter in Java and that isn't easy to do. It usually comes with big limitations as to what you can do. It is not just a matter of "tuning" the GC properties. It takes a lot more than that. Java is no more suited for realtime applications than Go. I work a bit on industrial realtime systems that actually do make certain guarantees, and neither the JVM nor the Go runtime are anywhere near anything you would want to touch with a ten foot pole for those kinds of applications. And if by RTOS you mean "embedded" then no, Java isn't suitable for that either since the runtime is huge and it typically needs a bit of RAM headroom to work properly. Checked exceptions only guarantee that someone will have to write code that catches those exceptions. It does not come with any guarantee that they will do anything meaningful with them. You still have to make sure that errors are handled by having code review practices that ensure error handling. It is no more a guarantee that a checked exception will be handled properly than it is a certainty that errors returned from function calls in Go will be heeded. This is engineering reality vs academic fantasy. I kind of agree on generics although, as you point out, Go has generics now. That being said, when sensibly applied, you will spend more time using generic types (like collection types etc) than creating them. Generics is something one typically wants to use sparingly since writing generic code is a lot harder than people like to think. I've seen a few projects where the code ended up being extremely hard to reason about because someone went overboard with generics in the design. I don't know yet if Go's approach to generics is good. I haven't used it enough (I don't need it that often), and it doesn't exactly seem like people are going overboard using it. Yet. This is also the first time I've had someone make the argument that Go has more boilerplate than Java.
    - 3y ago

zer8k 3y ago

I think my problem really comes down to the fact experimentation with Go is fundamentally impossible. It's like trying to experiment with another highly opinionated framework. It's usefulness for producing something that works well quickly is great. The second you want to take some time to explore it simply punches you in the face and sends you to the back of the line. In some sense, I guess, Go just offends me.

cube2222 3y ago
Experiment with what, explore what? Your comment is very general, and doesn't make much sense - Go is just fine for prototyping. If you mean PL research and being able to experiment with custom methods of abstraction and DSLs then yes, indeed, there's not much to do. Which, as I mentioned above, is a feature in most cases.
- zer8k 3y ago
  I got downvoted because I guess "experiment" was too loose of a term. Indeed, I mean being able to modify the system to suit you. Go, instead, is a system that molds you in it's image. Which is why I believe it's the next iteration of Java and not something like C or C++. It's just simply not "open" enough to create a novelty that enhances it in a way that Google approves of.