Clearly a lot of tools and APIs have been written in it, many would describe not needing a separate runtime on the target system as a big plus and the language seems simple enough to learn and utilize (with VSC support and GoLand both being good), even the typical complaints like the error handling don't seem like dealbreakers.
I wonder what's missing for Go to become a mainstay of development for the decades to come, or at least take up a huge chunk of the job market instead of being considered a niche language in some places.
Why would it be the new Java/.NET? You vastly overestimate that separate runtime as being a huge positive, it is almost indifferent to most niches where these two are most common: servers, especially on the bigger side of things. For a devops team with a proper CICD pipeline, monitoring, whatnot, installing a runtime is beyond trivial, especially that many of it is container-based.
So even if all else were equal, Go would need much much more positives to even start turning the wheel towards itself, momentum is huge in the industry (old Cobol systems are still clocking at places, even if they do so in a VM, as the hardware they are hardcoded against are too old now). Especially that it is not at all a net positive in many people's eyes:
- it is very verbose (yes, it is in fact more verbose than Java, that had been bullied by everyone forever for being verbose..)
- has terrible expressivity (java streams/.net linq)
- smaller ecosystem (java is much larger than even .net, let alone go)
- slow reflection (on the more enterprise-y end of the industry you sometimes need more dynamic workloads)
Also add that both Java and .NET has native AOT compilation, so even that small benefit you mention may not be a dealbreaker, even if those are not as smooth a rides as go's.
Whenever someone mentions Java AOT, I look it up, and it’s a nightmare. Has it changed recently?
I developed server software in Java for two decades, and I can tell you that the huge JVM was always a PITA for us, even after Docker became a thing. All those frameworks? We ended up throwing them out. And the slow startup speed of Java apps made our tooling sluggish. It was also a pain to ship tooling to non developers, for all the same reasons.
Using Go after all this time was like a breath of fresh air.
It’s fine for you to assert your own preferences and biases but you don’t represent all enterprise server developers.
OK... and these AOT compilers work identically to JIT compilers in every way, with no caveats other than needing to specify the architecture in advance.
Unfortunely the best well known, Excelsior JET, is no longer in business, most likely due to GraalVM and OpenJ9 being available as free beer, while PTC, Aicas Codename One are safe in their domains.
There is also RoboVM (https://github.com/MobiVM/robovm) as free beer, however it actually started as a commercial product, and the acquisition from Xamarin kind of stagnated it (naturally).
You’re deliberately ignoring my point and then throwing in an ad hominem for good measure. It has nothing to do with free or non free.
I ran a Java enterprise company for twenty years. I looked at AOT on multiple occasions, starting with gcj 20 years ago, and most recently, GraalVM. There were plenty of commercial compilers in between.
If there had been a non free AOT compiler that didn’t come with a bunch of compatibility and licensing complexities we would certainly have considered it. Just like we bought non free IDEs.
But such a tool didn’t exist. The cost in missing features and added complexity was always much greater than the sticker price.
Java AOT is an afterthought, it is not at all comparable with Go AOT, which is a core feature of Go, expressed for example in the Go team’s explicitly designing the language itself to support fast compilation.
There are plenty of conversations to be had where we can compare the two languages, Go will not always win those discussions, but one of the inarguable features of Go is that it is AOT from the ground up, and that is a feature that’s really valuable to me.
First you accuse me of ad hominem, and then confess that you only cared about free AOT compilers for Java, gcj which the only feat was being able to compile Eclipse with some nurturing quickly abandoned in 2009, while ignoring the commercial offerings that have been available for 20+ years.
WTF? I said “from” gcj, the earliest AOT compiler that I know about, “until” graalvm, the most recent that I know about, and that “There were plenty of commercial compilers in between”.
Because it's a seemingly "boring" technology that's not too hard to learn, seems to have a decent community/ecosystem in the works (let's see where it is in 5-10 years) and overall could hit the sweet spot of just being able to get things done with it in a 9-5 by a bunch of regular developers.
> You vastly overestimate that separate runtime as being a huge positive, it is almost indifferent to most niches where these two are most common: servers, especially on the bigger side of things. For a devops team with a proper CICD pipeline, monitoring, whatnot, installing a runtime is beyond trivial, especially that many of it is container-based.
I use containers and that won't change anytime soon, they're great! That said, CLR and JDK have some space overhead, even if a counterpoint could be made that storage is on the cheap side nowadays. However, there are also those who don't use containers and don't always have 1:1 reproducible environments (even though they should).
I've personally seen a difference in the MINOR version for JDK bring down production by having some sort of an issue that caused the performance under load to decrease 10x in an enterprise project. It would be nice to get rid of that risk and just ship the whole thing, much like how a fat .jar instead of configuring an application server like Tomcat separately makes things easier, just a step further.
Now, Java has some solutions for that, but I think that Go is in an even better position in that regard!
Well said. In addition, golang seems to shun everything under the guise of "keeping things simple", so you don't see frameworks like Spring or ASP.NET.
Of course pretending the issue doesn't exist doesn't make it so. At an employer, the reinvented a dependency injection + application framework, but poorly of course compared to the extremely mature offerings on the JVM and .NET, not to mention millions of dollars sank into maintaining it.
I think Go is on that Java/.NET adoption curve, but it's climbing it slowly because backend programming, as a whole, is a lot bigger, mature and diverse today, than it was when Java/.NET emerged.
I think there's a decent chance that, `[java.age - go.age = 15 years]` from today, Go is high up on the totem pole. From my perspective, its ecosystem is vibrant but still young – we still need to decide on the Go equivalent of Flask, Django, Spring, etc.
Yep! I think, at this stage, `plenty` is the point of my comment. While there are many competing and quality options (vibrant), none of them are the de facto leader (young).
I think, given where we are in 2023, it'd be difficult for a Django (i.e. ORM + templates + web framework all-in-one) to emerge in Go – it's possible we never end up with one, and that's OK. [I don't think there's much stomach for good people to work on sprawling projects like that anymore – we're in an season of backend development that favors separation (vs bundling) of concerns, from my perspective].
I'm not sure if it's a unique feature of the Go ecosystem that there isn't one clear winner in the "minimalist + pluggable web framework" or "ORM" categories, or if we just need to wait for the winner to emerge. Ironically, I think the quality of `net/http` and `database/sql` might have been an anti-catalyst for the development of leading libraries in those verticals.
> we're in an season of backend development that favors separation (vs bundling) of concerns
I work in a small team (5 developers), on multiple projects that span from 3 months to 1 year of work. While I like some of Go qualities (like speed, types, low memory, easy deployment,...) it would be hard for me to introduce Go to the team. The thing is that with Django (or Laravel, or Rails, or any "opiniated" framework) I can point the team to a nice single documentation website and associated framework that covers probably 90 to 95% of our needs and gets us right into the business logic real fast. There's real value in framework integration for teams like us (and for this very reason, we don't use Flask either, way to much fiddling). Also, the feature set in these solutions, while maybe "out of season", is fine for most of our projects.
At this point, should I want to push Go to the team, I would have integrate libraries myself and document... so basically starting my own version of a "framework". Like you said, it's a sprawling project. But hey... isn't it how Django started ? Maybe one day...
Meanwhile, I'll stick to using Go in my personal projects, until I have a very clear picture of the ecosystem.
Because it's very literally decades behind Java on almost every front. It was designed for system programming whereas Java is an enterprise platform. On observability Java stands alone. Far beyond anything else (including .net). E.g. check out OpenTelemetry to get a sense of how far ahead Java is on that front. It does all of that without impacting performance in a significant way.
In terms of 3rd party tools. NPM has more packages but they are simplistic toys for the most part. Java has a fantastic number of packages to solve every niche problem you can think of. These packages are at a maturity level that no one can compete with. Hibernate is so far ahead in the ORM field that there's no point comparing it to anything else...
The same can be said for Spring, it is massive. In a bad way as well... But that mass is without competition. You need to integrate with something, there's already someone who built that and it probably works with Spring.
Then there's scale... Horizontal and vertical scaling and the set of tooling to measure that it works properly. The question isn't why don't people switch to go, the question is why does anyone use Go to begin with?
To a large part it's a combination of ignorance about Java due to the vast amount of stuff that's already out there. A hostility towards the language which is redundant since there's Kotlin, Scala, etc. or problems with Oracle which is something I actually get... I use OpenJDK but Oracle does loom. Go feels like a toy. If I were to build a system level solution I would use Rust which seems superior in every way. For high level stuff the JVM is without competition.
Go is moving too slowly (ex: most of the SDK still doesn't support generics). Meanwhile, Java is moving relatively quickly, as are new contenders like Rust.
Go is moving slowly, or trying not to move at all, on purpose, and I have to say, as a C# developer having to constantly learn new syntax, it seems refreshing. At the rate it's adding new syntax, C# may fall apart under its own weight and become the next C++.
Maybe the decline of desktop applications (Java, C#) and Android (Java)? And then Go coming out with some killer frameworks? I have to stretch my imagination to imagine anything causing Go to outpace C# or Javas ecosystem.
Go ecosystem is like a fraction of what .NET/Java is. Both in quality and size. Dart for instance is a better lang. It is also from Google. It also compiles to binaries. Why is that not the new...
The slim spot for Go is the devops tools space. Where Go may or may not survive. Considering the march of Rust.
Clearly a lot of tools and APIs have been written in it, many would describe not needing a separate runtime on the target system as a big plus and the language seems simple enough to learn and utilize (with VSC support and GoLand both being good), even the typical complaints like the error handling don't seem like dealbreakers.
I wonder what's missing for Go to become a mainstay of development for the decades to come, or at least take up a huge chunk of the job market instead of being considered a niche language in some places.