
Go is boring, and that’s fantastic - rauhl
https://www.capitalone.com/tech/software-engineering/go-is-boring/
======
cmrdporcupine
Enums, immutables, and generics aren't good because they're exciting. They're
good because they give us expressive tools to write descriptive, type safe
systems that manage state better.

I don't like "modern" systems because I have a fetish for novelty. There's
nothing novel about these concepts, they've been around since the 60s and 70s.
I like these tools because they improve my ability to reason about the code,
but more importantly they let the compiler and other static analysis tools
reason about my code.

I am getting old and lazy. I want the compiler to do more for me, not less.

What I see is a situation where Go is gaining traction from two communities:

a) people who attempted to build large systems at scale in dynamic late bound
languages like Python and Ruby and NodeJS etc, and hit the wall from a
performance and maintainability POV. I could have warned you...

b) people who came from the Java world and got frustrated with the language
and tooling there

People coming from a) especially but also b) to some degree will be perfectly
comfortable with Go missing the nicer aspects of modern static typed languages
because they never had them in the first place.

As for...

"Go doesn’t have a virtual machine or an LLVM-based compiler."

How is this any kind of pro or con? It's just an implementation detail.

~~~
pjmlp
Pascal sometimes in the mid-70's

    
    
        type
           state = (on, off);
    

Go in 2020, about 50 years later,

    
    
        type state int
    
        const (
            on state = 0
            off state = 1
        )
    

Yeah we don't need those modern features from PhD level languages.

~~~
ksec
Why Pascal hasn't caught on is beyond me. When I was a lot younger I thought
the world one day will be partly made by Delphi.

Now it is pretty much dead.

~~~
controversy
Didn’t have a free commercial grade compiler. Made it hard for hobbyist to
learn.

~~~
cmrdporcupine
Nobody did back then though. Getting a free C compiler before GCC wasn't easy.
Even commercial Unix systems shipped with licensing restrictions on their C
compilers.

I bought Pascal, and then Modula-2, for my Atari ST. They were cheaper or the
same price as a C compiler. Though C was a better choice for that system,
since the OS was written in it and the calling conventions, etc. were all C.

On the Macintosh (and Lisa before it), by contrast, Pascal was the way to go.

So I think part of the reason C won out over Wirth languages back in the late
80s was because it just "fit" better with the systems that were emergent then.
The swing towards Unix/Posix or Unix-like machines meant that the syscall
interface for most things was defined with C calling conventions, and most
example code was done that way.

And C++ also became quite popular, while the various object oriented Wirth /
Wirth-like languages were not well standardized or available.

~~~
controversy
I appreciate your comment. I think it proves the idea how important free
compilers and run times are. The web took off not due to C, but Perl. It was
free and came with many servers that people rented. After that came the 90s
with languages like Java and other free higher level languages. At the same
time free OSes like Linux allowed people to be more technical without cost.

By the time this came around, universities taught C++ or Java in their intro
to programming. Students used those. Then found the free version from
discussion with peers.

------
dmitshur
I’ve been very happily using Go the last 7 years (disclaimer, I’m employed to
work on Go as of 2 years ago), some random personal thoughts.

It’s interesting how a language can be boring and so fun to use at the same
time.

I guess I don’t want excitement at the language layer because there’s plenty
of opportunity for it in other layers.

A boring language to me means there’s usually roughly one way of doing
something, so you just need to write up that one thing and move on to the next
part of what you’re building, knowing the past part is finished. Once
something works well and has a good API, I almost never want to come back to
it and rewrite it with a different set of language features that I happen to
learn.

The process of writing Go is fun to me because starting with an empty Go
program to do a new task is always a refreshing experience, it’s easy to reuse
any past functionality that you’ve already created (or found) and you can
focus on the new task. In contrast, when I was primarily using C++, starting a
new codebase wasn’t pleasant because of all the housekeeping and boilerplate
(like defining a uint16 type in a platform-agnostic way) I needed to
copy/paste just to have a reasonable starting point.

Also, the feeling of gofmt/goimports running on save and formatting the code
on save is a huge part of what makes it fun (fortunately, code formatters are
much more commonplace now; I wouldn’t want to go back to not having them).

~~~
gcatalfamo
Since you work with go I have a question. I learned it superficially but I’d
like to get more fluent with it. Which resource would you suggest?

