6 ms·

In practice, it's used as an alternative to python and ruby and nodejs. It can't fully do what Java or C# do.

by azth 5y ago

coder543 5y ago
Well, that is simply not true at all. Go is a perfectly capable replacement for Java and C#. Many huge projects that would likely never be written in Python have been written in Go when they would have otherwise been written in Java or C# in years past: Kubernetes, Prometheus, HashiCorp Vault and Terraform, etcd, CoreDNS, TiDB, Loki, InfluxDB, NATS, Docker, Caddy, Gitea, Drone CI, Faktory, etc. The list goes on and on. What, exactly, are you saying that Go can't do that Java can? Go is not a perfectly capable replacement for Rust, for example, because Rust offers extremely low level control over all resource usage, making it much easier to use for situations where you need every last ounce of performance, but neither C# nor Java offer the capabilities Rust offers either. I like C# just fine (Java... not so much), but your comment makes no sense. Certainly, I would rather use Go than most scripting languages; having static types and great performance makes a lot of tasks easier. But that doesn't mean Go is somehow less capable than Java or C#... it is a great alternative to both. If someone needs more than Go can provide, they're going to rewrite in Rust, C++, or C, not Java or C#.
- marwatk 5y ago
  > What, exactly, are you saying that Go can't do that Java can? Runtime library addition (plugins) and dependency injection are two big ones. (We can argue the merit separately, but they're not possible in Go) I think if Java had easily distributable static binaries k8s would have stayed Java (it started out as Java).
  - coder543 5y ago
    > Runtime library addition (plugins) https://pkg.go.dev/plugin https://pkg.go.dev/plugin Linux only, but it exists and it works… I just wouldn’t recommend that particular pattern for almost anything. Either some kind of RPC or compile-time plugins would be better for almost all cases. - With RPC plugins (using whatever kind of RPC that you prefer), you get the benefit of process isolation in case that plugin crashes, the plugin can be written in any language, and other programs can easily reuse those plugins if they desire. The Language Server Protocol is a great example of an RPC plugin system, and it has had a huge impact throughout the developer world. - With compile-time plugins, you get even better performance due to the ahead-of-time optimizations that are possible. Go programs compile so quickly that it’s not a big deal to compile variants with different plugins included... this is what Caddy did early on, and this plugin architecture still works out well for them last I checked. > dependency injection https://go.dev/blog/wire https://go.dev/blog/wire Java-style DI isn’t very idiomatic for Go, and it’s just a pattern (the absence of which would not prevent applications from being developed, the purpose of this discussion)… but there are several options for doing DI in Go, including this one from Google.
  - randomdata 5y ago
    > Runtime library addition (plugins) I don't see anything inherit to Go that would prevent it. gc even added rudimentary support some time ago, fostering the addition of the plugin package[1], but those doing the work ultimately determined that it wasn't useful enough to dedicate further effort towards improving it. There was a proposal to remove it, but it turns out that some people are using runtime library addition, and so it remains. [1] https://pkg.go.dev/plugin https://pkg.go.dev/plugin
  - shadowgovt 5y ago
    I believe Go supports DI via Wire (https://github.com/google/wire https://github.com/google/wire).
    - Groxx 5y ago
      Go supports DI by allowing functions with arguments :) Every language with functions supports DI. Wire is just a code-generator version of automatic DI.
  - jerf 5y ago
    Plugins are barely possible and utterly impractical, so no objection there. DI is totally possible, just about every system I build is nothing but dependency injection. What confuses people in the Java world is that you don't need a framework for it, you just do it. You could say the language simply supports a simple version of it natively. If you want something much more complicated like the Java way, there are some libraries that do it, but few people find them worthwhile. They are a lot of drama for what is in Go not that much additional functionality. This is one of the many places the interfaces not requiring declaration of conformance fundamentally changes Go vs. Java and leaves me still preferring Go even if Java picks up every other thing from Go. You don't need a big dependency injection framework; you just declare yourself an interface that matches what you use out of some 3rd-party library, then pass the value from the 3rd-party library in to your code naturally. Dependency injected. All other things you may want to do with that dependency, like swap in a testing implementation, you just do with Go code. (And I personally think that if Java's interfaces were satisfied like Go's, there would never have been a Go.)
