This is quite accurate, but I think it’s relevant to note that this is nothing better than “I’m wearing pink b/c pink is the popular color”. Or as during the financial crisis, when armies of bankers made incredibly bad decisions, but were rewarded, b/c they made the same sort of decisions that all the other bankers made.
In 1999, it was clear that Java was coming on as the language for enterprise apps. Boy, that worked out well. Then it was Ruby-on-Rails, then PHP, then Python, now Golang and Node.JS, and who knows what new hotness will arrive, that everyone will tell us we just gotta use, b/c it’s (Tony Tiger voice) GREAT!
Look: I’m not saying that you’re wrong: yes, you choose the language and ecosystem based on all sorts of factors that have nothing to do with actual worth. In fact (as Keynes said about the stock market) it’s a beauty contest, and you’re a judge. You’re voting not for the most beautiful contestant, but for the one that everyone else will find to be most beautiful.
That doesn’t mean you’re wrong. But we should know why we’re doing a thing, and not fool ourselves into believing we’re doing it for reason X (quality) when in fact we’re doing it for reason Y (we’re all lemmings).
Code quality is an illusive thing. Probably too off-topic on this forum to dig deeper. In research they talk about fault density and change impact analysis, if you wanna google-scholar it.
I philosophically despise Golang as it favors simplicity to a fault- it just recently added generics, as an example. I prefer statically typed languages which maximize expressibility- Golang by design minimizes the learning curve but sacrifices advanced language features.
However, it is a low hanging fruit for cloud development due to its lean program size and native support for it in most AWS services such as Lambda.
Another selling point of Go: mechanical sympathy is baked into the language paradigm, the community, and the compiler itself. This is refreshing compared to say Java or C# which leans too heavily on abstraction at the cost of performance and reduced comprehension of how your code actually runs on hardware.
TLDR; I would personally never use Golang but understand why companies might choose it due to its leanness, learning curve, and cloud friendliness.
Heh, as it turns out, this is false. I know of two instances where a senior exec was fired for buying IBM, and in one case, I was there to watch the aftermath (got called-in by his replacement; couldn’t clean it up fast enough to save that guy’s job, but was fast enough to save his successor’s).
ETA: and obviously if I know of two such instances (at very large banks) you can bet your bottom dollar there are a buncha others.
Thing is, it’s clear that quality has nothing to do with the way that “the enterprise IT language du jour” is chosen. We can know this b/c the choice changes so frequently, and for no obviously good reason.
Olle, I thought I should reiterate that I agree with you as to when and how one chooses to go with “the enterprise IT language du jour” (today, possibly, Golang). I’m just saying it in a more … brutal manner than you are.
To me, it’s about needing to get paid, and not having the luxury of telling your paymasters they can get lost [OK, I’d use a harsher four-letter word]. And it’s never going to be about something different. Everything else is just window-dressing – self-rationalization – for that basic need/problem/issue.
Definitely not true anymore no, but that’s mostly because IBM is not what it once was. The mentality is for the most part still there, just replace IBM with Microsoft or Google. Risk-averse people making non-decisions that they think others will perceive as right, regardless of whether it actually is. And there are certainly plenty of situations where that is the right decision for the person making it.
I’m a CTO and I have no issues to motivate my choice of OCaml to shareholders. Don’t over estimate inertia and risk aversion in the tech stack, most people will understand that using the right tool for the job is usually a good idea.
The cross-compilation and language-pure libraries story of Go is much better than that of OCaml, so Go makes sense when you want to write code and deploy it as a static binary to many architectures and platforms.
It’s also easier to not invoke the GC in imperative code in Go, which helps with latency-critical applications like userland network drivers. There was a study about userland network drivers across programming languages (OCaml, Haskell, Go, Swift, …) and the Go version did well for that reason. Keep in mind though that JSt folks work in a very latency-critical environment and they still use OCaml so when a company wants something done in a tech stack they’ll figure out ways around the stack to get what they want done
Worth noting that a language can be used as a DSL to generate highly specialized output cf. FFTW, and MLs are excellent at creating EDSLs, not sure Go can measure up there.
I’d go further and say that code quality is independent of which programming language you use. Or, to add some nuance, many code quality attributes are language agnostic.
A long time, ago, I read a paper by Jim Gray (from the 80s) that noted that studies of bug density had found that the density of bugs per line was the same across many programming languages. This would seem to argue that more succinct programming languages produce lower overall bug rates. Obviously, old work, and besides that it could have been wrong, lots has changed since then.
But one thing for sure: I think it’s pretty clear that the choice of language does matter: for instance, memory-safety matters – even though anything you can code in Rust, you can also code in C++, it’s clear that the Rust code will be less-buggy (for instance). I’d argue the same is true about strong static typing: it yields less-buggy programs. And I’d note that Golang does not lend itself to strong static typing – you use downcast from interface{} far too often.
I made my living debugging other people’s code for a lotta years, and languages that force programmers to use downcast a lot are going to produce more bugs than languages that forbid that.
And I think a good example of this is Rust, a language whose type system is very, very much like OCaml’s.
Sure, but my experience with PHP is that I can just enforce such a rule in the CI, using one of several available open source static analysers. So it’s not enough to look only at language level. That’s not how a modern stack looks like.
you need musl to be completely static with OCaml, and then OCaml’s static binaries in my experience were usually half that of Go’s. But I do understand that the comparisons I drew between the two were of toy projects, not larger ones. I imagine most of the deployed go code would also be small utilities in the size of my toy projects though.
That being said, even OCaml is no champion when it comes to static binary size, Zig and Free Pascal are. Zig also has a cross-compilation story as good as or even better than that of Go’s (considering Zig’s compiler is also a C compiler, so no equivalent of cgo stuff).
In research they talk about fault density and change impact analysis, if you wanna google-scholar it.