~~~
dmitshur
[https://learn.go.dev](https://learn.go.dev) lists many good resources.

The language spec at
[https://golang.org/ref/spec](https://golang.org/ref/spec) is a surprisingly
approachable one-pager, it’s worth at least glancing over.

One of my all-time favorites talks is
[https://vimeo.com/53221560](https://vimeo.com/53221560) from 2013. It shows
off how Go scales by starting with a small task and continuously adding more
requirements into the mix, while also demonstrating its concurrently support.

------
LandR
I sometimes wonder if Go is a long running by joke by Google.

Like someone internal at Google said people will use and adopt en masse
anything they make, regardless of how good it is.

Someone else said no way, a bet was made, and Golang was released. Ignoring
20-30 years of programming languge theory advancements. Yet everyone laps it
up.

And here we are today. I'm sure someone at Google is laughing.

I find Go completely tedious and inelegant to work with, its too verbose and i
think verbosity hides intention and expressiveness.

~~~
cmrdporcupine
FWIW it hasn't had much uptake within Google.

I think the sense that this is a "Google language" is exagerated. What it is
is a language created by a certain group of people at Google with Rob Pike at
its origin, and they would have created this language wherever they were
working. It's a continuation of the work they did on Limbo/Inferno, etc. not
something adapted for Google's needs, as it is sometimes advertised as.

So I'm in no position to criticize Rob Pike, he's a far smarter person than me
who has achieved a lot more than I ever will. But I also don't think Go solves
any problems that I have, and my one experience with going through Go code
review at Google turned me off the language probably forever.

~~~
vp8989
Can you elaborate, RE: the Go code review?

~~~
cmrdporcupine
Google has a "readability" restriction for reviewers/authors on CL
(changelists, I guess like a pull request). You need a reviewer with
readability in a given language to approve your CL before it can land. When I
first started, to get readability involved putting together a good archetypal
CL in the language, showing good knowledge of the language, lots of tests,
good documentation, etc. and then it would go into to a readability queue, get
reviewed, and you'd get your readability capability.

Go was different in that they had introduced an incremental readability
process. Instead of one CL, you had to do many, each reviewed by different
people, and over time after doing a whole bunch of CLs you could get
readability. This is the process that Google eventually adopted for all
languages, but they started with Go.

What I found was the Go reviewers were a) exceptionally pedantic [even by
Google standards] but, worse, b) very contradictory. One would chastize me for
using channels where they were unnecessary, so I'd remove their use and just
use simple functions but then a later reviewer would scorn me for not using
channels in the same code. It became a painful game of tennis. And the whole
thing had a feeling of ideology over practicality.

------
charlesdaniels
I think a lot of the commenters are missing the point.

Golang _is_ less expressive than other languages, like Rust or Haskell. You
can't create fancy custom types and things like that. Of course there are
drawbacks.

The benefit however, is that it's much harder to write "clever" code, which
translates into being harder to write unmaintainable code. If you know Go, you
can sit down at nearly any Go codebase and know what's going on pretty easily.
That certainly isn't the case for C or C++, and probably others (other people
have told me this is true of Rust, but I have not used it, so I will not claim
that).

Golang is not the fastest, or the most expressive, or whatever else. But it's
got enough expressiveness to not be painful for most use cases (slices, maps,
and structs cover a lot of ground). It's fast enough for most use cases
(faster than most scripting languages).

In my opinion, Golang has a very good ratio of (effort required to learn) /
(utility of learning). I have no doubt that Haskell is extremely powerful...
if you can learn how to use it.

I wouldn't be signing up to write a new OS kernel in Go, but for a userland
program that doesn't have hard-RT requirements? I think Go strikes a better
balance compared to C, C++, Java, Python, and others.

~~~
thatswrong0
> The benefit however, is that it's much harder to write "clever" code, which
> translates into being harder to write unmaintainable code. If you know Go,
> you can sit down at nearly any Go codebase and know what's going on pretty
> easily.

I don't think this necessarily follows. I don't think "clever"ness is what
makes code unmaintainable. You can still create a tangled mess in Go just as
easily as other, more expressive languages. In fact, I think it's more likely
in Go simply because you _have_ to write more code in Go. More code is more
maintenance. Go encourages you to repeat yourself and to not create / use
abstractions. Nil pointers are still a thing. It's incredibly easy to
accidentally shadow a variable and not handle an error. These are all solved
problems in other languages, yet they persist in Go, and they are all
maintenance headaches.

~~~
cloverich
> I don't think "clever"ness is what makes code unmaintainable. You can still
> create a tangled mess in Go...

It's not the only factor, but it is certainly _a_ factor: "Clever code" is
typically meant as derogatory. Fancy abstractions for simple use cases is a
common cause of tech debt IME, and harder to unwind than under-abstracted code
(tedious as that is to fix).

