[marwatk]

> 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).

[jerf]

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.)

[coder543]

> Runtime library addition (plugins)

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

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]

> 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

[shadowgovt]

I believe Go supports DI via Wire (https://github.com/google/wire).

[Groxx]

Go supports DI by allowing functions with arguments :) Every language with functions supports DI. Wire is just a code-generator version of automatic DI.