* Made by really famous veteran language designers
* Backed by Google
Not saying it doesn't deserve its popularity, but most of the things listed are not necessary for explaining its popularity, and none of them (even taken together) are sufficient.
- 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.
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.
Sure, I was posting on Usenet, Slashdot, Reddit,...online since 1994.
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...
They still don't have a means to load packages dynamically as easy as Oberon allows for.
- 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.
Docker makes deploying Java about the same as Go
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 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 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.
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.
It'a runtime that's run from the statically combined binary.
Or if you prefer free beer recipes, gcj which got dropped when most developers eventually moved into hacking into OpenJDK around 2009.
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...
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.
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.
Yes, with hardly any support, several issues, and one which only a handful of people actually ever used...
Which doesn't matter all that much until you're distributing an app made out of 10-20 such services...
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).
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.
Go is very well documented: That was the killer feature for me.
No more search tutorials / videos etc. - just get the go book, read it, and start coding.
Of course there are tutorials and videos everywhere for fun stuff.
But good documentation is more important than we think - even in the 21st century!
Using the two examples go and rust, Go's documentation is on another level compared to rust, it's more common to see examples in Godoc's than in Rust documentation... That's not a failure of Rust or the maintainers, it's just a different culture I guess.
If I want to do something in Go with a new lib, i can easily put together what I need to do using the documentation.
Where as with Rust, it's often confusing to the point where if they don't have an examples folder on the library, I'm shit out of luck understanding how to do something.
Rust is a mind bending ordeal by comparison with both the borrow checker and other foreign ideas that take a while to come to terms with.
Having used both I disagree; Go's stdlib is extremely well documented, even unexported types are along with examples etc. Rust docs are useful but more often feel like there's many things you're expected to figure out from the source and only minimal examples are given.
I am a fan of Rust, but I think Go's docs are an example to follow. The more complex the language, the richer docs it should have imo.
Quite aside from docs, Go's tooling situation is also better.
It's not a service they can pull the plug on, it's a software package that would still exist even if the entire Google organization went poof tomorrow. Because if it was a service they could just pull the plug on I would never have started using it.
Anyways, key point was that Google reputation was different, when Go took up. I can imagine if it would launch now it would find different reaction, which could prevent a community forming, thus less of safety.
First, I don't think even the most devoted rustacean can deny that Rust has a hell of a learning curve.
But perhaps most importantly is that Go has a strong and extensive standard library that covers many 21st century applications (e.g. talking to REST APIs).
The problem to me with the Rust "no stdlib" model is it leaves you with two equally unattractive options:
1) Write the library yourself (and leave yourself with the associated technical debt of maintaining it)
2) Figure out which of the often dozens of third-party Rust crates you want to use (and rinse and repeat the selection process for every library, and then expose yourself to third-party maintenance debt).But back then? Yeah, I was kind of expecting one of them to "win".
They overlap way more than they don't i.e. there is way more software that you can write in both languages than software that you can write in only one of them.
The "best language for the job" is mostly a myth.
The choice of language is mostly dictated by what you cannot do, rather than what you can do.
Can I use Go or Java to program a micro-controller with 128 kB of RAM? Not really (at least no using the official, non-crippled implementation) because even "hello world" in those languages exceeds that 128 kB limit.
If I'm writing a cmd-line app that I want to ship as a single binary for Windows and Mac and Linux, I'm not using Python. Technically it's possible but very few are doing it while Go gives me out of the box multi-platform compilation.
The reality is that the majority of software written today falls into one of those categories: * web frontend, running in the browser, by necessity written in JavaScript or something that transpiles to JavaScript. Both Go and Rust are out of this game * web backend and similar server software: both Rust and Go compete for that * command line apps : both Rust and Go compete for that * games : AAA games are pretty much C++, Go and Rust are out (although Rust could, in principle, work)
So in most cases both Rust and Go are unsuitable for the task or they compete for the task.
You'd be surprised actually. Java Card is actually designed for memory constrained environments. It's not as featured as Java itself but it uses the same language syntax and class file format.
What's moving the scales in favor of Go, for me, is Rust's borrow checker. I'm aware that it has a bunch of advantages over a garbage collector, but those are paid for with a pretty noticable productivity hit that doesn't seem to go entirely away with experience either; experienced Rustaceans I've consulted with less-common patterns still spent a lot of energy finding a way to make them work with the borrow checker and still sufficiently efficient, and most of that could have been saved for more productive work in a language more open to existing design patterns. Usually I'm neither out for the maximum safety at all costs nor resource-constrained, so I'd rather take Go-ish levels of safety and Go-ish performance and get work done faster.
If there was a Rust with a first-class garbage collector, but keeping all the neat functional elements, the neat semantics, the great libraries and ecosystem, strong types, single binary etc. pp., I'd pick that right away. Go is "easy" at the cost of expressiveness to a degree that makes for reams upon reams of repetitive code or code generation, and Rust-ish functional patterns could greatly condense that and make much more readable, at the expense of having a somewhat higher learning curve. That's a trade-off that I'd much prefer, reading and reviewing Go codebases can be very tedious.
Unfortunately major projects pull on tens of random libraries from the internet which represent real supply chain risk.
And those two options don't strike me as equally unattractive. Writing everything that isn't in the standard library from scratch is completely impractical for modern apps. Nobody does that in Rust. Integrating crates from the ecosystem into your workflow is just part of developing in the language.
People complain about Racket's ecosystem, but it has many libraries that would be PhD level effort to implement and are unique in its ecosystem such as Rosette and Redex. If some random REST API doesn't have bindings yet, implementing those myself isn't all that difficult.
I'm the same. For me, it was some combination of:
- I can build useful stuff with few dependencies
- I don't have to wait seconds for compilation
- I can trivially build, scp the build artifact, and run it
1. The standard library is very good in the sense it covers a fairly wide range of areas and gives you some idea of how to use Go idiomatically (I feel this is more important in Go than in other languages I've used).
2. The language just feels right to me. I have not met any other language that feels like it was optimized for my brain that well. I recently made an attempt at learning Rust, and I kind of got it, but I eventually gave up because the benefits did not seem worth it to me in light of the steep learning curve. Go just clicks with me. It's not the best language ever by whatever metric you choose, but for my needs, it is the right language.
C is a nice language because there's no magic happening - functions are only executed if they are explicitly called. However, C had problems with strings, memory management, resource cleanup, undefined behavior, and probably a few other things I can't recall at the moment. It was also not designed with concurrency in mind, and glibc for some reason doesn't support static linking.
Python is a very nice language to work in, but there is a lot magic going around with all those Python protocols and magic methods. I also find myself making a lot of errors using exceptions - exceptions can happen at any point and there is no way to anticipate them, other than documentation, which leads to try/except boilerplate. And if I want to handle exceptions on a more granular level, I find myself writing try/except for every line I call, which is 2 lines of boilerplate - same as "if err != nil {" and "}". Also, CPython has a lot of dynamically linked dependencies, which makes containerization more difficult. There's PyInstaller, but PyInstalled doesn't seem to play well with non-pure-Python modules (uwsgi, for example). And concurrency in Python is terrible because of GIL, and asyncio is far from perfect, considering function coloring and inherent single-threadedness.
Go managed to become a language with a feel of Python but with certainty of C. It's like someone took C, fixed strings, added anonymous functions, automatic memory management, defer keyword for resource cleanup, sane concurrency model with channels and select. I think the name "select" comes from the Linux select syscall which allows you to wait for multiple file descriptors until one of them is ready - same thing happens with select and channels in Go. The select syscall (and its descendants) is the bedrock on which the whole asyncio world relies upon, so Go's concurrency design is already proven in practice.
When I write Go code, I'm rarely worrying about an exception popping out of somewhere. Panics do happen, but in most cases, they are caused by truly exceptional errors and warrant a crash.
And even though it's not a "systems language" in a kernel sense of the word, I've used Go to write video4linux applications, so it is certainly capable of making ioctls and manipulating C-like structures. Also it's statically linked, so it's possible to make really small containers with it, and easily cross-compiled, which is nice for portability.
- https://madnight.github.io/githut/#/pull_requests/2021/4
- https://www.tiobe.com/tiobe-index/
- https://redmonk.com/sogrady/2022/03/28/language-rankings-1-2...
Dart seems to be doing relatively well. Considering Go has more things in its favor than Dart, it's logical that it's doing better. Still, the Google boost seems to be really big.
Dart is actually the counter example for “ Backed by Google “
Similar to the peer comment to me, Dart languished for a long time. You have to remember Dart was created as a replacement for Javascript and that they wanted other browsers to embed the DartVM in their browsers. This got absolutely rejected by Mozilla, Apple, and Microsoft.
They then attempted to use it as a transpiled language, but it always generated larger javascript files than most other solutions. It still exists and is used, but Typescript ended up being a better solution. (note: there is AngularDart, which is a bit of a fork/mirror of Angular, but for Dart). This has some uses within Google as I understand it, but it's usage outside of that is rather small.
Flutter using Dart ended up being a large boon for the language and drives much of the changes to the DartVM.
Dart had to go through various targeted usages before it really found a home.
Golang obviously didn't have that constraint, it didn't depend on any external runtime.
After the browser rebuff Google had a meandering approach to figuring out where Dart could fit in instead. Whereas Go slotted quite easily into one specific niche, building microservices at Google.
I think the lesson is that clear positioning is crucial
Yeah that’s a positive
>> Backed by Google
But that’s a negative, https://killedbygoogle.com/
I definitely think you’re too fast to dismiss the language features contributing to popularity. As an example:
Fast builds are a positive developers immediately warm to when they experience them (stand by for rustacean “i need time to make tea and my compile times are exactly the right length for tea break” type comment). The example of the 4.4mb c++ project that results in the compiler ingesting 8Gb of data is eye opening. C++ needs to resolve type information for all includes and all their includes and all their includes… go only needs the interface so compilation can be done without all that effort.
A more interesting comparison would be open source projects that Google has abandoned or failed to properly hand over control of to the community, especially if we're talking about Go.
It is true that Google has some poor product management and has some hilariously inept examples or product coherency (chat being the biggest disaster). But people praise startups for pivoting (read: killing a product) and (in general) demand innovation over glacial iteration. Trying new stuff necessarily means killing things that don't work (or paying a whole bunch of engineers to maintain a dead product for eternity).
Yes, but you discount the size of Google. Some of the things Google has killed have been large enough to have been considered successful products for a startup. They kill a "tiny" product because it's only large enough to be what some startup hopes to become. Google Reader is my favorite example of this. Multiple companies now exist in the soil on top of that grave.
Go has the fundamentals to survive - it’s open source, it has a healthy amount of contribution from non-google employees, the compiler is written in Go (that’s important when you consider an alternative situation like a python or js developer who wants to contribute a change to their compiler (they need to learn c / c++ respectively), i strongly suspect that if google walked away tomorrow, the velocity of change to the compiler, stdlib etc would not massively drop in the short term.
Medium / long term though… would i bet on Go over Java? It’s not clear to me that Go has reached the level of market penetration to make that a simple question.
Edit: i meant to add halo projects like docker, kube etc. as reasons to suggest the Go community is healthy
The tool as-it-is keeps chugging along pretty well and even improving in small ways, but it stops reacting to larger trends and misses the boat at critical moments. Some new language in the same space comes up and finds it easy to shear off a massive portion of its user base by doing "the same thing, but modern".
(Less obvious models would be PHP to backend JS, and PHP and Python to Go, which had similar community development arcs.)
No, that's also a negative. C is close to assembly and produces fast code but it's weakly typed and very unsafe. Pascal was the strongly typed and safe option but people went for C because speed was considered more important than safety back when processors were slow.
In today's online world, we've realized safety is more important than speed. We write web apps in slower interpreted languages and Rust is a response to unsafe code that can be hacked like a hot knife through butter. I consider it a move in the right direction.
So I don't consider Go being made by really famous veteran language designers to be a plus because they produced a poor language that only won out because it neglected safety in a quest for speed. That wasn't as bad when computers weren't online, but it still allowed programmers to make errors that caused code to crash. Today it's become a critical issue.
Interestingly, Go is more like Pascal, Modula-2 and Oberon than like C, except in syntax. With Go, the creators of C have admitted Niklaus Wirth was right.
Oh here we go :-) and yet the world spins on C kernels and lands jumbo jets in C autopilots and regulates heartbeats with C pacemakers and, and, and …
It seems there’s more nuance to this than just “strong types good”.
>> people went for C because speed was considered more important than safety
But for the past 10-27 years people have the choice to use a fast and safe language (java, c#, go) and they do, in very large numbers.
For the past 10 years (-ish) they’ve had the choice to use rust too - but they don’t. Rust has a popularity comparable to clojure or erlang.
No, no even close. Java and C# crawled on a Pentium III-IV even with SSE2 compared to C and C++.
If you said Ocaml...
Keep in mind that many of those things are written in a subset of the C programming language, such as MISRA C.
MISRA as you point out is another useful tool in the toolbox.
Likewise outside UNIX, the C compilers that were starting to appear were just as fragemented, supporting only subsets of K&R C.
...and "really famous veteran language designers" wouldn't become famous veterans if they wouldn't learn something along the way.
"Unsafe" in most discussions today refers exclusively to the latter.