~~~
shaan7
> It's not the only factor, but it is certainly _a_ factor: "Clever code" is
> typically meant as derogatory

Yep, but here's the thing - if the problem is misuse of the tool, then the
solution should be to not misuse the tool. Saying "we will remove features
because some people misuse it" is like saying "we will remove headlights from
cars because some people drive irresponsibly[1]".

Go remains my language of choice if I have to build efficient webservices, but
I really feel sad when people make it sound like Go is awesome because it
misses language constructs. No! It is awesome because it is FAST (quite near
C) but it is very easy to do simple things like writing http servers, parsing
JSON and so on (like Python et al).

[1] [https://timesofindia.indiatimes.com/city/bengaluru/high-
beam...](https://timesofindia.indiatimes.com/city/bengaluru/high-beam-menace-
over-5000-cases-booked-in-four-months/articleshow/58691189.cms)

EDIT: fixed typo

------
melvinroest
> But the people who design and build bridges, they're great at it. Bridges
> get built _on time, on budget_ , and last for dozens, hundreds, even
> thousands of years. Bridge building is, if you think about it, kind of
> awesome. And bridges are such a common occurrence that they’re also
> incredibly boring. No one is amazed when a bridge works correctly, and
> everyone is kind of amazed when software does.

Emphasis mine was added by me.

Sorry, source needed. You're a software developer, not a bridge builder. Yes,
bridges in my country seem to work, fair enough. But I have the faintest clue
if the design/building process really is going that smoothly. To write this
down as a fact to build your argument is IMO a pretty big assumption.

~~~
buster
Especially if you consider the state in which some infrastructure is around
the world. I'm impressed to see the occasional aqueduct from 2000 years ago in
Europe, but i also see the occasional modern bridge collapsing in the same
country ([https://www.theguardian.com/cities/2019/feb/26/what-
caused-t...](https://www.theguardian.com/cities/2019/feb/26/what-caused-the-
genoa-morandi-bridge-collapse-and-the-end-of-an-italian-national-myth)). From
what I've heard and seen, infrastructure in the US (roads, bridges) isn't
exactly the example for "build once, use for thousands of years".

And that's not even considering how many of those road or bridge building
projects really are in time and budget.

------
grey-area
Being boring really is what I love most about Go. It doesn't change much and
there is a culture of simplicity, so it's quick to onboard new devs and there
isn't a lot to get your head around. That also makes it good for building
large projects, as the complexity is in the domain and the application, not
clever uses of the language itself.

I almost wish they'd make it more boring and take a few things out, but it's
probably too late now to change the language much and people would complain
vociferously. Things I never use and wish it didn't have: panic, goto, labels,
struct tags, executable comments, even arrays.

The only things I'd like to see improved significantly are enums, errors, and
user-space generic collections (coming soon!).

~~~
cy_hauser
> generic collections (coming soon!)

You and I must experience time differently. I read a couple days ago that the
end of 2022 would be the earliest they might appear but probably further out
than that.

~~~
grey-area
I've been using it about 8 years at work, and don't mind if they take another
year, it'll take a while to work into large code bases anyway. Personally I've
felt generics as a lack but not a huge unfillable hole, and prefer language
stability to churn, so am completely fine with it taking time to add large
features. I'm pleased with the evolution of the generics proposal so far -
it's getting simpler and more transparent.

I really wish in their mooted Go 2 they could just remove some features, as
listed above, rather than add some. Perhaps everyone prefers a slightly
different subset of the language though so that isn't really possible.

------
jherdman
Boring technology that does great things has been a huge part of my career for
the past eight years at Precision Nutrition. With that said, the following
opinions are mine and mine alone.

Here are some boring choices we made that paid dividends:

1\. Postgres. It does what it does, it's stable, it's reliable, and continues
to improve as time goes on. 2\. Ember. It's by far the most stable front end
framework going. It's made our job easy in uncountable numbers of ways. 3\.
PostCSS. Write plain CSS, use modern features, remove plugins as browser
support grows.

A few years ago I'd have said Rails was a boring technology we chose too.
These days I'd say it's a bit of a thorn. It's clear that some of the magical
choices made make long term maintainability challenging, as are some of the
performance characteristics. A few of the libraries used by the community have
bitten us hard too insofar that they're either a maintenance nightmare, poorly
maintained, or exceptionally difficult to migrate away from (e.g. CanCanCan,
Active Model Serializers).

These days I'm playing with Elixir, which is also boring but allows you to do
exciting things. I especially appreciate ExUnit having come from the RSpec
world — assert, refute, end of story.

