Comment by jasode | Hacker News Reader

Comment by jasode | Hacker News Reader

Parent Full thread

>- Made by really famous veteran language designers

- Backed by Google

Looking at decades of how various programming languages gain popularity, those proposed reasons don't seem that convincing when we look at counterexamples.

E.g. counterexamples of unknown (at the time) creators creating popular languages : Bjarne Stroustrup (C++), James Gosling (Java), Rasmus Lerdorf (PHP).

E.g. counterexamples of famous computer scientists creating languages that were not widely adopted : Alan Kay famous for Smalltalk but Squeak is not widely used, and Niklaus Wirth famous for Pascal but later Oberon not widely used.

I think Go's popularity is mostly explained by technical reasons:

1) compiles to a single executable that's easy to deploy. This is a compelling advantage over Java,C#,Python,Ruby that require runtimes or complicated virtual environments.

2) a good enough standard library that's useful for quickly programming middleware type of apps on servers. Server-side infrastructure apps are Go's sweetspot. Go's a better productivity baseline than C++ and Javascript with their bare standard libraries that requires researching "what's the best library?" on Stackoverflow or browsing NPM repos.

3) "go routines" which some think of as the "killer feature" because that concurrency mental model is easier than threads or async/await.

I'm guessing those 3 tech reasons attract more programmers than people that think "Rob Pike and Ken Thompson are famous guys at Google so I'll use Go". Regardless of celebrities, the language itself still has to have some compelling technical advantages for it to grow in usage.

C++ was born at AT&T, shared the UNIX throne with C, adoption grew from there.

Java was created by Sun, was remarkable in having the JDK available as free beer in the age of comercial compilers, Sun bankrupt themselves pushing Java everywhere.

PHP provide a saner way to use a Perl like language on ISPs, whithout the mess of mod_perl, while most ISPs would charge extra for something else.

Smalltalk was gaining adoption, before its main backer outside Xerox (IBM) decided to join forces with Sun and Oracle, and move into Java instead, famously rewriting their flagship product into Eclipse. One of the main architects behind this effort is now leading Visual Studio Code development.

Compiling to single executables has been the way compilers worked before dynamic libraries became widespread in 32 bit platforms.

My email is in my profile. You wanna record a podcast or something? Your breadth of knowledge on the history of a lot of this stuff is really great. Have you written things down anywhere other than HN comments?

Thanks for the invitation, it would be a quite boring podcast, I am not that interesting really.

Sure, I was posting on Usenet, Slashdot, Reddit,...online since 1994.

I would also add that the tooling is very good. A few examples:

- Built-in test suite that is simple but extensible. Also fast because it can test different packages simultaneously.

- Building is easy. Unless you're doing something unusual, you probably don't need a Makefile or any configuration, you just run go build .

- Gofmt means that everyone's code looks the same and you don't have to waste your time arguing about indentation or whatever. Some may see this as a downside.

I think there's another big reason: simplicity. The language spec is very short and readable, and there are very few concepts to learn to be productive with it. Compared to most other popular general purpose languages, this is a refreshing–if at times frustrating–quality to have.

If James Gosling was an unknown I wonder what your criteria for renown is.

Oberon is sort of widely used, at least conceptually. Large parts of it are co-opted into Golang.

I wouldn't call the method syntax declaration taken from Oberon-2, and unsafe instead of SYSTEM as large parts.

They still don't have a means to load packages dynamically as easy as Oberon allows for.

>This is a compelling advantage over Java,C#,Python,Ruby that require runtimes or complicated virtual environments.

You can deploy c# app without having to install anything.

>You can deploy c# app without having to install anything.

The C# option of self-contained executables is very recent with VS2019 & VS2022 and was not available when Go came out in 2009.

