While it is absolutely true Go servers use less memory that classic servlet deployments, The question is what were you using at first place? where you using a big framework? with this or that big IoC container ? with a bloated ORM ? ... or where you using barebone jdbc and writing servlets without any framework? because essentially that's what you're doing with Go, Go has 0 big framework(and no Beego or Revel are not complex), 0 big ORM , 0 IoC container ... And while the Java culture is about heavy decoupling and reusability , the Go code culture is basically about writing correct code without thinking about re-usability at all, because often you just can't. So I'm curious. My point is didn't you reduce memory usage because Go forced you to write code a certain way ?
> the Go code culture is basically about writing correct code without thinking about re-usability at all, because often you just can't. So I'm curious.
That's a very strong statement. Do you have evidence to support this? I don't code in Go right now, but have been keeping an eye on it as it continues to gather momentum.
I'll jump on this, but I'm going to change it up a bit.
> the Go code culture is basically about writing correct code without thinking about USABILITY at all
The reality is go is YOUNG and it shows. Lets take two good examples that are part of what is going on in golang today.
Vendoring: The core teams approach, and what the community are doing have diverged pretty rapidly. Recently there have been some efforts bring vendoring into alignment, but what is being used isn't the best approach/solution, its good but on the whole could be better.
http: The core library is great if you want something small, and its fairly easy to put together a tool chain that will remain "idiomatic". However if your going to go out and build something "large" then you have an interesting issue, because OOTB core http lacks any concept of context. There are some interesting tools and frameworks out there to make up for this (gorilla/context, codegangsta/negroni) but if you adopt them your no longer "idiomatic"... your libraries are now less reusable because they are tightly coupled. It looks like a new method signature is going to be required in the http package, one that uses golang.org/x/net/context and returns errors so we can have a sane http stack OOTB in go....
Log vs syslog: Logging in go is fairly messy right now... there are a bunch of packages that try to make up for this, but really better logging has to be built into the core. Syslog has levels/features, log is just dry and basic (maybe too much so). The core not only needs a unified solution, but one that is going to be context aware.
Will these get fixed? Probably! The core team isn't deaf. However if they don't start moving on a path to 2.0 soon and address some of the real issues, I fear that go will end up in the same boat that python did in 2.x vs 3.x.
P.S. in spite of all this I have been writing a LOT of go lately and enjoying it, but it really does need to grow and soon!
Lack of generics can make it harder to write cleanly reusable modules in Go. I've noticed gophers are often less allergic to copy pasting code with tweaks (as long as it isn't too many lines) and don't mind rewriting similar code if it is obviously correct. It was a bit of a culture shock for me at least.
You confuse parametric polymorphism with reusability. The former is merely one of several ways to achieve the latter. The Go way for reusability usually consists of interfaces.
Interfaces and parametric polymorphism are not alternative approaches to solving the same problem, which is why many languages that feature parametric polymorphism also feature interfaces or similar constructs [0] (and why some languages that had interfaces for a long time later added parametric polymorphism [1].)
Code reuse is totally possible in Go. I never said otherwise. However, there may be unnecessary ergonomic and safety issues due to lack of generics. In particular, you may end up casting / type asserting when you really shouldn't have to.
The parent comment is incorrect. Orthogonality is a really big deal in Go, and is highly stressed in the culture. Libraries are strongly encouraged to present methods that work with interfaces that are defined by the standard library to ensure the libraries are composable.
If your library works with streams of bytes, its methods had better use io.Reader and io.Writer. If you're writing an ORM, it had better be built on database/sql.
The problem got exacerbated when the container-ized deployment stopped letting the OS more efficiently serve shared memory. There are lots of tricks and wisdom built into platforms like Tomcat to reduce memory use, too. They're just confused when they're alone in what appears to be their own universe.
This is why there's such a strong pressure to move to more svelte language implementations and "microservices" as you start to see containerization take off.
> the Go code culture is basically about writing correct code without thinking about re-usability at all, because often you just can't.
What a ridiculous statement. Go encourages elegant and simple interfaces to make code reuse easier. The tooling provides an incredibly easy way of sharing code. The "culture" is all about sharing code. Go's much better at facilitating code re-use than (say) Java, both at a language level and at a cultural level.
The JVM has the largest library collection of any platform (currently 1,026,516 libraries just in Maven Central repository). Sure a lot of is to do with the age of the platform but this idea that Java is somehow impeding code reuse due to language/cultural reasons is ridiculous.
One of the biggest complaints for people coming to Java is actually just how many transitive dependencies libraries are brought in.
While it is absolutely true Go servers use less memory that classic servlet deployments, The question is what were you using at first place? where you using a big framework? with this or that big IoC container ? with a bloated ORM ? ... or where you using barebone jdbc and writing servlets without any framework? because essentially that's what you're doing with Go, Go has 0 big framework(and no Beego or Revel are not complex), 0 big ORM , 0 IoC container ... And while the Java culture is about heavy decoupling and reusability , the Go code culture is basically about writing correct code without thinking about re-usability at all, because often you just can't. So I'm curious. My point is didn't you reduce memory usage because Go forced you to write code a certain way ?