- azth 5y ago
  golang doesn't have annotations, doesn't have enums, error handling is very error prone. No ability to choose from different GC implementations, nothing remotely close to JFR.
  - cy_hauser 5y ago
    Go does have some of these features: annotations, enums, JFR. They're just built for features of Go rather than Java. They're not the same but perform similar roles for the Go language. Error handling is subjective but I'm not going to disagree it could use some help. Same with Go's GC in certain situations but nothing I've coded has needed more. All that said, what makes your list any different than a similar list comparing Java to Blub? I don't see your list as preventing one from writing a Java app in Go using Go's idioms instead. (It can't fully do what Java or C# do.)
    - azth 5y ago
      > They're just built for features of Go They're inferior, and do not cover the same grounds (e.g. "enums" in golang are just integer constants, you can't code gen using golang tags, JFR is way way more comprehensive than anything that golang has etc.) The GC selection, JIT, and hot swapping/reloading are features that do not exist in golang, and we've seen what hoops people have to jump through when they face issues that can only be resolved by them. Basically, they're features most people don't know they need them until they do, then they'er already in a big mess. You can write a Java app in golang or assembly, but it won't be anywhere near as maintainable, clear, concise, debuggable, or correct.
      - shadowgovt 5y ago
        Why does golang need JIT when it already statically compiles to a non-virtual machine target? It could probably use some performance optimizations, but JIT would be redundant when it's already compiled.
        azth 5y ago
geodel 5y ago
I mean of coure. I have not seen IBM Websphere Server 6.0.1 written in Go. Neither is there a full fledge SOAP/WSDL engine in Go. So clearly Go is less capable.
- azth 5y ago
  I've seen similar abominations written in golang, but they're not public.
avinassh 5y ago
> It can't fully do what Java or C# do. I am curious, what all stuff it cannot do?
- shadowgovt 5y ago
  Mostly stuff related to tooling and environment because unlike Java, it hasn't been around for two decades for people to patch its weaknesses with workarounds.

In practice, it's used as an alternative to python and ruby and nodejs. It can't fully do what Java or C# do.

by azth 5y ago

In practice, it's used as an alternative to python and ruby and nodejs. It can't fully do what Java or C# do.

Well, that is simply not true at all. Go is a perfectly capable replacement for Java and C#. Many huge projects that would likely never be written in Python have been written in Go when they would have otherwise been written in Java or C# in years past: Kubernetes, Prometheus, HashiCorp Vault and Terraform, etcd, CoreDNS, TiDB, Loki, InfluxDB, NATS, Docker, Caddy, Gitea, Drone CI, Faktory, etc. The list goes on and on. What, exactly, are you saying that Go can't do that Java can? Go is not a perfectly capable replacement for Rust, for example, because Rust offers extremely low level control over all resource usage, making it much easier to use for situations where you need every last ounce of performance, but neither C# nor Java offer the capabilities Rust offers either. I like C# just fine (Java... not so much), but your comment makes no sense. Certainly, I would rather use Go than most scripting languages; having static types and great performance makes a lot of tasks easier. But that doesn't mean Go is somehow less capable than Java or C#... it is a great alternative to both. If someone needs more than Go can provide, they're going to rewrite in Rust, C++, or C, not Java or C#.

marwatk 5y ago
> What, exactly, are you saying that Go can't do that Java can? Runtime library addition (plugins) and dependency injection are two big ones. (We can argue the merit separately, but they're not possible in Go) I think if Java had easily distributable static binaries k8s would have stayed Java (it started out as Java).
- coder543 5y ago
  > Runtime library addition (plugins) https://pkg.go.dev/plugin https://pkg.go.dev/plugin Linux only, but it exists and it works… I just wouldn’t recommend that particular pattern for almost anything. Either some kind of RPC or compile-time plugins would be better for almost all cases. - With RPC plugins (using whatever kind of RPC that you prefer), you get the benefit of process isolation in case that plugin crashes, the plugin can be written in any language, and other programs can easily reuse those plugins if they desire. The Language Server Protocol is a great example of an RPC plugin system, and it has had a huge impact throughout the developer world. - With compile-time plugins, you get even better performance due to the ahead-of-time optimizations that are possible. Go programs compile so quickly that it’s not a big deal to compile variants with different plugins included... this is what Caddy did early on, and this plugin architecture still works out well for them last I checked. > dependency injection https://go.dev/blog/wire https://go.dev/blog/wire Java-style DI isn’t very idiomatic for Go, and it’s just a pattern (the absence of which would not prevent applications from being developed, the purpose of this discussion)… but there are several options for doing DI in Go, including this one from Google.
