
Leaving Go - beNjiox
http://jozefg.bitbucket.org/posts/2013-08-23-leaving-go.html
======
pron
It's ironic that the "better" the language (for some hazy definition of
"better") the less actual work seems to get done with it. So Go can be pretty
annoying at times, and so can Java (I've said before that I find the two
almost identical, but that's beside the point now); and C is horrible and
completely unsafe and downright dangerous. Yet more useful working code has
probably been written in Java and C than all other languages combined since
the invention of the computer, and more useful code has been written in, what,
5 years of Go(?) than in 20(?) years of Haskell.

Here's the thing: I am willing to accept that Haskell is the best programming
language ever created. People have been telling me this for over 15 years now.
And yet it seems like the most complex code written in Haskell is the Haskell
compiler itself (and maybe some tooling around it). If Haskell's clear
advantages really make that much of a difference, maybe its (very vocal)
supporters should start doing really impressive things with it rather than
write compilers. I don't know, write a really safe operating system; a novel
database; some crazy Watson-like machine; a never-failing hardware controller.
Otherwise, all of this is just talk.

~~~
Locke1689
As someone who thinks that more advanced type systems and proof-carrying-code
are some of the biggest advances in theoretical computer science _and_
practical programming in the last few decades, but also is a C# compiler
developer, I have also noticed this. Haskell is really interesting, but C#
developers _get shit done._

I'm not sure what the cause is, but it definitely gnaws at me.

~~~
nostrademons
It's not a good thing - for production software - for a language to be too
much fun to use. It means that developers spend all their time _using the
language_ and not enough time _solving problems_. The suckiness of Java/C#
tends to encourage people to solve their problem and move on quickly to the
next problem, because it's honestly not much fun trying to extend the language
or build abstractions. Haskell & Lisp programmers, however, can spend hours
constructing utility libraries, DSLs, and custom monads to solve their problem
_elegantly_ , and as a result they have extremely elegant source code that
nobody but themselves will ever read, a library of utilities that they will
probably not use again, and a solved problem that took 4 hours while the hacky
Java solution took an hour.

~~~
Dewie
Then I guess that Emacs users never get any work done? ;) (I wouldn't know,
but I would be surprised if that was the case)

~~~
nostrademons
The average emacs user I know doesn't actually know or write Elisp, they just
grab preconfigured .el files off the Internet or corporate intranet and add
the appropriate snippets to their .emacs.

Elisp gurus, in my experience, _don 't_ get all that much work done, other
than writing lots of editor extensions. This is great if their job is writing
editor extensions, less great if their job is something else. It's the same as
with compiler writers: they're great at making _other_ people more productive,
but when it comes to writing end-user software, not so much. In general, of
course - there are exceptions.

------
tptacek
If you're looking for a language that will enable "bottom-up development",
where you gradually define, in Paul Graham On Lisp style, a language optimized
for your problem domain, Golang is not the language for you.

Similarly, if you're looking for a language that will read and write like a
specification for your problem domain, so that writing your program has the
side effect of doing half the work of proving your program correct, Golang is
also not a good choice.

