[brunojppb]

> Boring is good. Boring is stable. Boring means being able to focus on your work, not on what’s different about Go.

This really resonates with me. I work with NodeJS and the JS ecosystem in general on my day job and I have to tell you, the struggle is real. The ecosystem is fragmented, everyone is doing their own thing, which is hard to make things stable. Don’t get me wrong, I still enjoy this work, but I really wish the JS ecosystem could have a stable modern foundation we could rely on.

[hermanradtke]

The JS eco-system (npm, React, etc)? Sure. Let us also acknowledge that JavaScript, the language, has been prioritizing backwards compatibility before golang even existed.

[ilyt]

Well, it is a bit easier if you have no stdlib to speak of

[trhhowaway232]

JS has a stdlib, there's just nothing in it.

[KronisLV]

I wonder why Go isn't the new Java/.NET (yet?).

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.

[kaba0]

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.

[doctor_eval]

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.

[pjmlp]

The only change is that now there are free beer AOT compilers, commercial AOT compilers have always been an option since around 2000.

[doctor_eval]

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.

Right..?

[pjmlp]

Naturally depends on the use case, yet they work good enough to be in business for 20 years.

https://www.ptc.com/en/products/developer-tools/perc

https://www.aicas.com/wp/products-services/jamaicavm-tools/

https://www.codenameone.com/

Android 5 & 6 (only changed back into JIT/AOT due to long compile times), https://www.infoq.com/news/2014/07/art-runtime/

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

[KronisLV]

> Why would it be the new Java/.NET?

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!

[za3faran]

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.

[trhhowaway232]

Java DI isn't good either. It runs a full DAG on boot.

[kaba0]

There are entire second generation of “cloud-ready” frameworks for Java that does it at compile time instead.

[gen220]

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.

[guggle]

There are plenty of Flask equivalent in Go IMO. Django... not so much.

[gen220]

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.

[guggle]

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

[coffeebeqn]

You also don’t need to have frameworks for everything when the std library delivers

[invalidname]

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.

[slantedview]

> I wonder why Go isn't the new Java/.NET (yet?).

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.

[booleandilemma]

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

[kaba0]

But Go started at Java 1.1 levels, for no good reason. If you want a language with a conservative growth, Java is your choice.

[coffeebeqn]

Moving towards what?

I use it to build services that can serve lots of requests, I don’t need the language to be moving fast underneath me

[shakow]

> Moving towards what?

Toward a better stdlib? E.g. we had to wait years to get Min/Max.

[coffeebeqn]

I think the stdlib is pretty good! Was anyone really waiting for min/max?

[slantedview]

The SDK is where most movement is needed.

[trhhowaway232]

Go is spreading like wildfire in microservice and devops space and Rust is following closely behind.

It's over.

[tmerr]

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.

[liampulles]

I was a Java dev full time and went to full time Go dev. I think a lot of it boils down to wide employment opportunities with Java.

Some people also like the idea of creating OO package private final monstrosities.

[seanmcdirmid]

Go is popular in dev ops right? It could theoretically languish there for a while, like Python did, before becoming popular for other things.

[pjmlp]

Because the overal experience is lacking in language features, tooling and ecosystem.

[AtNightWeCode]

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.

[devjab]

JavaScript is famously backwards compatible. That’s exactly why it’s the mess you describe.

[afavour]

> I really wish the JS ecosystem could have a stable modern foundation we could rely on.

I actually think we do now. ES modules, ES2020 code. Both supported by Node and major browsers. Node even has a built in test runner now! The problem is getting everyone up to this bar. Once we’re there I think things are going to feel a lot better.

I think part of the problem is that the JS ecosystem also encompasses frontend UI work and there are so many different applications for it that multiple implementations is inevitable. Desirable, even.