~~~
brendanmc6
I'm a frontend dev and amateur solo founder interested in tools that empower
me to build more with less effort. Should I finally bite the bullet and learn
Postgres/SQL? I have the (ill-informed) impression that it's better suited for
large and complex systems whereas I'm mostly building SaaS and simple
e-commerce apps.

Aren't there usually full-time SREs focused on managing and maintaining SQL
databases? I can get really really far, really quick with Cloud Firestore (for
free at my scale), and stay focused on my frontend. But as complexity grows
and requirements change I can sometimes find myself in sticky situations--
mostly because there are no tools for schema migration in Firestore.

But on the other hand with Firestore and similar noSQL products I can get
scaleability, security, speed, stability and a lot more all out of the box.

Curious to hear your input.

~~~
leetrout
Not OP but you will get far with Amazon RDS or another hosted Postgres
offering if you can afford it.

I'm always terrified of ecomm using NoSQL for carts and transactions but I'd
say it's overblown on my part I just prefer to rely on the durability of a SQL
database using guardrails at the schema level to keep my data correct. Either
tool is easily misused but Postgres really can handle a lot it just doesn't
get the shiny attention some other host services do because it doesn't over
promise things you probably won't need to use. That said, you can do really
slick NoSQL style stuff with Postgres HStore and JSONB columns.

There are a lot more data-store-as-a-service offerings for NoSQL but I don't
find any of them particularly beneficial for "plain" apps but agree you can
get started a lot faster. Firestore is a lot of fun when you need things to
sync between clients and there are tools to do the same / similar with
Postgres (noted below).