What's worse, those two approaches to solving programming problems are
compatible with each other. Lots of sharp programmers deeply appreciate both
of them, and are used to languages that gracefully provide both of those
facilities. If that describes you, Golang is a terrible choice; it will feel
like writing 1990s Java (even though it really isn't).

There are two kinds of programmers for whom Golang will really resonate:

Python and Ruby developers who wish they could trade a bit of flexibility,
ambiguousness, or dynamicism for better performance or safer code seem to like
Golang a lot. Naive Golang code will outperform either Python or Ruby.
Golang's approach to concurrency, while not revolutionary, is very well
executed; Python and Ruby developers who want to write highly concurrent
programs, particularly if they're used to the evented model, will find Golang
not only faster but also probably easier to build programs in.

Systems C programmers ( _not_ C++ programmers; if you're a C++ programmer in
2014, chances are you appreciate a lot of the knobs and dials Golang has
deliberately jettisoned) might appreciate Golang for writing a lot like C,
while providing 80% of the simplicity and flexibility value of Python. In
particular, if you're the kind of programmer that starts projects in Python
and then routinely "drops down" to C for the high-performance bits, Golang is
kind of a dream. Golang's tooling is also optimized in such a way that C
programmers will deeply appreciate it, without getting frustrated by the tools
Golang misses that are common to other languages (particularly, REPLs).

At the end of the day, Golang is overwhelmingly about pragmatism and
refinement. If you're of the belief that programming is stuck in a rut of
constructs from the 1980s and 1990s, and that what is needed is better
_languages_ that more carefully describe and address the problems of correct
and expressive programming, Golang will drive you nuts. If you're the kind of
person who sees programming languages as mere tools --- and I think that's a
totally legitimate perspective, personally --- you might find Golang very
pleasant to use. I don't know that Golang is a great _language_ , but it is an
extremely well-designed tool.

~~~
DAddYE
> Systems C programmers

I don't know many (TBH none) c programmers that likes or actually uses go. The
thing is that as for c++ if you are still writing in c is just for few
reasons: portability (in terms of embedding your library) and speed.
Especially the former seems very important.

EDIT: I know => I know personally or I follow.

~~~
kaib
Does Ken count as a Systems C programmer?

Most of the systems C programmers I know, who admittedly work on large
distributed systems, like Go.

~~~
DAddYE
Edited, I meant: who I know or I follow.

------
ChuckMcM
This is a great rant. Having recently done the 'golang' tutorial on the site a
lot of it resonated with me. I have a slight advantage in that I worked at
Google when Go came into existence and followed some of the debates about what
problem it was trying to solve. The place it plugged in nicely was between the
folks who wrote mostly python but wanted to go faster, and the folks who wrote
C++. It was a niche that Java could not fill given its structure.

In a weird way, it reminds me of BLISS[1]. BLISS had this relationship to
assembler that "made it manageable" while keeping things fast. BLISS was
replaced by C pretty much everywhere that C took hold (one theory is that
BLISS is the 'B' programming language, Algol is the 'A' language, personally I
think BCPL is a better owner the the 'B' moniker). The things that C has
issues with, memory management, networking, and multi-threading, Go takes on
front and center. It keeps around some of the expressiveness and type checking
that makes compiling it half the battle toward correctness.

Now that was kind of what the Java team was shooting for as well but with
limited success. I feel like between Go and Java we've got some ideas of what
the eventual successor language will look like. For me at least that is a step
in the right direction.

[1] [http://en.wikipedia.org/wiki/BLISS](http://en.wikipedia.org/wiki/BLISS)

------
chimeracoder
As someone who writes both Lisp and Go (and enjoys both), I find it odd that
this article uses Lisp and Haskell as points of comparison.

> programming in Go isn’t “fun” in the same way that Python, Haskell, or Lisp
> is.

Yes, writing Lisp is much more "fun" than writing Go for me. But writing Go is
much more productive and maintainable (both for solo projects and for larger
groups).

In fact, this is almost an intentional "feature" of Go:
[http://aerokode.com/blog/go-is-boring](http://aerokode.com/blog/go-is-boring)

> The idea is that there’s simply no way that any group of designers could
> imagine how people will want to use their language so making it easy to
> extend solves the problem wonderfully.

On the other hand, there's no way of making a language so easily extensible
while also maintaining relatively uniform idiomatic, design, and style
conventions across a language community. Go very heavily favors the latter.

> In Lisp, CLOS (Common Lisp Object System) was originally a library. It was a
> user defined abstraction that was so popular it was ported into the
> standard.

CLOS is actually very similar in some ways to Go's structs. Both emphasize
encapsulating data inside an "entity" (object/struct), _and_ separating the
notion of behavior from that entity. To quote one of the language authors from
GopherCon[0]: "Interfaces separate data from behavior. Classes conflate them."

Lisp was "designed" (if you can call it that) around the principle that
extending a language should be as easy as writing a program in that language.
Go was designed around the principle that there should be only one dialect of
the programming language, for the sake of cohesiveness. It's a stronger
assertion of the Pythonic motto, "There should be one, and preferably only
one, obvious way to do it".

[0]
[https://twitter.com/chimeracoder/status/459827405386162176](https://twitter.com/chimeracoder/status/459827405386162176)

~~~
Pxtl
> Yes, writing Lisp is much more "fun" than writing Go for me. But writing Go
> is much more productive and maintainable (both for solo projects and for
> larger groups).

I heard ASP.Net WebForms get this defense, that no other platform could handle
the "enterprise" needs for maintainability and every other platform was just
building a pile of cowboy spaghetti code.

Turns out it just sucked.

~~~
egeozcan
> Turns out it just sucked.

Well, an anecdotal counter-evidence is that we have some WebForms apps
maintained by another team in our company and the developers from that team
seem very happy and are productive enough to meet reasonable deadlines. I
despise WebForms but that doesn't mean anything from a product managers
perspective.

------
gdulli
The agreeableness of Python is the reason I settled on it after experience
with a bunch of other languages. I was starting to find software engineering
to be a chore and was losing interest in it until I started using Python. No
language is best at everything, and all the ways python isn't the best have
been worked around without much bother.

Go did not strike me as a language I would enjoy writing, despite the
strengths it surely has in some areas. I would just be giving up other
strengths I prioritize more highly.

~~~
camus2
Frankly python is good enough for most things. It's not perfect but it's one
of these languages you can really use for anything(like java). I'm not fan of
the syntax though,I prefer ruby's(ruby is not for "everything" unfortunatly).
I've seen insane stuff done in python (3d games,gui apps,complex network
tools...) running quite well on my old mac.

Go is relevant where you want pretty good performances and concurrency with
low memory footprint(unlike java) ,without using C/C++ and threads. But it's
clearly not for everything.

------
DAddYE
> I’ve been using Go since November and I’ve decided that it’s time to give it
> up for my hobby projects. I’d still be happy to use it professionally, but I
> find that programming in Go isn’t “fun” in the same way that Python,
> Haskell, or Lisp is.

I can't leave go, but indeed I think absolutely the same. The thing is that GO
was designed to replace c++ thing that absolutely failed. So we have a
python/ruby replacement with very old patterns (I think manual checking errors
ie.).

Indeed I think go is an awesome language but sometimes I really feel like a
monkey repeating myself over and over again.

~~~
coherentpony
>The thing is that GO was designed to replace c++ thing that absolutely
failed.

I was so excited for GO to become a nice replacement to C++. GO has awesome
build times. C++ has awful build times. This is partly due to all the extra
work the C preprocessor has to do make sure all the headers are present.

The big lose for me is the fact that GO has absolutely no operator
overloading. This is one of the biggest wins in C++, especially since I do lot
of high-performance scientific computing. Overloading operators makes code a
lot more readable and user friendly, in my opinion (I'm others will disagree,
though). I'm aware that you can hack GO to mimic operator overloading but it
involves hitting the vtable. And hitting the vtable is completely unacceptable
in performance-critical code.

~~~
kybernetikos
> Overloading operators makes code a lot more readable and user friendly,

Completely true for scientific computing, but I've been subjected to libraries
written in scala recently and operator overloading there has lead to some very
difficult to read and use libraries.

~~~
StefanKarpinski
The key to preventing overloading of _definitions_ from being a complete
disaster is to be very careful not to overload _meanings_. I.e. if you're
going to have lots of methods for your `frob` function, you had better be
crystal clear what it means to `frob` something and only add methods that fit
that definition. Scala and C++ libraries tend to like to just pick a random
operator and use it to mean some arbitrary made up thing because they feel
like it, ignoring the _meaning_ of the operator. The classic example in C++ is
using << for stream output. That's the left shift operator for Pete's sake!
Why would that be what you use print stuff? Because you liked the look of it?
It's not terribly surprising that this a complete usability disaster.

------
piokuc
I think people gave Go a lot of credit just because it was designed at Google.
People have high respect for Google engineers and so they assume what Googlers
have designed must be flawless. So they take for granted ideas like lack of
exceptions or lack of operators' overloading being a good thing, even though
I'm quite sure they would be quick to criticize such BS if that was a feature
in a language not coming from Google. But, in the long run, the language must
defend itself on its own, without the authority of people/organization behind
it.

~~~
bookwormAT
I think people gave Go a lot of attention because it was designed by Rob Pike
and Ken Thompson.

~~~
piokuc
I have a feeling that the attention would be much more modest if they happened
not to be on Google payroll when they designed the language. Anyway, whether
it's because of Ken or Rob, or Google brand, it doesn't change the point I was
trying to make.

------
eridius
> I wanted a fast, compiled replacement for stuff I write in C right now. But
> Go is not that language.

You should look into Rust. It sounds like it might be more like what you're
looking for.

~~~
djur
Rust is great but it's still frontier territory right now. The documentation
for the standard library is very sparse and stuff like HTTP is still in very
early stages. I would only adopt it for production work if you're willing to
be very actively involved in the nascent Rust community, follow the mailing
lists, fix bugs yourself, etc.

On the other hand, if that's the kind of thing that excites you, Rust is a
really great option right now.

------
Jabbles
As much as I want to emphasize that this is not the right way to think about
programming in Go, I do want to point out that the example has a lot of extra
code that isn't needed. Indeed, it's not really possible to have a bug of the
kind the author wrote if written properly:

[http://play.golang.org/p/puZBEmOVaI](http://play.golang.org/p/puZBEmOVaI)

~~~
DocSavage
The explicit type switch also lets you streamline handling of uint8, uint16,
etc (just return value) and panic or error if given a type you don't expect.

But I find it unfortunate that type switches must have single type cases. For
example, it's too bad this doesn't work:

[http://play.golang.org/p/a4j1I6Oug-](http://play.golang.org/p/a4j1I6Oug-)

The OP's complaint would be minor if the compiler would auto-unroll the multi-
type case clause.

------
shurcooL
Every design decision has trade offs. Since the author only covers the more
obvious negative aspects of those 2 features, I'd like to cover the more
subtle positives.

> Extensibility

One really great thing about that is how consistent it is. Every func in Go
has a unique identifier: the package import path and the func name pair. This
makes it possible to build tools like godoc.org and the `doc` command that let
me look up the exact behavior of (unfamiliar) code.

In this case, I can go to godoc.org/math/big#NewInt or type `doc big.NewInt`
and see:

    
    
      // NewInt allocates and returns a new Int set to x.
      func NewInt(x int64) *Int
    

In fact, it's so predictable that I don't have to think. As long as it's Go
code, if I ever run into an unfamiliar func F of package P, I can always go to
godoc.org/P#F or `doc P.F`. No searching, just an instant lookup. If I need to
do 30 such lookups to solve a task, it makes a big difference. This applies to
_all_ 3rd party Go packages. That is big.

On the other hand, something like `x + y` is magic to me. I know that
computers work with bytes at low level, and I want to be _able_ to understand
what happens on that level. I understand and accept such magic for built in
types. But I certainly wouldn't want to be reading a 3rd party Go library code
that says `x + y` on its custom types. Where would I go to find out what that
custom plus operator does? How does one make an unexported version of a plus
operator? There'd be less consistency, more exceptions and rules, more
variations in style and less tools that can be built to assist/answer
questions about Go code.

> The Type System

I don't have time to cover this atm, but there are some advantages to the
explicitness and verboseness of Go's approach. Can you think of any?

I'm not suggesting it's the best it could ever be, just that there are both
advantages and disadvantages that should be considered.

------
bfrog
Go's strengths are tooling and libraries. Especially when you see the well
written libraries all revolving around internet protocols, encodings, and
content generation. It makes it extremely easy to write performant web sites
and http API endpoints which many people do daily.

All that said I hope Go adds D like compile time code generation and static
typing or [D,Rust] gains better tooling and HTTP service oriented libraries
and APIs that are as well written as the Go standard library packages are.
Secondly I hope [D,Rust] sees how awesome having a common automatic format,
build, and test tool is. In so few language is the testing package as simple
as Go's. In so few languages is the build process as easy as Go's.

------
coldcode
All languages suck, at some level. Whether this matters to you is a matter of
need, willingness to compromise, and benefits to you, for some definition of
you. This often leads to people writing their own language if they can which
generally only pleases themselves.

------
cryptos
I've the same feelings about Go. After working several month on a side project
with Go, I have given up, because I've felt not as productive as with Java
(not to mention Scala). There are lots of annoying things: missing generics
leading to a lot of uselesse code which could carry bugs. Without generics you
can not create an Option datastructure, but have to return nil (the million
dollar mistake of Hoare). Without generics you can not write concise
object/functional code like someCollection.map(i -> i * i). Go has no good
support for immutability. Mocking is awkward, because you have to code your
mocks by hand. Unicode handling is a pain.

That is why Go attracts mainly people from scripting languages (they get a bit
more type safety and better performance) and C (they get a bit more type
safety and less errors). Coming from other languages Go is not that
attractive. I'm hoping for Rust to succeed.

------
vfclists
Try Nimrod. Or Julia.

I haven't tried them yet, but it looks like their fun.

~~~
zoowar
Julia is not fun. We expect it to be fun, like python, but it's not.

~~~
herokusaki
Can you elaborate why?

~~~
xioxox
I was interested until I discovered Julia doesn't have a useful form of OOP
inheritance. Ok, you don't always need it, but for some things it's
indispensable (e.g. using widget/window systems).

~~~
one-more-minute
That's a bit like saying, for example, Python isn't interesting because it
doesn't have monads (and they're essential for managing state, or whatever).
Different languages have different ways of doing things, and lacking feature X
isn't necessarily a deficiency.

Julia generally favours composition over inheritance. You might be interested
to look at GTK.jl, its widget/window system.

[https://github.com/JuliaLang/Gtk.jl](https://github.com/JuliaLang/Gtk.jl)

------
ilaksh
If you guys like Python and are having second thoughts about Go, take a look
at Nimrod.

Also, I personally look at Nimrod as a faster and slightly cleaner Python with
a few extras, and I don't try to break the compiler using all of its cutting
edge features. If you use it that way you will be happy.

------
Kiro
What is the definition of fun when it comes to a programming language?

~~~
DAddYE
It's subjective, for me is DRY (don't repeat yourself) and achieve a "big"
result with a small (but readable) effort.

------
stcredzero
A 16 year old kid decides that Go isn't suitable for writing an embodiment of
Principia Mathematica. Surprise: Haskell is a better Haskell than Go.

Go is a something like C, but with a few more features plus GC and come neat
concurrency facilities. Why would anyone expect _that_ to be anything like
Haskell, or even to have a type system even approaching that kind of power?

------
rio4223
Very well put. I tried Go now for a while and I was wondering why it doesn't
appeal to me like for some of my friends. By reading through your response I
found the reason for my gut feeling. I guess I belong into your first
categorie ;).

------
lmm
Does anyone actually use CLOS? It's always held up as this great example of
language extensibility, but my impression is that since it's not part of the
core language Lisp folk tend to create their own abstractions instead.

~~~
piokuc
Not sure what you mean by "not part of core language" \- CLOS is part of ANSI
Common Lisp standard.

~~~
jimktrains2
It wasn't always that way. It use to be just a lib iirc.

~~~
piokuc
Well, CLOS became part of ANSI Common Lisp standard 24 years ago...

------
taylorlapeyre
I just wanted to point out that the author of this article is a high school
student.

[http://jozefg.bitbucket.org/about.html](http://jozefg.bitbucket.org/about.html)

~~~
tdees40
Wow, "writing lots of compilers and type checkers" definitely wasn't on my
radar screen when I was in high school.

~~~
Jtsummers
Me neither, but a classmate was reading over/working through the dragon book
our senior year of high school. There's a reason he went to CMU and I didn't.
On the other hand, compilers (well, a less than formal version) was the third
CS course topic at GT. Definitely approachable, with good faculty/staff, as an
early topic of study.

------
jamra
I have a problem with his extensibility critique. I don't agree that having
generic types are good for the language. The problem in using polymorphism is
that your users are going to abuse polymorphism. There will be class
hierarchies that will confuse and abstract from the algorithm at hand. You
will be mutating and mangling objects rather than dealing with the issues at
hand.

Reading a go source file is like following a for loop. It's quite technical.
Reading a Java source file can be a case of trying to figure out the high
level abstractions of the program.

~~~
twic
The genericity that is being talked about here is _parametric polymorphism_ ,
not _subtype polymorphism_. Parametric polymorphism doesn't lead to confusing
class hierarchies. Parametric polymorphism doesn't involve inheritance, so it
doesn't lead to any class hierarchies.

------
sandGorgon
>Ok, it’s only a few characters, big deal. Now what does this do?

>b.Mul(b).Sub(big.NewInt(4).Mul(a).Mul(c)) >Or in Haskell

>b * b - 4 * a * c

umm.. correct me if I'm wrong, since I'm not well versed in either Haskell or
Go, but doesnt the Golang version _read_ better in terms of scoping. I mean
just by reading the Go version, I know what it will evaluate to, but in the
Haskell version I dont know the precedence order just by reading.

~~~
grayclhn
I do, and I don't even know Haskell: (b * b) - (4 * a * c)

edit: I don't know go, but I assume the go example is intentionally
unreadable. But complaining about infix multiplication and subtraction is...
curious.

~~~
khyryk
It really does get that ugly. Check out
[http://golang.org/pkg/math/big/](http://golang.org/pkg/math/big/).

~~~
grayclhn
Yikes.

------
pjmlp
I had similar reasons, but on my case the language was still at pre-1.0.

~~~
ewood
May I ask what languages you tend to favour? I've had a few friends tell me
lately that they were all giving up on Go after persisting with it since early
2010. They are all people who tend to work in C/C++ so they don't tend to be
thrown by a steep learning curve. I'm quite surprised because they were all
vocal proponents in the beginning.

~~~
pjmlp
Java, Clojure, Scala, Haskell, C++, OCaml, C#, F#, D, Rust, Ada.

------
personZ
These sorts of posts are profoundly boring. I know people will up arrow it --
some sort of spiteful "Down with Go!" contrarian thing, when they aren't
talking up rust -- but it isn't because the content is interesting or
illuminating, but rather as some sort of activist thing.

This particular piece (by a high school student, as an aside) starts off
trying to create a surrogate for generics in Go.

 __Don 't __.

Here's the thing -- most of these posts are not about people making real code,
but people making -toy- code. Where every function is all things to all
people.

The number of times I've needed a generic abs in my life -- zero.

The number of times I've needed a double floating point abs in my life --
every single time.

That's the thing about generics and real, actual world code: Your types are
generally much less amorphous than you think. They really are. This illusion
that everything needs to be everything just does not hold in the real world.

But it is always the tiring example used against Go. Boring.

~~~
eridius
A generic abs? Not particularly useful, you're right. But he was using that as
a trivial example. Generics are incredibly useful in a lot of contexts. One
context that the author touched on briefly is new container types. In Go, if I
have a Slice, the type of element the slice contains is specified. But if I
have a user-defined container, either the container has to be specialized for
a single type (which makes it largely useless, at least as reusable code), or
it has to take interface{}, which really sucks. No more homogenous container,
no more static type information when working with this container, etc.

~~~
burntsushi
Trivial examples are terrible as evidence to support a point. Trivial examples
are generally good for pedagogical purposes, which doesn't really fit with the
OP.

For example, the OP mentioned that using a stack in Go requires casting from
`interface{}`. But this is patently ridiculous. Most people who need a stack
in Go just use a slice: [https://code.google.com/p/go-
wiki/wiki/SliceTricks](https://code.google.com/p/go-wiki/wiki/SliceTricks)
\--- Is this a bit messier and limited than a container type suited to stacks?
Yes! But it gets the job done the majority of the time. _Therefore_ , it's not
as big of a problem as the article leads you to believe.

Not all things require clean polymorphic container types. Sometimes you can
get by with less. And when you need more, you're going to feel a bit of pain
with a less expressive type system. It's all part of the trade off. But it's
not good to represent this as a scenario where it's all just bad stuff all the
time.

~~~
eridius
It's more than just feeling pain when writing code. Using interface{} has a
runtime cost. Both because of the vtable and because it requires heap-
allocating something that could otherwise be inline.

~~~
burntsushi
Yes, that's true. The "pain" I had in mind wasn't in using `interface{}`, but
in writing non-generic code. This doesn't result in a performance loss, but
will result in some code duplication. (Or alternatively, extra complexity from
using some sort of code generator.)

But, to be fair, in the Go world, both mechanisms are used. It depends on
which costs are important.

------
leccine
It is so funny to see that somebody else got annoyed by Go the same way as I
did. I could not get over the fact that I cant pass any type to a function
other than interface{}. When you do that it just delays the problem and I have
decided to not have a generic function but have multiple specific one. This
violates the DRY principle but at least works. I am still looking for best
practices with Go. I think the biggest advantage of that languages is the fact
that Goole uses it in production and the libraries are well tested. The
community is great too. Clojure has a way smaller community that limits the
usage of that environment quite a bit. I agree with the author on Lisp is
being more fun than Go, but that is a single dimension of the entire problem.

------
falconfunction
I'm so glad Go can compile everything quickly, it's almost as fast as an
incremental compiler from the 80s.

------
Donch
The example could have been simplified:

    
    
      func abs(x Top) Top {
    	switch v := x.(type) {
    	case int32:
    		if v < 0 {
    			return -v
    		}
    	case int64:
    		if v < 0 {
    			return -v
    		}
    	case float32:
    		if v < 0 {
    			return -v
    		}
    	case float64:
    		if v < 0 {
    			return -v
    		}
    	}
    	return v
      }

~~~
bsdetector
This isn't simpler, it's smaller. In fact it's _more complicated_ , since
instead of 4 completely separate cases you have 4 half-cases and a default.

For instance, pass a positive int16 and you get the right answer, but pass a
negative int16 and you get a useable but wrong answer instead of nil from the
original.

~~~
Donch
It was an example of a language feature, that is short variable declarations
in type switches, which avoid repetitive casting. The example below has the
default clause which handles unknown types. I suppose the point is that you'd
never actually do any of this because the method is disgusting.

Thanks for the downvote :-)