- randomdata 5y ago
  > Runtime library addition (plugins) I don't see anything inherit to Go that would prevent it. gc even added rudimentary support some time ago, fostering the addition of the plugin package[1], but those doing the work ultimately determined that it wasn't useful enough to dedicate further effort towards improving it. There was a proposal to remove it, but it turns out that some people are using runtime library addition, and so it remains. [1] https://pkg.go.dev/plugin https://pkg.go.dev/plugin
- shadowgovt 5y ago
  I believe Go supports DI via Wire (https://github.com/google/wire https://github.com/google/wire).
  - Groxx 5y ago
    Go supports DI by allowing functions with arguments :) Every language with functions supports DI. Wire is just a code-generator version of automatic DI.
- jerf 5y ago
  Plugins are barely possible and utterly impractical, so no objection there. DI is totally possible, just about every system I build is nothing but dependency injection. What confuses people in the Java world is that you don't need a framework for it, you just do it. You could say the language simply supports a simple version of it natively. If you want something much more complicated like the Java way, there are some libraries that do it, but few people find them worthwhile. They are a lot of drama for what is in Go not that much additional functionality. This is one of the many places the interfaces not requiring declaration of conformance fundamentally changes Go vs. Java and leaves me still preferring Go even if Java picks up every other thing from Go. You don't need a big dependency injection framework; you just declare yourself an interface that matches what you use out of some 3rd-party library, then pass the value from the 3rd-party library in to your code naturally. Dependency injected. All other things you may want to do with that dependency, like swap in a testing implementation, you just do with Go code. (And I personally think that if Java's interfaces were satisfied like Go's, there would never have been a Go.)
azth 5y ago
golang doesn't have annotations, doesn't have enums, error handling is very error prone. No ability to choose from different GC implementations, nothing remotely close to JFR.
- cy_hauser 5y ago
  Go does have some of these features: annotations, enums, JFR. They're just built for features of Go rather than Java. They're not the same but perform similar roles for the Go language. Error handling is subjective but I'm not going to disagree it could use some help. Same with Go's GC in certain situations but nothing I've coded has needed more. All that said, what makes your list any different than a similar list comparing Java to Blub? I don't see your list as preventing one from writing a Java app in Go using Go's idioms instead. (It can't fully do what Java or C# do.)
  - azth 5y ago
    > They're just built for features of Go They're inferior, and do not cover the same grounds (e.g. "enums" in golang are just integer constants, you can't code gen using golang tags, JFR is way way more comprehensive than anything that golang has etc.) The GC selection, JIT, and hot swapping/reloading are features that do not exist in golang, and we've seen what hoops people have to jump through when they face issues that can only be resolved by them. Basically, they're features most people don't know they need them until they do, then they'er already in a big mess. You can write a Java app in golang or assembly, but it won't be anywhere near as maintainable, clear, concise, debuggable, or correct.
    - shadowgovt 5y ago
      Why does golang need JIT when it already statically compiles to a non-virtual machine target? It could probably use some performance optimizations, but JIT would be redundant when it's already compiled.
      - azth 5y ago

geodel 5y ago

I mean of coure. I have not seen IBM Websphere Server 6.0.1 written in Go. Neither is there a full fledge SOAP/WSDL engine in Go. So clearly Go is less capable.

azth 5y ago
I've seen similar abominations written in golang, but they're not public.

avinassh 5y ago

> It can't fully do what Java or C# do. I am curious, what all stuff it cannot do?

shadowgovt 5y ago
Mostly stuff related to tooling and environment because unlike Java, it hasn't been around for two decades for people to patch its weaknesses with workarounds.