[https://www.postgresql.org/docs/12/functions-
json.html](https://www.postgresql.org/docs/12/functions-json.html)

[https://www.postgresql.org/docs/12/hstore.html](https://www.postgresql.org/docs/12/hstore.html)

[https://github.com/PostgREST/postgrest](https://github.com/PostgREST/postgrest)

[https://github.com/diogob/postgres-
websockets](https://github.com/diogob/postgres-websockets)

[https://github.com/supabase/realtime](https://github.com/supabase/realtime)

------
rchaves
> Among compiled languages, garbage collection is rare

??????

> Rust's borrow checker is a fascinating way to get high performance and
> memory management, but it effectively turns the developer into the garbage
> collector, and that can be hard to use correctly

Isn’t the whole point of rust that you cannot get memory management
incorrectly because compiler guides you?

> all Go code is formatted the way that go fmt says code should be formatted.

just like rustfmt, elm-format, prettier and I hope most modern or future
languages

I agree with his main idea, I also like the idea of a boring language, but
then his arguments misses the point completely, talking about benchmarks and
such.

He should talk about why having no exceptions can be a good thing, or having
no generics.

Having a very small API surface and stable language is one of the reasons I
love Elm as well, nobody is able to do too smart abstractions with monads and
such, it’s about code, readability, explicit better then implicit, etc,
nothing to do with garbage collecting, performance, blablabla

~~~
leetrout
I worked at a shop where there was some Ruby code and autoformatting was
argued against from one of the senior tech leads because "[ruby] wasn't
designed for an autoformatter. go was built that way"

Absolutely blew my mind. I love go fmt, prettier, black, etc and cannot
understand why people still love to argue over styling at this point. I get
that he was saying the formatter ships with Go but I don't subscribe to the
idea that you can't use an opinionated formatter because the language authors
didn't make one.

~~~
recursive
I can kind of understand it. If it's a first class part of the language, then
it's never going to get painted into an ugly corner.

As a nearly related example, the LESS css pre-processor language was developed
prior to `calc()` expressions. As a result, the LESS language parses
arithmetic expressions. So `calc(10em + 10px)` compiles to `calc(20em)`. So in
order to do `calc()` expressions, you have to use nasty hacks like `calc(10em
~"+" 10px)`. If LESS "shipped" with CSS, this wouldn't have happened.

~~~
leetrout
I see your point. I think that's a little apples-to-oranges because LESS
transpiled to CSS - it wasn't a formatter for CSS.

~~~
recursive
In the analogy, there may be a new language feature that breaks assumptions
made by a 3rd party code formatter.

------
stephc_int13
>There are a few things that we have learned in the last 60 years about
writing programs where there is pretty much universal agreement:

>We agree that it's better to find problems earlier rather than later.

Agreed.

>We agree that people are awful at managing memory in programs.

Nope, manual memory management can be done properly and this is not rocket
science.

>We agree that code reviews help find bugs.

Sure, but this is not the only way and not always the most efficient.

>We agree that on any project that requires more than one person,
communication costs dominate.

Nope, this is a blatant over-generalization.

~~~
zeveb
> Nope, manual memory management can be done properly and this is not rocket
> science.

Outside of NASA (often, _literally_ rocket science!), where has manual memory
management ever been done properly? I don't think that it ever has. For that
matter, I would be unsurprised if even NASA had manual memory management
failures.

~~~
cyb_
Even NASA apparently has rules against dynamic memory management in critical
systems.

> 3: Do not use dynamic memory allocation after initialization.

[https://sdtimes.com/nasas-10-rules-developing-safety-
critica...](https://sdtimes.com/nasas-10-rules-developing-safety-critical-
code/)
[https://news.ycombinator.com/item?id=4339999](https://news.ycombinator.com/item?id=4339999)

~~~
blibble
high performance trading systems use the same approach

(of course: failure is less catastophic than it would be for NASA!)

------
untog
Obviously this is all a matter of opinion but I don't consider a lack of
exceptions, enumerations and generics "boring", I just consider them to be
missing features.

Certainly there's an argument to be made for simpler languages being better
(maybe we should all be writing in Assembly?) but I'm personally not
convinced.

~~~
isp-localhost
I hear these sorts of arguments often, as someone who likes both Go and C I do
have some responses: I would hardly call exceptions in C++ a "feature" but
more of a "liability." Enumerated types (probably referring to sum types here)
have trade offs that are not necessarily clear from simply _reading_ the code.
Generics often lead to code which is (IMO) difficult to follow, debug, and
reason about. The point about assembly is jest? Or dishonest? I would argue
that C, C++, Go, Haskell, etc etc are "simpler" than assembly, if they weren't
we probably would be writing assembly, and I suppose following that logic
maybe we'd be hand constructing opcodes with a two key keyboard.

------
throw_m239339
Go is like C. AKA roll your own unsafe type system at runtime with void
pointers (or interface {} in Go). This isn't acceptable for a language
released 10 years ago. On one hand you have a rigid type system very limited
in terms of polymorphism, on the other hand with interface {} anything goes,
even creating Adhoc functions at runtime.

Go should have taken cues from ADA and how it implements generics. There is
enough polymorphism to solve most cases where generics are useful, but also
enough limitations so that a codebase isn't cluttered with `Type A<Type
B<C,D,Type E<F,G,H>>>` horrors everywhere.

------
pif
Shaw's Principle: Build a system that even a fool can use, and only a fool
will want to use it.

[https://www.angelo.edu/faculty/kboudrea/cheap/cheap3_murphy....](https://www.angelo.edu/faculty/kboudrea/cheap/cheap3_murphy.htm)

~~~
moreaccountspls
You think everyone building tools like k8s, terraform, etc. are fools? That's
a pretty myopic worldview.

~~~
erik_seaberg
Terraform is I/O bound on cloud provisioning APIs (its CPU performance doesn't
matter), and its complex object models need to be extensible. Python would
have been a better choice.

~~~
jen20
As a former maintainer of Terraform, I 100% assure you that Python would have
in no way been a better choice.

While Terraform is I/O bound to some degree, it has a large degree of
concurrency - something quite miserable to do in Python.

Terraform does not take full advantage of even the type system available in
Go, but a dynamic language would make things even worse. I do not think Go is
the ideal language for programs like Terraform, but having spent many
thousands of hours in that codebase now, the answer is stronger types (likely
Rust), not fewer.

~~~
erik_seaberg
I'm currently generating bloated JSON templates because writing any kind of
non-Go plugin looked like a painful ordeal.

------
ed25519FUUU
My favorite thing about Go is that I can jump into _any_ codebase, written by
any developer, and the mental load required to unwrap their logic is very low.

The "stylistic opportunity" for other languages is such that I can usually
tell which developer on the team wrote what just at a glance. Not so with Go.
It's all the same bland but beautiful gray.

Something to be said about languages that help _external_ people understand
them, as opposed to languages developed to improve developer satisfaction.

~~~
didip
I agree with this opinion, code review burden in Go is so little.

------
__tg__
Re. the bridge analogy in the article: we had a bridge being built behind our
building at work and they had announced the opening date a year in advance.
Sure, when the date came the bridge was opened exactly on time. I was walking
with my colleague across it and asked him, "How come we can't ever predict
when we'll be done?". His answer was deeply insightful: "They build the same
bridge every time while we build a different one".

------
nikki93
The manual memory management thing -- like needing GC -- feels like a false
dichotomy. Most of these languages that have GC need you to "manually" manage
resource lifetimes anyways for a lot of resources: files, network connections.
If you're making a UI, you think about when components are mounted and
unmounted. The logic for all this is domain logic and part of the code for
your program. Memory is just one such resource, and I think there should be
more acknowledgement of it as such by languages, instead of just piling it up
and kicking a "GC cycle" to clean it up whenever, leading to pauses in
interactive programs and whatnot (Go's GC, and Go in general, do not perform
well under WASM in my experience).

In Go you have to "manually" defer a file.Close() call -- vs. the destructor
getting automatically called in C++ (it even gets automatically called when a
containing object is destructed, if it's a member, and so on). Go's version
doesn't seem very "automatic" to me.

The simplicity of Go actually hides a lot of runtime complexity that is
happening: the GC, map lookups, scheduling of goroutines and so on. Which you
have to understand and then ultimately learn how to tune from a distance
(because you don't have direct control) for a lot of applications where it
matters. For server applications (where the hardware is under your control)
and also CLI tools (which can just run, only allocate memory, then just exit),
this matters less. If your code is running on user's devices as an interactive
application, it feels to me like how it performs on and uses their actual
hardware is part of your responsibility as the developer, and some things
about Go make that harder to do. Like you have to think about the GC and try
to avoid it ("from a distance") if you run into that (which you do quickly in
WASM, and which eg. Gio tries to explicitly design around, and so on).

I want to see languages that care about simplicity and also include such
deterministic resource management as part of their design and offering.

~~~
coder543
> In Go you have to "manually" defer a file.Close() call -- vs. the destructor
> getting automatically called in C++ (it even gets automatically called when
> a containing object is destructed, if it's a member, and so on). Go's
> version doesn't seem very "automatic" to me.

To clarify this one point, Go allows you to attach a destructor (finalizer) to
an object, but since the language is garbage collected, there’s no guarantee
of when the destructor will be called, if ever, since disabling the garbage
collector is entirely possible, even if not advisable.

The File object will Close the file when the Finalizer runs, since the
standard library attaches a finalizer to it, but you should defer the Close to
deterministically ensure that the file is closed when you expect it to be
closed, and to free that OS resource of a file handle as soon as possible,
since some OSes limit how many you can have at a given time. Finalizers also
won’t be run when the program exits, which is fine for most things, but you’ll
want to have ensured any buffers were flushed before then, and defer can
guarantee that.

Languages like Rust and C++ have deterministic destruction at the end of a
given scope thanks to RAII, so it makes sense for them to lean more heavily on
destructors there.

Java File*Stream objects should have “close()” called on them, from what I’m
seeing on a Google search, so this doesn’t seem to be a surprising pattern for
a garbage collected language. I know in Python you’re encouraged to use a
“with” block to ensure that file objects get closed.

[https://golang.org/pkg/runtime/#SetFinalizer](https://golang.org/pkg/runtime/#SetFinalizer)

------
sandGorgon
One of the questions that i have always wondered about is how do financial
companies work with math libraries in any language other python - which not
only has the entire math/statistical software mindshare..but pandas/scipy +
BLAS/LAPACK is optimised to its gills in Fortran.

For e.g. Monzo engineers have tweeted that they had to create an internal math
library -
[https://twitter.com/_liclac/status/1264142576908722178](https://twitter.com/_liclac/status/1264142576908722178)

Once you bring Pandas, Scipy, LAPACK/BLAS, Numba/Cython into play...then i bet
these benchmarks look a lot different.

------
ladyanita22
From what I'm reading, I fail to see how Go is faster than other languages. It
actually seems pretty bad.

In the article, it is said to match Java. In the Benchmark Game, it is
certainly not among the fastest.

~~~
didip
In my experience, Go gives a perception of faster than Java because the GC
pause on average is really quick compared to a decently tuned G1 GC.

~~~
erik_seaberg
Go's GC has always had pretty low throughput compared to a JVM, but with value
types (which Java doesn't have yet) it can be faster if you manage to keep
everything on the stack.

------
k_bx
Go _does_ have subtyping (unlike Rust and Haskell), which makes type system
needlessly more complicated and type inference harder.

~~~
atombender
Go doesn't have subtyping, only implicit coercions. Not the same thing.

~~~
k_bx
Right, thank you for this correction! I've just spent some more time with Go,
looks like I was wrong and it has something closer to Type Classes (or
Traits), but not subtyping.

// Too bad editing is not available anymore

------
empath75
IMO, the thing that makes go good, from an enterprise point of view, is that
you can take a team of mediocre coders who have never used it before, and
deliver working code quickly. It might be ugly, it might be dumb, but it'll
get the job done, and will generally be easier to maintain than python or ruby
in the long run and with good performance.

I think a few things contribute to that:

1) Relatively few language primitives -- it takes like a day to learn 90% of
the keywords you'll be using day to day.

2) Transparency -- it's easy to look at any code base, and track down all the
relevant code, even without an ide. Compared to a language like ruby, there's
not a lot of 'magic' happening.

3) Conciseness. Unlike a lot of statically typed languages -- go code isn't
verbose. It's statically typed, but the inference works well enough that
you're very rarely having to use type hints all over the place -- Java has
started to be more like this, but back when go started, it was a breath of
fresh air.

4) Kubernetes. If you want to build on top of k8s, go is pretty much the only
game in town. It just makes everything eaaier. Other languages have k8s
support, but any language other than go will have more friction.

5) Go channels and concurrency -- I actually don't think this is that
important, but knowing that it's available if you have that kind of
performance demand is nice.

~~~
pansa2
> _Conciseness [...] you 're very rarely having to use type hints all over the
> place_

This hasn't been my experience. When I tried porting some Python code to Go, I
found it wouldn't compile without lots of type casts (mostly between different
integer sizes and signedness).

~~~
empath75
yeah, but python isn't statically typed. I'm comparing it to java.

~~~
cultus
It really shouldn't need any type annotations. A Hindley-Milner type system
would have been more flexible and require no type annotations (as well as far
less interface {} and unsafe casts), and still support everything Go has. The
language as a whole seems to just commit all of the mistakes of C, except with
garbage collection.

------
zaphar
I wonder what the actual statistics on bridge building are. Are they really
typically done on time and on budget? How many times do the drawings or
engineering specifications for a specific bridge have to change while getting
built to adapt to new information?

We trot out this particular analogy all the time in software engineering and I
can't remember ever seeing any real data to back up the assertions.

~~~
corty
From having lunch with guys from the mechanical engineering department (they
were right next door at uni) my anecdotal second-hand wisdom is: Most larger
engineering projects are as broken, tedious, expensive and unpredictable as
most software projects. You will always find unsteady ground that nobody told
you about, new last-minute requirements, shitty subcontractors making a mess
and substandard parts that happened to be cheapest on the tender. From what
I've heard, around 2 in 3 projects are over budget or over time in a
significant way because something was massively screwed up somewhere and
needed to be hotfixed, patched, rebuilt or -my favourite- reevaluated to be
statically sound without structural changes.

I think the common software engineering myth about "real engineering" being
somehow better and something one should aspire to is just really a myth.

------
exabrial
...functions returning multiple parameters, confusing operators that are
different 'just because', types on the right hand side instead of the left
'just because', I don't think GoLang is solving as many problems as it
creates. It's different because being different is cool, not because it solves
any sort of practical problems.

If I were going to go learn some strange non-C-like-outer-worldly-syntax, I
think your effort is best spent learning Rust, which is way faster, offers
some strong failure guarantees, and fills a lot of use cases from embedded
systems to WASM.

------
hyperman1
It strikes me how this gives a value proposition for go that is very similar
to COBOL: Easy structure, predictable to build and run, minimize individual
coding style differences,....

Not necesarrily disparaging for either lanfuage, as COBOL, boring as it is,
has brought tremendous value in large scale software engineering.

There are of course big differences too, like i18n, variable width strings,
... But if you give COBOL a c-style syntax,some dynamic size data structures,
and you squint a bit, you end up quite close to Go

------
oconnor663
> Go doesn’t have generics.

> And Go hasn’t added any major features since Go 1 was released in 2012.

Isn't Go in the process of adding generics as we speak?
[https://blog.golang.org/why-generics](https://blog.golang.org/why-generics)

------
roryrjb
But is Go boring? I'm less interested in language syntax and semantics than I
am about the runtime. I mean this generally and with all languages. Yes Go the
language is simple and boring but the runtime, to me at least seems somewhat
magical. By that I'm really talking about the concurrency. A lot of people
sell Go by talking about Go routines but to me it's the one thing that makes
me wary of adopting it. I'm very uncomfortable just blindly using concurrency
features and not really knowing what's going on underneath.

------
jrockway
> Go doesn’t have ... an LLVM-based compiler.

[https://github.com/tinygo-org/tinygo](https://github.com/tinygo-org/tinygo)

~~~
todotask
Yes, it's not part of Go standard library [https://tinygo.org/faq/why-a-new-
compiler/](https://tinygo.org/faq/why-a-new-compiler/)

------
ssorc3
'Go doesn't have immutables'? So it has mutability then. How does that affect
how 'boring' a language is? Surely immutability is simpler.

~~~
tsimionescu
Immutability is much more difficult to reason about except for some very mathy
problems.

It is extremely natural to think in terms of state, so much so that almost all
algorithms you'll find in computer science are commonly expressed in
imperative terms.

~~~
erik_seaberg
In a concurrent language, shared mutable state is the trap that Hoare's CSP
book was urging us to avoid. Worse, in Go builtin maps are always writable yet
parallel writes and reads can segfault. There's a sync.Map type but it isn't a
drop-in replacement (because builtin maps don't implement any interfaces) and
it isn't typesafe (because no generics).

~~~
tsimionescu
Yes, Go has very bad primitives whichever way you look at them. I still think
you can't say a language with built-in immutability is more boring technology
than one with built-in mutability.

There's nothing stopping you from using Go's maps without mutation. You can go
ahead and send copies of maps through channels, just like you would if they
were really immutable. Sure, the interface is clunky, but so is every other
interface in Go, so I don't see too much reason to complain here...

------
entha_saava
Maybe, Idk who that appeals to.. But Go lacks the even most trivial of array /
slice manipulation functions. Is this loop an index() or apply() or filter()
or count() or sum() or wutt? Don't even talk about generic data structures.

To be fair, Go authors are pretty smart having created something more usable
than C while not even seriously looking at how things are done in other
languages.

------
carapace
If you were trying to choose between Go, D, Nim, and Zig for a general-purpose
compiled language, what are the criteria for differentiating and what are the
pros and cons of these languages? Are there other languages that should be
included in this list? (Common Lisp?)

(FWIW, chief on my list of criteria is the "debug story": what kind of hell am
I in when things inevitably go wrong?)

~~~
kazinator
To make things interesting, can we add the following choice: wading chin-deep
over a half-mile wide tract of land flooded with raw sewage, to reach a C
compiler.

~~~
carapace
I'm coming around to C-with-good-tools as a decent option. It's _everywhere_
and it's been studied and meta-programmed to death and back again.

------
jdonaldson
There's been other boring, fantastic languages... Lua comes to mind. There
also always seems to be one or two "crippling" missing features for these
kinds of languages as well. I actually think it's a good thing! We should stop
adopting one-size-fits-all thinking.

------
konart
>You don't have permission to access
"[http://www.capitalone.com/tech/software-engineering/go-is-
bo...](http://www.capitalone.com/tech/software-engineering/go-is-boring/") on
this server.

oh...

------
kockic
I think the main advantage of go is it's learning curve. Standard lib is quite
small, so even with no experience, in a few weeks you could be fully
productive on any go code base. With e.g. C, Rust, Java, Ruby this would
probably be months.

------
corty
While the article overall might not be totally wrong, at least two details are
dead wrong.

Go DOES have a virtual machine, thats what gives you all the lightweight
threads and garbage collection. You may call it "runtime", but there is no
difference between a heavyweight runtime or a lightweight VM.

And go DOES have exceptions, thats what panic does. The are just used less
frequently than in other languages (e.g. Java, where even the happy path may
contain exceptions, e.g. in Swing).

~~~
efficax
A "runtime" is not a virtual machine anymore than the standard c library is a
virtual machine... it's clear what virtual machine means in this context: an
abstraction layer between machine code and program code that translates one to
the other at runtime.

~~~
corty
By that argument a x86-VM running on x86 is not a VM because there is no code
translation in between.

~~~
lostmsu
Words can have different meanings in different contexts.

~~~
corty
Yes, but here they don't. A VM is a non-physical machine that executes
instructions. Nothing more, nothing less. And yes, this means that even a
library might be considered a VM. I don't see why people get so wound up about
that.

~~~
lostmsu
Because half of your point is nonsensical without that stretch of the meaning
in regards to VMs.

Go programs do not run on a VM. They run on a specific CPU architecture, and
specific OS. You would need an actual VM to run the same program on something
different. That is unlike Java which on its own is a VM to run programs on.

I would argue the other half of your point is nonsensical in the same matter.
You just conflated two different definitions of exceptions, which are similar,
and have intersections, but not identical.

------
drewcoo
Coding Go is like an old bridge. Because almost all Go code will be removed or
replaced in short order. And only a very few survivors will still exist years
from now to feed the confirmation bias of "history."

That analogy should go the way of most old bridges.

------
tapirl
> Go doesn’t have immutables.

Declared functions in Go are immutables.

------
imagetic
Capital One is probably the worst endorsement possible.

