
Have Static Languages Won? - tbirdz
http://pointersgonewild.com/2015/11/25/have-static-languages-won/
======
dugword
"Dynamic languages are at a disadvantage. Most of the mainstream ones out
there today were designed by amateurs, people with no formal CS background"

Patently false. * from Wikipedia

Python: Guido van Rossum * Master's degree in mathematics and computer science
from the University of Amsterdam * Recognized as a Distinguished Engineer by
the Association for Computing Machinery

Ruby: Yukihiro Matsumoto * Graduated with an information science degree from
University of Tsukuba, where he was a member of Ikuo Nakata's research lab on
programming languages and compilers

JavaScript: Brendan Eich * Brendan Eich received his bachelor's degree in
mathematics and computer science at Santa Clara University. He received his
master's degree in 1985 from the University of Illinois at Urbana-Champaign.

Perl: Larry Wall .... Well I guess he doesn't have a formal CS background. But
he was literally a NASA rocket scientist.
[https://en.wikipedia.org/wiki/Larry_Wall#cite_ref-3](https://en.wikipedia.org/wiki/Larry_Wall#cite_ref-3)

~~~
rbehrends
You can also add:

Lua: Roberto Ierusalimschy * Associate professor at PUC-Rio.

Tcl: John Ousterhout * Professor of computer science at Stanford (and
professor of computer science at Berkeley when he invented Tcl).

Plus, Python's design was based on a teaching language (ABC) that was designed
based on actual usability research.

And, of course, this does not even count the classics (LISP, Smalltalk,
Scheme) whose authors have pretty impressive academic pedigrees and whose
designs inspired many of the more recent languages (e.g., the influences of
Smalltalk and LISP on Ruby are pretty obvious).

------
realharo
> _You can have statically compiled languages that use type inference to
> realize what is effectively dynamic typing._

Just because you don't have to explicitly write out the type does not make it
any less static.

I believe that the usual arguments against languages with static typing such
as verbosity and lack of flexibility are largely eliminated by the more modern
languages such as Scala, Kotlin or Typescript (though typescript is more
"optional typing" than static really).

~~~
coldtea
> _Just because you don 't have to explicitly write out the type does not make
> it any less static._

No, but not having to write the type was one of the biggest attractions of
dynamic languages -- a lot of us didn't care that much for being fully
dynamic, but just enjoyed the less ceremony of dynamic languages.

As for not having to commit to types for some cases, STL languages can also
have a "void *" or "variant" or "dynamic" type (a la C#).

~~~
nrinaudo
There is one other undeniable advantage to dynamic languages: you can express
things in a dynamic language that you can't in a static one. Static languages
try to be as sound as possible, at the cost of some completeness. Dynamic
languages are less concerned with soundness and can be more complete.

As an example, duck typing is usually not possible to achieve in a static
language - it's really hard to allow duck typing and remain sound (I don't
actually know that it's possible, but I'm not sure either way).

Having said that, I'm firmly of the opinion that static languages are much,
much easier to write in and maintain once you get the hang of whatever type
system they use, and the loss of completeness is acceptable for all the
benefits they bring.

~~~
realharo
Question is, how many real-world cases there are where duck typing is super
beneficial. Usually if you need a bunch of differently-typed objects to
fulfill the same contract, you can just make them implement an interface (said
interface can also be documented, etc., it makes the intent very explicit).

I do believe there are cases where dynamic typing is genuinely useful, but
those make up a very small portion of real-world problems.

~~~
nrinaudo
I agree that duck typing is rarely critical, you can always work around it
when you find you'd like to have it.

On the other hand, I disagree with the scenario you describe: if you have
multiple types _that come from an external, closed-source library_ , you won't
be able to have them extend a new interface. If you're lucky and they've not
been marked final, you'll need to wrap them in another type that extends the
right interface, then unwrap them... not at all impossible, but a lot of
boilerplate.

The best solution I know of is type classes, in languages that support them.

~~~
sanderjd
Those sound like implementation details of a specific language (C# I'm
guessing?) rather than a fundamental attribute of statically typed languages.

~~~
nrinaudo
I don't think so, but I'd be happy to be proven wrong.

If you have a function that expects a type A, and you want to pass an object
of type B that doesn't have A as a supertype, I don't know of many ways to do
so. Either you wrap your B in a type that extends A, or you create a new
implementation of B that extends A (this is often the same solution as the
first one), or you use type classes or some variant of the concept. Is there
an other option that I'm not seeing?

~~~
drewgross
In Haskell, you declare that a type is an instance of a typeclass, and provide
implementations for the required functions. You can do this anywhere for any
type. Then, you have your functions accept any type that is an instance of you
typeclass you need. Go has a vaguely similar concept. This is incompatible
with subtyping, but not incompatible with static typing, and is one of the
reasons fans of functional programming languages can so derisive of languages
that allow subtyping.

------
eadz
> _Dynamic languages such as PHP, JS, Python and Ruby, in addition to being
> relatively poorly designed, are the languages that powered the explosion of
> the web_

The author seems to paint a broad brush in saying all dynamic languages are
poorly designed. Languages can have different design goals.

From Matz, Ruby's creator;

> _Instead of emphasizing the what, I want to emphasize the how part: how we
> feel while programming. That 's Ruby's main difference from other language
> designs. I emphasize the feeling, in particular, how I feel using Ruby._

(
[http://www.artima.com/intv/rubyP.html](http://www.artima.com/intv/rubyP.html)
)

So one of Ruby's primary design goals was programmer happiness, and in that
respect it isn't not poorly designed at all. The technical 'perfection' of a
programming language only matters to a point, it's us as programmers people
that have to speak its language all day, and optimising for how we feel doing
it is a valid design goal.

I don't think it is a valid criticism to say something is poorly designed,
without looking at its design goals. Every language is poorly designed in one
way or another.

------
chaotic-good
No, they didn't. This article is narrow minded and prejudiced. Of cause if
we're talking about programming in general - static typing languages are often
a better option. But programming doesn't ends there, there is technical
computing, statistical computing, data analysis and so on. How about beating
Python + numpy + pandas in data crunching or maybe R in statistics? In this
fields underlying data types is almost always very simple, and because of this
you simply can't benefit much from static typing.

This is not about expressiveness (the article author is wrong here IMO). It's
all about flexibility and (more important) interactivity. I can do useful
things in ipython console or in ipython notebook in the browser. It's like a
tiny lab for small and moderately sized things, data munging, analysis and
visualization, prototyping and all this stuff.

There is dynamic languages like Python, R and even MATLAB that's not going to
disappear anytime soon. There is a new dynamic language called Julia that's
only starts getting traction but IMO it's already more interesting then Rust,
Go and Nim combined together.

~~~
bostik
> _How about beating Python + numpy + pandas in data crunching_

I'd think this sentiment misses a small bit of context.

In the above combination, Python is the glue language, which merely makes it
easy to dispatch the heavy lifting. Numpy is a damn good convenience wrapper
around the under-the-hood number crunching engines - which themselves are
written in static languages.

I mean, have you ever tried to _build_ numpy from scratch? That thing pulls in
both BLAS and LAPACK, some of the most heavily optimised libraries in the
world. These fortran(!) libraries can trace their ancestry all the way to
1970's, and have benefited from aggressive optimisations done over the course
of 4 decades. [0,1]

So, invoking numpy as a testament to power of dynamic languages misses a
pretty important point. And I say that as someone who loves Python, and uses
it as a first-choice tool in perhaps 90% of use cases.

0:
[https://en.wikipedia.org/wiki/Basic_Linear_Algebra_Subprogra...](https://en.wikipedia.org/wiki/Basic_Linear_Algebra_Subprograms)

1:
[https://en.wikipedia.org/wiki/LAPACK](https://en.wikipedia.org/wiki/LAPACK)

~~~
Veedrac
> So, invoking numpy as a testament to power of dynamic languages misses a
> pretty important point.

I don't think so. People build Numpy in a different language to the one they
expose it in because those languages have different strengths.

If Numpy's source languages (including BLAS and LAPACK) were suitable for
front-end usage, Python would have never entered the equation.

I think it's more a testament that _despite_ the base libraries being so
freely accessible, only dynamic languages have actually built front-ends that
people want to use. Even Julia is dynamic.

------
fulafel
Another perspective is that dynamic application programming languages were
always the underdogs. Corporate Cobol/Java/C#/C++ programmers always
outnumbered application programmers in dynamic languages outside the ad-hoc
web scripting languages (PHP & JS).

Clojure & other Lisps, Python, Erlang, Lua, and Ruby are all application
programming languages first and web languages only incidentally (1). They all
have clear strengths and are miles away from the horror of JS and PHP.

I think it shows in the article that the author's thinking on dynamic
languages is colored by Javascript and its propensity to hide bugs. This is
worrying since it might signal that JS does this for many people :(

(1) Admittedly Ruby is more strongly associated with Web nowadays due to
Rails.

------
hawski
Article points to [http://wtfjs.com/](http://wtfjs.com/) to show "glaring
flaws" of JS. JavaScript is not perfect, but almost all what is presented on
sites similar to wtfjs.com are non-issues to me. It may be stupid or
surprising that API behaves in some ways, but as long as it behaves exactly as
in documentation it is not much of a problem. I always check available
documentation even for basic APIs in every language that I use. i.e. I was
amazed that even senior developers at my previous job did not know that
strncpy is practically useless. It was just `man strncpy` away.

In a way static typing can save you just like reading of documentation, but in
a more organized manner. That said you should still eat your ve^W^W^W read
documentation.

What helps in case of dynamic languages is REPL. It is even better than
documentation sometimes. You can easly check every line with your reasoning.
For C or C++ I always have some simple file for testing basic constructs to
check my assumptions. One could argue that that is the role of unit tests, but
one does not prevent the other. Unit tests are same thing, but in more
organized manner.

~~~
gnuvince
Two things:

a) Maxime works on a compiler for JS, so even if something is documented to
death, it usually makes analyses less precise and/or more complex.

b) Many statically-typed languages have a REPL (OCaml, Haskell, Scala); this
is not an issue with the typing discipline, but with the tools available to
the developers.

~~~
dllthomas
With type inference, a REPL can even tell you things about code that can't run
yet!

    
    
        Prelude> :t mapM undefined [5,6,7]
        mapM undefined [5,6,7] :: Monad m => m [b]
    

This can get even more informative with Typed Holes:

    
    
        Prelude> mapM _whatFunc [5,6,7]
        
        <interactive>:14:6:
            Found hole ‘_whatFunc’ with type: Integer -> m b
            Where: ‘m’ is a rigid type variable bound by
                       the inferred type of it :: m [b] at <interactive>:14:1
                   ‘b’ is a rigid type variable bound by
                       the inferred type of it :: m [b] at <interactive>:14:1
            Relevant bindings include it :: m [b] (bound at <interactive>:14:1)
            In the first argument of ‘mapM’, namely ‘_whatFunc’
            In the expression: mapM _whatFunc [5, 6, 7]
            In an equation for ‘it’: it = mapM _whatFunc [5, 6, 7]

------
bpicolo
JavaScript, PHP, Python, and Ruby are all in the top 5 spots on GitHub. Java
is the only STL that made the cut. There are certainly types of work that seem
to favor dynamic languages, because they have the ability to do some
interesting things. ORMs, for example, far more powerful in dynamic languages
as far as I've encountered

~~~
nerdy
Even PHP has trajectory toward static types. Some examples are Hack[1] and
PHP7[2]. Check out the talk Rasmus gave at Etsy[3] for more about PHP7 changes
but it looks like at least limited support for static or "strict" types
(whatever subtle distinction that might be) has enough merit for PHP to
implement after all this time.

1\. [http://hacklang.org/](http://hacklang.org/)

2\. [http://www.php.net/manual/en/migration70.new-
features.php](http://www.php.net/manual/en/migration70.new-features.php)

3\.
[https://www.youtube.com/watch?v=MT4rRWKygq0](https://www.youtube.com/watch?v=MT4rRWKygq0)

~~~
captn3m0
PHP is still a dynamic language. PHP 7 gets us scalar typehinting support,
which lets us check types at run-time. There are similar annotation based
solutions for Ruby as well, which ultimately rely on a lot of Ruby's
metaprogramming features. The idea behind these solutions is to have proper
type support where you need it.

You will have to pry duck-typing from my cold dead hands if you try to remove
it from PHP/Ruby completely.

------
bshimmin
Well, there's plenty of controversy in this one, but I think

 _Compared to CS students, the average web developer is not as passionate
about programming, and not as skilled a programmer._

...probably takes the biscuit; I'm not even sure where to start with it
really, apart from my complete failure to understand how "web developers" and
"CS students" are supposed to be two distinct groups which are able to be
compared.

~~~
exo762
Anecdotally, on my year around 75% of students were there just because CS was
supposed to bring money. They've started CS studies while not knowing how to
program, knowing nothing about operating systems or caring. For them it was a
9-17 future job, nothing more.

~~~
alexwebb2
First time I've ever heard a 9-5 job called a "9-17" job. Decided to Google it
to see how common it was, and all the results are for the Bible verse Job 9:17
-

> He would crush me with a storm and multiply my wounds for no reason.

Seems appropriate for some "9-17" jobs.

~~~
silversupreme
17 is 5pm expressed in 24-hour time. :)

I like your interpretation as well, though.

------
reacweb
When I have started my carrier, it was unimaginable to use a dynamic language
in a serious project. I was taught(!?) that the difference of development cost
was very small.

The mentalities have evolved. People know that you can drastically reduce the
development costs (of small projects) by using dynamic languages. We know also
that maintenance is more costly.

Static languages are always improving to support features that used to exist
only in dynamic languages. Dynamic languages evolve to support optional
typing. The differences are reducing, but I think there is still a need for
the 2 kind of languages.

Often they are combined in big projects. For example c++/javascript in browser
or c++/guile.

------
jayvanguard
This post and the one that prompted it both seem to be begging the question. I
don't see greater percentage use of static vs. dynamic languages now compared
to ten or twenty years ago.

There is a lot of interesting research into strong static type systems but
that has been going on for ages (ML family of languages).

In fact, I'd say if anything there is a big surge every decade or so in
dynamic languages when a new problem space emerges.

90s - Perl, Javascript

00s - Ruby and Objective-C resurgence

10s - ES6 and JS related languages

Once an area matures, the paranoid static type people come in and harden
things. Then people realize they're getting nothing done and add DSLs on top
for flexibility. And on it goes.

~~~
tormeh
The C/C++ people aren't paranoid (JPL coders excepted). Otherwise they would
be using something else.

Ada users are paranoid and Java users are concerned about project cost.

------
azaras
An alternative is optional static languages like Groovy or alternatives like
python Type Hints
([https://www.python.org/dev/peps/pep-0484/](https://www.python.org/dev/peps/pep-0484/))
are better than pure dynamic languages.

~~~
jayvanguard
I agree, I think optional or gradual typing is the future for dynamic
languages.

~~~
brianwawok
So a big project with optional typing. How do you handle it? Each person picks
a level? Or make rules that all services are strongly typed but within a
method is loosy goosy?

I see the project going one of two ways. One all loosy goosy. One all
statically typed. At which point what did optional typing add? Pick a side and
go for it.

~~~
jayvanguard
I see it as a gradual thing. Early in the project loosey and then as the
software matures add in more typing. But yeah, everyone needs to agree on the
right level for that stage in the project.

~~~
dllthomas
You seem to be under the impression that types are for late stage development.
I find them indispensable early on. First, because they let me feel out where
my assumptions conflict, often before I've gotten to writing the bit of code
that will make it obvious. Second, because when my assumptions _are_ wrong,
the type checker is a tremendous help refactoring - telling me all the places
my old code is incompatible with my new assumptions. Both of these mean I
don't need to be quite as sure that I've got things exactly right as I start
coding.

------
jinst8gmi
It seems like a reasonable argument that there has been a dramatic rise in the
number and popularity statically typed languages which feature type inference:
Go, Rust, C# (to a limited extent), Scala, Swift etc. They combine the
performance and safety of static typing without sacrificing expressiveness.

------
johngossman
It might be an interesting contest to find the earliest reference to this
debate. It isn't quite what I was looking for, but I found this short
comparison of programming languages from 1972 amusing:
[http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/1972002...](http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19720025540.pdf)

For example, this quote from the conclusion: "The possibility of
standardization of computer languages is still remote, and in the author's
opinion will remain so until standardization in hardware applied to standard
problems is first achieved"

Are we there yet?

------
agentultra
I hoped to have debunked, though not thoroughly, the myth that dynamic
languages cannot scale to power large projects in my recent talk at Pycon CA.
Just take a look at Openstack. It's powering clouds in CERN and Yahoo! Japan
where it provides the infrastructure for delivering earthquake notifications
to the public -- a valuable and critical service! And it's written largely in
Python.

It does rely on systems written in static languages and is itself written in
one... but dynamic languages _are_ very useful for a class of problem where
deferring decisions about specifics until run-time is a huge advantage.
Normally this is reserved for exploratory programming but in practice it is
also useful for dynamically configured systems that can introspect themselves
at run-time and change that configuration or adapt to unstructured input.

 _Update_ : I'm also one of the unwashed masses that, _gasp_ , didn't go to
university and study PLT. I still have a dog-eared copy of SICP, The Dragon
Book, Concrete Mathematics, et al... and started by making terrible pong
clones and text adventures in BASIC on an Amiga 500.

~~~
rwmj
OpenStack is the perfect example of how Python doesn't work well for larger
projects. It's only because of an absolutely massive investment in testing
that OpenStack works at all. I think it's more accurate to say that OpenStack
works despite an unsuitable choice for implementation language.

~~~
agentultra
I assure you that even if you wrote it in Haskell you'd have a few unit tests
and integration tests in there.

~~~
ldrndll
I don't think he claimed otherwise. There's a difference between a code base
that makes judicious use of tests to validate business logic and one that
relies on the test suite just to keep it from falling apart. I've worked on
the latter, so I know ;)

I'm not making any representations as to whether or not this is true of
OpenStack. I honestly wouldn't know.

~~~
agentultra
I can assure you, as an active technical contributor, that the testing
infrastructure in Openstack is verifying business logic, ensuring consistent
coding standards, running unit tests and code coverage, and all of the usual
activities associated with delivering reliable software. The difference for
many projects is the scale at which it is automated thanks to the Openstack
Infra and QA teams.

Any suggestion that Python code cannot possibly execute without it is an
exaggeration.

------
imglorp
Won ... for what job? Dynamics have their places.

------
random_coder
Availability of an interpreter has been one of the major advantages of
programming in dynamic languages. With languages like Haskell, Scala coming
with first class interpreters, this advantage is being lost to a certain
extent. I think it should be possible to build interpreters even for
mainstream static langs like C++ and Java, they probably exist already, though
I'm not sure why they haven't found larger acceptance.

I believe the biggest advantage with a good static type system is that
programmers can design good datatypes and specify their relationships - and
the compiler can then detect any inconsistencies(ideally anyway).

~~~
brianwawok
Java take too much boilerplate. Who wants to use it in an interpeter?

I do use a interpreter with both scala and python a lot.

------
acbart
I don't know, I'm taking a Program Analysis graduate seminar this semester,
and my take is that the techniques for dynamic analysis are getting halfway
decent.

It's also interesting to compare Python and JavaScript. Holkner and Harland
did a pair of papers about those two communities' usage of dynamic typing - JS
people do type changes throughout the program execution, but after
initialization the Python people follow the Aycock quote: "Giving people a
dynamically-typed language does not mean that they write dynamically-typed
programs." Languages have different characteristic programs, to some degree.

------
mcv
Static Languages won? That's not just a bit premature; it's bizarre. Several
of the most popular and effective languages at the moment are dynamic: Python,
Javascript, Ruby, PHP, all the LISP derivatives.

I don't doubt that lots of new static languages have popped up, but how many
people actually use those? Plenty of people use static languages, true, but
those are mostly the old ones: Java, C, C++, C#, and Haskell and Scala.

Any claim that this has been settled by some new languages nobody is using is
bizarre.

------
wmil
Static languages haven't "won".

There's just not much point in creating a new dynamic language.

Ruby is flexible enough to turn into a DSL for whatever. Python does it's job
very well. Lua has it's niche. Javascript is everywhere now.

What can a new dynamic language do that isn't easier to accomplish with
libraries?

So most of the language development has gone towards making static typing
easier to use. Improving on C++ / Java is easy. There are interesting ways to
go about it with no clear right answer.

------
incepted
They have won in theory: they are arguably better in every way than
dynamically typed languages (DTL) in the sense that they offer all the
advantages that used to be unique to DTL and, obviously, also all the
advantages of STL (automatic refactorings, performance, ease of maintenance,
etc...).

Javascript is the last serious holdover of the DTL generation but even it is
showing tendencies to be replaced by STL (Typescript, Dart). It will take a
while, though, but the trend is clear.

~~~
idibidiart
Replaced? I can't see that happening in the next 5 years (an eternity in this
business) Supplemented with tools like Flow? That's already a huge thing, and
it's part of the React and React Native tool belt.

~~~
iheartmemcache
The whole reason Flow was invented was because Javascript was un-managable at
scale without types. The whole "both" (i.e. gradual typing a la Typed
Racket/Clojure/TypeScript) is probably solution. Interestingly the author has
an article on that too which is a fairly good read[1].

[1] [http://pointersgonewild.com/2012/11/09/static-vs-dynamic-
why...](http://pointersgonewild.com/2012/11/09/static-vs-dynamic-why-not-
both/)

------
dasboth
Sweeping statements like "X programming language/paradigm has won" do an
injustice to the wealth of uses of programming. You wouldn't use the same
programming language to write code for an Arduino, a startup MVP web
application, an enterprise desktop application etc. and there's no reason you
should.

Personally I developed most of my web apps in C# but I find Python great for
prototyping and data analysis tasks. Why is there a need to declare a winner?

------
hcarvalhoalves
I think it can certainly win as the type systems / inference get better, and
languages with those characteristics are ported to mature platforms with good
libraries, etc.

The real appeal of what we today call "dynamic languages" is leaving type-
checking up to the programmer, so in essence all programs are typed - just so
happens that some don't formalize it inside the code.

A good compromise until then is gradual typing.

------
programminggeek
Short answer, no they haven't and they won't.

------
coldtea
No, Javascript has won, and it's dynamic.

But people are starting to appreciate static typing assurances and IDE
conveniences.

------
ilurkedhere
You can go far, quickly with a dynamic language and that's often what you need
in a startup environment.

------
ajuc
Are go/rust really that popular? I always thought they are even more niche
than clojure.

~~~
ainar-g
Both RedMonk [1] and TIOBE [2] indexes (both flawed, but better than nothing)
show that Go is somewhat more popular than Clojure. Rust is still behind, but
it hit its 1.0 relatively recently, so it's just getting started.

[1] [http://redmonk.com/sogrady/2015/07/01/language-
rankings-6-15...](http://redmonk.com/sogrady/2015/07/01/language-
rankings-6-15/)

[2]
[http://www.tiobe.com/index.php/content/paperinfo/tpci/index....](http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html)

------
Thiz
In academia and corporate? Sure.

In real world? Php, Python, Ruby and Javascript still reign supreme.

Mobile is another story since main platforms are controlled by corporations,
but if it were for the hobbyists neither java nor swift would have had a
chance.

~~~
galactus
In what sense are academia and corporate not "the real world"?

------
facepalm
Which static language should supposedly have won?

~~~
sagichmal
> Which static language should supposedly have won?

It's absolutely not that specific static languages have "won". But rather that
the latest crop of static languages have proved that the oft-cited downsides
of static typing, e.g. type stuttering in declarations, can be pragmatically
addressed by other means, e.g. type inference. As such, the cost differential
of static languages over dynamic is reduced to near-zero, and all of the
benefits remain.

I don't really see an argument, or really counter-argument, in the linked
post. The author complains that the current crop of dynamic languages are
badly implemented, but I'm not sure that holds water when you look at e.g.
Clojure. They claim the chief advantage of static languages is IDE
support/integration, but that seems like a strawman to me, a fringe benefit of
the real, structural advantages of an explicit type layer.

~~~
facepalm
So basically Scala and Haskell? I've tried Go but was turned off by the
complexity of writing a sort function - an artifact of static typing. Seems to
me you'll always end up with something like generics which becomes complicated
quickly?

~~~
brianwawok
I mean every language has a baked in sort function, so maybe that is a bad
place to start :)

Java collection signatures are not super complex but they have fundamental
bugs fixed in the slightly more complex scala collections type signatures.

~~~
facepalm
No I mean using the sort framework of Go. It takes several steps to set up a
comparator function.

compared to list.sort(function(a,b){return comparisonResult}) that was very
demotivating to me.

~~~
ldrndll
It seems like quite a few people have found that the simplicity of Go's type
system just winds up transferring the complexity to your code base, instead of
in the language implementation. I find it interesting how divided the opinions
are on this.

------
braythwayt
Betteridge's Law of Headlines

[https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...](https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines)