Before that, you had extra steps of ClickOnce installer deployment or obscure AOT experiments that nobody was using in production. (Also as trivia, the new C#/NET6 self-contained executables don't work on Windows 7 and Server 2012. You still have to install .NET Framework runtime for those older systems.)

So during most of Go's history, the C# executable would get the following error if deployed on a computer without the .NET Framework runtime already installed:

https://www.google.com/search?q=%22This+application+requires...

Let's not also forget that the .NET self-contained executables are huge in size compared to Go's. An ASP.NET app could be more than 100 MB

Many go apps are fairly large as well. Most of mine start at 10 MB and quickly reach 70-80 MB for fairly simple functionality for similar reasons (hosting runtime).

NGEN, MDIL, .NET Native, Xamarin weren't obscure AOT experiments that nobody was using in production.

"1) compiles to a single executable that's easy to deploy. This is a compelling advantage over Java,C#,Python,Ruby that require runtimes or complicated virtual environments."

Docker makes deploying Java about the same as Go

Every Java app I've ever deployed, I needed to tune the JVM.

Well, not when I'm running something locally. Every app I've deployed professionally in corporate environments (which is most of my experience running Java), I needed to tune the JVM.

I'm surprised. Latest JVM versions are tuned really well out of the box. Tuning is a good thing by the way. Its the reason Java can handle areas that Go can't.

Yeah, although it seems to be taking a while for everyone to update to the latest and greatest JVM versions.

While in Go it gets rewritten in Rust instead, because it lacks the tuning knobs.

A.k.a.: Why just have a single thing (a statically compiled binary), when you can have several moving pieces and different levels of infrastructure and configuration to worry about (the hypervisor, the container runtime, the container cli, the open ports and shared volumes configuration, the host OS image, the JVM inside the image, java memory and gc tuning, and so on)

Maybe you are building a standalone utility in Go that can be downloaded as a single binary. Great. Most places I work at, deploy to Kubernetes as docker containers

Given that the context on this subthread is how a benefit from Go is that it "compiles to a single executable that's easy to deploy. This is a compelling advantage over Java,C#,Python,Ruby that require runtimes or complicated virtual environments."

I fail to see how this information about "most places you work for" is relevant.

Even if that's the case, you can always also deploy Go with kubernetes and whatever.

But you can't deploy most of the others as a single static binary.

(Getting one out of Java, for one, requires some half-arsed non-really-supported solutions, whereas getting one out of Go is the default).

"I fail to see how this information about "most places you work for" is relevant."

I can spell it out. Where is I work is a web based business and those businesses are typically using hosted environments. Go binaries aren't an advantage in these environments.

One can, and many do, just deploy a single Go binary into those "hosted environments". There have been a couple of posts on HN of teams doing that.

In fact one can even do it your way, and use kubernetes and co in those hosted environments and Go binaries would still be an advantage -- because the container for the go-based service can just have a static binary inside, and be relatively easier to manage than a Java one.

Java deploys as a single file so would be the same as a Go binary. Container just needs the JVM included, which is trivial.

Last time I checked, Go has a runtime as well.

Which is neither here nor there.

It'a runtime that's run from the statically combined binary.

Great, Java is doing the same since the first commercial JDKs started supporting AOT compilation around 2000.

Or if you prefer free beer recipes, gcj which got dropped when most developers eventually moved into hacking into OpenJDK around 2009.

What other people actually use matters a lot though. Hell, a greater proportion of Java devs ca. 2002 probably knew how to AOT-compile their programs than do today. Using minority tooling in a popular language is often just as painful as using a minority language.

That is orthogonal to what language implementations can do, failure to education doesn't change what tools are available.

Only in a vapid purely existential sense of "available".

It is available, if people don't want to pay for them, and prefer free beer stuff, it is another matter.

It's actually the opposite:

The availability of a half-arsed, hardly supported, restricted compared to regular JVM based runs feature, dumped at some point by SUN so that they could say they also have it, doesn't mean people should use it, or that a platform is as good in that aspect as another who has that feature as a fully supported, first class, default mode.

Don't be excited by mere presence of a feature. Implementation, maturity (which is different than "age of introduction"), completeness, support, and usage, matter...

Ah the proof of not have the slightest idea of what you are talking about, given that those commercial AOT features were never sold by Sun in first place, with exception of Embedded Java deployments.

If we go down the implementation, maturity route, than even there are several half-arsed, hardly supported capabilities in Go compared with the JVM ecosystem, even after 10 years of existence.

>Ah the proof of not have the slightest idea of what you are talking about, given that those commercial AOT features were never sold by Sun in first place, with exception of Embedded Java deployments.

Didn't wrote sold, said "dumped at some point by SUN so that they could say they also have it".

But thanks for the ad hominem.

>If we go down the implementation, maturity route, than even there are several half-arsed, hardly supported capabilities in Go compared with the JVM ecosystem, even after 10 years of existence.

Sure. Just not related to the ability of building a static binary.

>Great, Java is doing the same since the first commercial JDKs started supporting AOT compilation around 2000.

Yes, with hardly any support, several issues, and one which only a handful of people actually ever used...

Except a Java container running a simple REST server is going to be a few hundred megs, while a similar Go container will be around 10 megs most likely.

Which doesn't matter all that much until you're distributing an app made out of 10-20 such services...

Since Java 9 one can tier it down with jlink, previously the uberjar plugin could also be used for similar purposes.

That's only true if your project and all your dependencies are modularized, right? I moved on to Go around the time Java 9 had recently come out, so no idea how well the ecosystem has evolved in this direction in the meantime.

For the record, I miss many aspects of Java, especially the language and tooling, but Go was definitely the right choice for our project at the time.

From what I've seen major Java projects are still delivered in large containers with a full JVM (ElasticSearch, Keycloak at least).

Not with the uberjar approach.

Many projects choose the easy way out when packing their deliveries, and to certain extent Java is having a Python 3 moment with anything past Java 8.

The cynic in me sees that as the main reason why Docker was adopted, HP-UX was already having containers in 1999 and no one was rushing to package Perl into them.

Reply on news.ycombinator.com