
Why we switched from Python to Go - tortilla
https://getstream.io/blog/switched-python-go/
======
dundercoder
Python was my entry into the programming world, and I've been an evangelist
ever since... Or I was until I ran into distribution and parallelism. Since
then, Nim has been my go-to language of choice. It is all that Python was,
plus unbelievable speed, compiling to shippable binaries, and some other cool
language features that admittedly, are still beyond my scope of abilities.
Still quite lacking in libraries compared to Python, but after a few attempts
(perhaps halfhearted), I never felt "Go" was a suitable replacement.

~~~
sjellis
For me, the ecosystem matters as much as the language itself these days
(actually more). There are languages that I've used at home just as a learning
experience, but ideally, I want a language that I can put into production at
work. That means quite a list of criteria: only a small number of languages
have a well-supported AWS SDK, for example.

I won't say that Go is mainstream yet, but it feels very "production-ready" in
those respects.

~~~
oblio
I'd say that simplest "production-ready" criterion is this: does it have an
officially supported and stable release of a IntelliJ IDE (there is a slight
Java-ecosystem bias, but I think it's only slight).

So the mainstream languages are...: C/C++, C#, F#, Go, Groovy, Java,
JavaScript, TypeScript, Kotlin, Objective-C, PHP, Python, Ruby, Scala, SQL,
Swift, VB.NET (source:
[https://www.jetbrains.com/products.html](https://www.jetbrains.com/products.html)).

Sounds about right :)

~~~
majewsky
So, from the top of my head, Erlang, Haskell, OCaml, Perl, Fortran, Cobol and
any type of shell script is not production-ready. Nice to have that clarified.
:P

~~~
gbersac
They may be production ready, but have a quite small ecosystem compared to
other languages mentioned.

~~~
saghm
Do shell and Perl really have a "small ecosystem" compared to something like
Groovy?

------
wruza
>Go forces you to stick to the basics. This makes it very easy to read
anyone’s code and immediately understand what’s going on.

I’m not criticizing Go since I have no LoC in it, but in other restricted-and-
flat languages and areas our company’s expertise quickly (read: in half a
decade) went to the limit with no chance to turn the lang partly into dsl and
level up. It is like playing rpg where you stuck to level 5 and never get
powerful enough to take middle-level quest even with a great party.

While it seems cool to have automatic jsonification, build process and out of
box concurrency, inability to create something that only your team can use and
understand effectively means you’re locked to growing markets (bubbles) and
never have real expertise and/or budget over bloated competition. This may
play a bad game with your future, should roads cross with one who has.

Again, the type I’m talking about must be rare, and “there is only one
opinionated way to do it” seems to fit better on average tasks.

~~~
rockostrich
I understand what you mean by "inability to create something that only your
team can use and understand", but the article doesn't say anything about that
and isn't really addressing developing new code in Go. The article is about
Python not matching their needs after a few tries at optimization and Go
having a similar development time (although if the code was already
implemented in Python then I assume the Go code was almost trivial to write so
I'm not sure that was a valid point).

As for "'there is only one opinionated way to do it' seems to fit better on
average tasks", from the Zen of Python: "There should be one-- and preferably
only one --obvious way to do it. Although that way may not be obvious at first
unless you're Dutch." And Python has been used to do plenty of above average
tasks.

~~~
marcosdumay
At a high enough level, Python does not live up to that zen. It does not
restrict how you will organize your code, it just restricts instruction level
options.

Keep in mind that the Zen of Python is mostly about how Python differs from
its ancestors (basically, Perl). It's not a work on software engineering.

------
it
I'm surprised to see Go's error handling listed as a disadvantage. Go
encourages writing good error messages, and that's one of my favorite things
about the language.

To get a sense of it, take a look at a failing test in a language such as
Python that uses asserts for testing and compare it to the equivalent written
in Go. Quite often, the error message in Go will be clear and to the point. On
the other hand, I've seen plenty of assertion based tests in other languages
that report inane things like "1 != 2" or "true != false" when they fail.

Go encourages putting the effort into this up front. It pays off later when
things go wrong and you want to know why.

~~~
tyingq
Probably complaining from someone used to exceptions and/or assertions, where
there is perhaps less boilerplate and manual verification that context bubbles
to the right place.

You can get there either way, but what you're used to weighs heavily.

For your example, depending on my experience, knowing that 1!=2 in some code
I'm using directly might be more meaningful or actionable than "out of
filehandles for accept()" in some deep chain of dependencies I know little
about. Just depends on what you're used to.

~~~
curun1r
Or anyone who's used a language where errors aren't as stringly-typed as Go
and where the compiler can enforce error handling. Exceptions have benefits
and drawbacks, but any language that can return a Result type will have better
error handling than Go in basically every way.

~~~
pritambaral
In Go, `error` is an interface, which means you can return anything that
implements the `Error() string` method as an `error`.

~~~
majewsky
Yeah, but 99% of libs won't return anything with additional accessible
structure.

~~~
tshannon
Yeah I think the point is, errors shouldn't be overloaded with too much extra
structure. They should be errors. If additional structure is needed, it should
probably be sent separately via the common multiple returns idiom in Go.

~~~
curun1r
Additional structure like, say, a numeric error code? An HttpError could
definitely contain the corresponding status code.

But I think the bigger point is that, for libraries, errors should be an
enumerated set of possible error conditions, not strings. You say "additional
structure", I say the duplicate filename, the invalid email address or,
crucially, the error that caused the error...chaining errors is very useful.
The multiple returns idiom in Go may make this possible, but it's hacky and
strictly worse than languages that can utilize generics and a more richly-
typed set of errors.

------
setheron
How do these shallow articles get upvoted so much ? they don't have much
specific information except very generic "developer productivity".

Let me give a specific example where moving to Go really helped our tooling:

Go has some great interfaces, specifically their net & ssh client. In order to
perform operations against some machines, we have to tunnel through bastions,
however we'd also like the tool to work when an operator has already ssh'd
within the region (the tool is installed on hosts as well -- so that long
running tasks can be performed).

It was easy to create HTTP clients that easily tunnel through an SSH
connection via Go's Dialer interface (present in the net & ssh package) or
just directly if no tunnel was needed.

~~~
tschellenbach
Actually moving to Go was a very thorough and long process. We did small
example projects and tried out many of the libraries we needed. The blogpost
is more of a high level summary of why Go is such a great language.

~~~
VintageCool
Did the Go implementation of the ranked feed use the algorithm optimizations
discovered while optimizing the Python implementation?

~~~
tschellenbach
No most of the optimization were Python specific. But of course development
time was a bit faster due to it being the 2nd time solving the same problem.

------
slackingoff2017
Why does anyone write web apps in Python? PHP? Ruby?

Modern Java and Go are so much faster than the alternatives that it's stupid
to consider anything else if performance is important.

Golang and Java can manage over a half million HTTP responses a second. Node
is pretty fast but why bother when Java is many times more mature in features,
tooling, and and supports concurrency... And uses less ram and is usually
faster. People moan about the "huge" Java runtime when JavaScript uses 3-5x
more memory and has a huge runtime of its own.

All the big companies are using Java and Go almost exclusively for high volume
endpoints and it blows my mind the amount of mental gymnastics some companies
go through to avoid following suit.

Java has come a long way since J2EE. These days it's asynchronous, non-
blocking, serverless, etc.. pretty much all the acronyms thrown around about
node except its not JavaScript, which IMO is a huge win.

~~~
ubernostrum
_Why does anyone write web apps in Python? PHP? Ruby?_

First: Because squeezing every last nanosecond's worth of performance out of
your web app is actually an extremely rare problem to have. And if you truly
cared about performance over programmer convenience, you'd practice what you
preach and build your web apps in hand-rolled assembly, but I'd bet a lot of
money that you don't do that.

The typical web application -- I'd be willing to bet over 99.999% of all
deployed production web applications serving requests today -- has a
bottleneck at the database and the network that dwarfs any overhead from
language performance.

I remember a bit over ten years ago when there was debate in the Python web
world about which templating engine to use to generate HTML. And people argued
endlessly over microbenchmarks of them, to figure out which was fastest, but I
remember one blog post which showed a pie chart of time spent in the average
request/response cycle. Nearly all of it was accessing the database, and
template rendering was a tiny, tiny sliver, so the author humorously labeled
it "obviously _this_ is the part we need to focus all our optimization work
on". Language choice is similar.

Second: Because what else your company does matters. Where I work, web
applications are how we expose data and interfaces to that data. But there's a
gigantic stack behind that, of data intake, data parsing, data processing,
analytics, the whole nine yards. It's all in Python, because Python has hands-
down the strongest ecosystem of any popular programming language for that
stuff. So the web applications which serve as the interfaces to the data are
also written in Python; it means we have one language to worry about, one
language to work in, one language every software engineer knows. I've been
pulled onto projects doing things that didn't involve web applications at all,
and I've been able to be productive because those projects were still in
Python, and I could read code and get up to speed on what was happening, and
take care of mundane things for a more domain-experienced person whose domain
expertise was then free to apply to things I couldn't do.

Third: Because programmer convenience really and truly does matter. When I
first started doing this nearly twenty years ago, people posted comments like
yours, incredulous at the idea that someone would use PHP or Perl given their
performance characteristics compared to Java (or C -- plenty of web apps used
to be written in C!). But even then we knew: servers are cheaper than people.
The average salary of a quality software engineer (or "web developer" as we
were known then) would buy you a lot of compute time, either on your own (in-
house or colo'd) metal, or nowadays on someone else's cloud.

So you choose based on convenience to humans. PHP, for all its faults, was an
_incredibly_ convenient language to write web apps in, and compared to the
usual CGI model that preceded it, was a breath of fresh air when it took off.
Today, frameworks written in Python, Ruby, PHP, etc. are similarly in a good
position compared to more heavyweight things like the Java world (which for
better or worse is still suffering the lingering effects of its mid-2000s
"enterprise" reputation), or even Go (which is still young and still seems to
come up short, both language- and ecosystem-wise, on some of the things actual
working web programmers want. In particular, programmer-friendly ORMs in
statically-typed language really really _really_ want generics or a good
equivalent, and Go's historic attitude toward that has not been great.

~~~
adwn
> _And if you truly cared about performance over programmer convenience, you
> 'd practice what you preach and build your web apps in hand-rolled assembly_

The performance gain from Python/Ruby to Java/Go is an order of magnitude
larger than the performance gain from Java/Go to assembly. The productivity
loss from Python/Ruby to Java/Go is an order of magnitude smaller than the
productivity loss from Java/Go to assembly.

Therefore, going from Python/Ruby to Java/Go _might_ be a good idea for web
apps, but going from Java/Go to assembly is virtually _never_ a good idea for
web apps.

~~~
ubernostrum
If you're disregarding programmer convenience in the name of performance, then
do it. But once you make the decision to trade off some performance for
convenience -- no matter how much or how little you give up/get -- you start
losing the high ground for preaching to others about how they should refuse to
trade what you see as inappropriate amounts of performance for convenience,
because now you're just arguing matters of degree and unquantifiable personal
taste.

------
carlisle_
> Python, Node and Ruby all have better systems for package management

Maybe they have better tools for managing package dependencies but Go doesn't
have to deal with interpreter dependencies, which can be a major headache. Go
also doesn't have the problem of conflicting system level packages.

Honestly no matter how good your deployment practices are, if you have to
manage an application's deployment long term you're going to have dependency
problems of some kind. I'd rather deal with those problems at compile time
than hit an edge case during deploy or in prod.

~~~
disconnected
> conflicting system level packages

In Python, if you have control over the target system, this is solved with
virtualenv. You can install whatever versions of libraries you want in there
with pip without causing conflicts with system level packages.

If you intend to ship to end-users, yeah, you are kinda screwed. You are stuck
using one of the various "freeze" methods, which, in my experience, kinda
blow.

~~~
hasenj
> this is solved with virtualenv

Except when you run into edge cases, which happens all the time.

~~~
gruez
elaborate?

~~~
jeffshek
Most of the time pip installs work fine, but once a while after some type of
OS upgrade (namely, my experience has been MacOS), you run into odd compiler
types of issues.

So it's why a lot of teams will use either Vagrant / Docker to setup local
developer environments.

~~~
0xCMP
Can confirm that once upgrading macOS required using Docker to be productive,
because some C-dep we had stopped working. We have developers using macOS
10.10 to avoid any issues (although they're likely gone by now, it's not worth
the effort to figure it out anymore).

------
BLanen
A thing that REALLY turned me off in go...

The fact that go's Math functions only work with floats. Idiotic.

You have so many packages that have to add the same freaking min(int a, int b)
function.

~~~
ryanpepper
Does Go have templating?

~~~
mmargerum
Templating is built right into the Stdlib
[https://golang.org/pkg/text/template/](https://golang.org/pkg/text/template/)

The only 3rd party library I pull in to build web servers is gorilla (routing,
sessions) and a database driver .

Everything else you need is in the go standard library .

~~~
vgbm
I believe the parent means templating in the sense of generic types:
[https://en.wikipedia.org/wiki/Template_(C%2B%2B)](https://en.wikipedia.org/wiki/Template_\(C%2B%2B\)).

------
Dowwie
Wait just one minute, Thierry...

Are you telling me that Python helped you create a viable tech-oriented
newsfeed and activity stream business, serving 500 companies and more than
200Million "end users"? That sounds like a great incentive for any
entrepreneur to get started with Python.

You've gotten this far by using the language you've turned away from! Further,
I'm confident you didn't solve every challenge you've had on your own but
rather did so with the help of the worldwide community of Pythonistas who
answer questions and help to solve problems.

It takes a village to raise a startup. Don't try to burn the village down
after you've grown up and can afford to explore other villages.

~~~
JelteF
Hi, Jelte from Stream here. The post was definitely not meant to indicate that
people should stop using Python. We still use it happily for the website and
I'm still a big fan of it myself.

However, for the API we've outgrown it in performance requirements. That's
what the article is about, together with the things we found during the switch
that we liked and disliked about Go.

~~~
the_mitsuhiko
I would love to hear your experience in two years though. I find the go
runtime incredibly lacking in terms of introspectability. That's okay if you
run google scale operations where you just throw away the environment on
deploys and you do not care about the individual processes, but if you are
running a reasonably lean operation the ability to see what a process is doing
is incredibly helpful. That even affects simple things such as error reporting
which is almost useless in Go to debug issues at runtime.

~~~
weberc2
These are good points. Stack traces in Go are a matter of discipline while
they're free in Python. That said, I think Go brings a lot to the table even
for a lean operation which more than compensate for these weaknesses. Probably
the biggest advantages are that Go deploys as a single binary, and one Go
process is sufficient to make efficient use of the machine's resources--no
need for something like it's uwsgi. At our small Python shop, we probably have
two full time positions dedicated to managing our Python installation process.
This could conservatively be halved with Go. Beyond that, we have a couple
more full time positions for managing the fleet of servers required to run or
applications--Go could easily reduce our machine demand to 2 or 3 (including
redundancy) which would probably require just one engineer to maintain not to
mention the savings on our AWS bill. These are just a couple of obvious
benefits to Go, but for us this isn't enough to justify a rewrite.

------
tschellenbach
Author here. Super cool to see this post on HNews.

For those of you working with Go. One of the guys on our team wrote a little
tool called VirtualGo. It's pretty handy when you're working on multiple go
based projects
([https://github.com/getstream/vg](https://github.com/getstream/vg))

~~~
aeriklawson
Thank god something like this exists. I _gagged_ at the workspace structure
when I first started Go - it gave me enough pain starting out one weekend that
my interest faded away. I've been looking for a reason to try it out again and
a bunch of comments here got me really excited again.

------
hasenj
I think there's a great value in code being straight forward and simple and
that is very much not appreciated among many programmers.

A good language enables you to "compress" your code without making the code
flow impossible to follow.

A bad language encourages you to obfuscate the flow of the program using wacky
abstraction techniques.

Go doesn't exactly hit the sweet spot for semantic compression due to lack of
compile time programming (aka generics?), but it does a good job of making the
flow of the program pretty clear.

~~~
albinofrenchy
I tried using Go this weekend and basically just abandoned it when I learned
that it only had 'generic's for three built-in types and other than that you
are forced to essentially dynamic cast everywhere.

I just don't get the appeal. Go seems a lot like what you'd get if you just
removed every language feature that anyone has ever complained about; for good
reason or not.

~~~
hasenj
It seems like the domains where Go is used often don't make heavy use of
custom containers or data structures, so that makes the pressure on the
language makers lower than it would otherwise be.

~~~
dingo_bat
Or the other way around.

------
servbot
Thank you for the insights on Go and how Go has added value to your
organizations and enabled a better environment for development at your
organization! I love hearing viewpoints on tradeoffs and general evaluations
on value of new(ish) development technologies.

I'd also like to point out that I write this a Python-phile that has come to
the understanding that Python is great until it isn't. When Python becomes to
burdensome, the understanding of the problem delivered by my Python sketch
helps to narrow the focus of what I need to solve the problem efficiently. By
that time, Go has never been the correct tool _for me_. I'm comfortable
writing solutions in C, Rust and Java, perhaps this is my problem.

Whenever I read or write Go I don't understand how it managed to capture the
mindshare that is has. Especially in the face of other technologies available,
Go seems like a timid step forward in descriptions of computation, when there
are bolder choices that deliver valuable additions to my development
ecosystem.

I appreciate that Go places a premium price on simplicity, however with
languages like Rust make some big steps towards static guarantees at compile
time the guarantees that Go makes seem pretty weak. But I feel that when I
make the leap from Python to Go, I admittedly don't understand the allure.
Static compiltion is really nice! Statically linked binaries for distribution
is very nice! The tooling is out of this world! Hands down, Go has one of the
best out of the box toolchains I've ever encountered. But when helping me
think about computation, Go doesn't.

Go's concurrency primitives don't feel like a great deal of a step forward
compared to C. I know, I know, this is crazy talk. I feel like I am missing
some great wisdom about Go, I truly do. Concurrency is really hard and Go has
clearly helped a lot of people minimize concurrency problems. But whenever I
use channels I am reminded Go does not allow me to shut my brain off, and
whenever the deadlock bug strikes, I feel that I might as well be writing C.

I don't mean to disrespect Go and the great things it does, the opposite of
that! I am hoping Go delivers a bulletproof abstraction for concurrency. Until
then I've become too familiar with other tools to justify using Go for more
than incredibly niche use cases. I really hope that will change (both my
mindset and Go)!

~~~
catnaroek
> I appreciate that Go places a premium price on simplicity, however with
> languages like Rust make some big steps towards static guarantees at compile
> time the guarantees that Go makes seem pretty weak.

Rust's static guarantees come at a price: You have to learn Rust to take
advantage of them, which is apparently no mean feat.

> I am hoping Go delivers a bulletproof abstraction for concurrency.

Don't hold your breath. Go has always been and will always be about “good
enough”, not “bulletproof”.

------
omegaworks
>Reason 3 – Developer Productivity & Not Getting Too Creative

There is a time and place for these tools. A part of managing a team is
ensuring there are good practices around "getting creative" and that there is
a clear rationale. Python's metaprogramming came in handy for helping us
provide a high level syntax to work with our data model.

~~~
dvt
I'm happy that Python's metaprogramming came in handy for you and your team,
but Python's propensity for DSLs is one of the reasons I loathe it so much. I
guess in the context of data science, a DSL makes sense, but it's a nightmare
to debug.

~~~
camus2
> I guess in the context of data science, a DSL makes sense, but it's a
> nightmare to debug.

What do you think struct-tags are? it's not like Go is free of DSL either. In
fact the std lib itself uses them. Let's not pretend Go is without fault on
that matter.

------
andrewgodwin
I would agree with some of the points - speed (which is stretched over two
points), concurrency, and the ability not to do magic as easily, but several
of the points (compile time, available developers, strong ecosystem) are not a
"versus Python" at all but rather against other languages.

Personally, I see a language like Go and Python as solving different spaces. I
wouldn't write a lot of website business logic in Go, and I wouldn't write a
low-level TCP redirection daemon in Python.

~~~
tschellenbach
Yeah there are some use cases where Python is a clear winner. For us Python
seemed like a good fit initially. Traffic was low and the API didn't provide
more advanced features where Python's speed becomes an issue. (Ranking,
aggregation)

------
yedpodtrzitko
We are switching from Python to Go, because:

> Reason 7 – Strong Ecosystem

> Go’s ecosystem (...) it’s of course not as good as (...) Python.

Then why do you put that as a reason to switch?

~~~
Liquid_Fire
Similarly,

> Reason 5 – Fast Compile Time

------
sitkack
If you can switch from Python to Go, you weren't using Python anyways, you
were use Gothon or Javthon.

If you want static binaries, great tooling and an excellent imperative and
functional language, try F# with mkbundle. The compelling reasons to use go
are shrinking.

~~~
Scramblejams
Would love to, but what I would miss from Go is that low latency GC. If ya
need it, ya really really need it.

If only somebody wrote a nice ML that compiled to Go! I love a lot of things
about Go, but the language certainly isn’t one of them.

~~~
dualogy
I'm hacking on a PureScript-to-Go transpiler (ie. alt backend for existing
PureScript compiler once PR #3117 gets accepted). Watch
[http://github.com/metaleap/gonad/](http://github.com/metaleap/gonad/) \---
hoping to "get there" within 2 weeks. Taking unreasonably long already, given
that purs already does its jobs on its own like parsing, type-checking,
transforming-ML-to-imperative. One reason I'm taking a bit longer than the
quickest-dirtiest approach would, I want to preserve the type information as
much as possible rather than have all functions accepting and returning and
passing `interface{}`s in a JS-like manner. Ie it's meant to generate sane
readable human-like idiomatic Go code. Type-classes mapped to interface types,
etc. Will also have to attack the need to have any Go package be represented
readily on the PureScript side as an existing module that'll show up in auto-
complete and pass compilation, so to quickly auto-generate some kind of dummy
FFI bindings whenever a Go-land dep is imported and used. Fun ride!

There's clearly value in combining Go's compilation speeds, stdlib
functionality, rich ecosystem, lean fast binaries, GC etc with a rich and
cutting-edge Haskell-ish/ML-ish type system (and the leaner syntax and
compressed idioms). Will be great for clear thinking and expressive high-level
type-driven dev and DSLs (and naturally, implicitly generics/code-gen haha),
without having to wrestle with GHC/cabal/stack build annoyances/times and
Haskell's whacky academic overly-PhD-ish "wrappings" around raw
straightforward real-world needs such as http-server and db-client, where
again the Go ecosystem shines.

~~~
Scramblejams
Thanks for the tip! I'll keep an eye on it.

------
yeukhon
> Python allows you to get pretty creative with the code you’re writing. For
> instance, you can:

> Use MetaClasses to self-register classes upon code initialization

Avoid metaclasses....

> Swap out True and False

Not possible anymore

> Add functions to the list of built-in functions

What are the practical reasons?

> Overload operators via magic methods

Useful but also recommend don’t. I can see someone writting numpy would do
that, but most applications don’t have a reason

Profile profile profile! Find the bottlenecks.

~~~
yen223
"Avoid metaclasses...."

Good luck finding a Python library that doesn't use metaclasses anywhere!

~~~
mrgriffin
How about Requests?

[https://github.com/requests/requests/search?utf8=%E2%9C%93&q...](https://github.com/requests/requests/search?utf8=%E2%9C%93&q=metaclass&type=)

------
neilwilson
You can tell a lightweight article when you read that all you need to do to
get concurrency working is stick 'go' in front of a function call.

I must mention that to the LVM developers dealing with my latest lost wakeup
problem.

------
drej
Instead of all the 'we replaced x with y', I'd like to for once read something
along the lines of 'we started using x and y side by side, embracing the
benefits of each'

I use both Python and Go regularly and the use cases rarely overlap. They are
both fantastic languages and once you realise what you want to use each one
for, you'll be one happy developer. (Applies to many other combinations of
languages.)

------
pjmlp
Right now, Docker, K8s and their adoption among Microsoft, Oracle, IBM are
what keeps me keeping up with what goes on Go, because "hey we need to write
some stuff in Go here".

For me Reason 3 is exactly the opposite, if I have to spend time manually
writing code that other languages give me for free, I am anything but
productive.

------
ojhughes
Performance shouldn't be a compelling reason to change the language for a
project. If they have truly benchmarked, profiled, reworked hotspots using
Cython and looked into major bottlenecks such as IO and Python still isn't
performing up to scratch then fair enough.

------
seunosewa
> Go’s fast compile times are a major productivity win compared to languages
> like Java and C++ which are famous for sluggish compilation speed.

C++ is famous for sluggish compilation speed, but Java is not. Java code
compiles pretty quickly; it’s a simple language.

~~~
tapirl
Neither is java a simple language, nor does Java code compile quickly, in my
experience.

However the largest disadvantage of Java is Java programs generally consume
more than 10x more memory than the same scale Go programs, and need 20x more
time to fully to warm up.

I do admit Java is more consistent than Go from the syntax design view.

------
matt_wulfeck
> _Go forces you to stick to the basics. This makes it very easy to read
> anyone’s code and immediately understand what’s going on._

I think all new language design _must_ incorporate this goal going forward.
It’s been simply too valuable. When I see something introduced that does x, y
incrementally better but makes no effort for the above goal I get sad and move
on.

It’s easy to get caught up in the technical challenges of a language, but this
meta challenge is what really helped move the ball forward with Go, and I’d
love to see it introduced as a first-class goal in new language design.

~~~
_pmf_
Some people insist on being obtuse (coincidentally, I'm looking in the general
direction of a template heavy C++ user), and for worse or better, personal
preference is a large factor in language adoption as opposed to what works
best for the industry as an engineering practice.

------
hprotagonist
when you list as a con "package management", meaning "go is even worse than
python"... man.

------
TeeWEE
I cant help to feel that in Go performance is more important that developer
productity. Go is the new C. The code looks a bit clunky, with lots of error
checks.

I rather work in a language like Python or Kotlin where the code just looks
like how you would think the code would like (if i would write it in
pseudocode on paper)

However Go in big teams will really be nice. Thats why they invented it in the
first place.

------
dingo_bat
I'm surprised to see that people choose anything other than C++ if they care
about performance. Are you really trying to profile and optimise python and
go? It will never be worth it! Just write the same thing in good modern C++
and you get an automatic 100x speed up for most cases. Then optimise to reach
the absolute limits of the hardware. Python and go it seems!

~~~
criddell
Some people choose Go rather than C++ for the same reason you went with C++
rather than an assembly language.

Most of the time, things only need to be fast enough and trading speed for
ease of development, deployment, and maintenance is an easy decision to make.

------
crimsonalucard
The guy didn't even mention type checking. Guess it's not a big deal to him.
Zero type errors during runtime is a big deal.

~~~
mmirate
That's a very good thing for a language to have, indeed. But Go isn't the best
thing to look into for productivity-via-the-type-system. What _is_ (barring
the purely functional languages' learning curve) is most any ML descendant;
albeit Rust in particular if Go-like performance is desirable.

~~~
crimsonalucard
Rust is descended from ml? Isn't Rust a algol based language? Is it
functional?

~~~
FreeFull
OCaml was a really strong influence on Rust. The first Rust compiler was
written in OCaml. Rust's traits are also similar to Haskell's typeclasses.

~~~
mmirate
Rust also has discriminated unions, structural pattern matching and local type
inference.

------
pmattos
A nice write up generally. I just feel he should also mention the classic
static vs dynamic typing thing. From my perspective, teams switching to Go —
from dynamic typed language such as Python — _really_ appreciate the
additional compiler help it provides ;)

~~~
sametmax
You have type checks in python if you want them. It's just opt in.

------
ollieco
I've done a fair bit of web dev work in Python but I am currently building my
startup ([https://www.growthmetrics.io](https://www.growthmetrics.io)) in Go.

It is in the initial stages, but so far it has been pretty good - both as a
learning experience and from a developer productivity perspective.

I've also open sourced a web app boilerplate that I extracted from
GrowthMetrics' codebase -
[https://github.com/olliecoleman/alloy](https://github.com/olliecoleman/alloy).
It might be useful for people looking to get started with Go.

------
qaq
IF you like Python but need performant compiled alternative take a look at
nim.

------
jancsika
> Our largest micro service written in Go currently takes 6 seconds to
> compile.

What's the biggest, beefiest real world program yet written in Go, and how
long does it take to compile it?

~~~
btym
Docker takes about 10m to build:
[https://jenkins.dockerproject.org/job/docker/job/docker.gith...](https://jenkins.dockerproject.org/job/docker/job/docker.github.io/job/master/1606/)

Kubernetes takes about 16m:
[https://k8s-gubernator.appspot.com/build/kubernetes-
jenkins/...](https://k8s-gubernator.appspot.com/build/kubernetes-
jenkins/logs/ci-kubernetes-bazel-build/223299/)

~~~
takeda
Doesn't sound too fast, that's about how long it takes for FreeBSD kernel to
be compiled[1] and I would imagine a kernel is more complex. The whole system
takes about 50 minutes[2]

[1] [https://ci.freebsd.org/job/FreeBSD-head-
amd64-LINT/buildTime...](https://ci.freebsd.org/job/FreeBSD-head-
amd64-LINT/buildTimeTrend)

[2] [https://ci.freebsd.org/job/FreeBSD-head-
amd64-build/buildTim...](https://ci.freebsd.org/job/FreeBSD-head-
amd64-build/buildTimeTrend)

~~~
cdoxsey
Go's main compilation performance gains come from incremental compilation.
Since C++ doesn't have real module support merely parsing the entire
dependency graph from headers can take a very long time. In go if you have .a
pkgs for all your dependencies your program will compile very fast.

If you use docker as part of your ci build the dependencies as a separate step
so they can be cached between builds. This is especially important for
libraries like sqlite, which can take a lot longer to compile.

------
atilaneves
Since when is Java famous for sluggish compilation???

------
mjevans
The only thing actually missing from Go's standard library that I've wanted is
an abstraction of 'native' UI things (assuming you're compiling for a
graphical platform).

For portability there is shipping your a widget set (QT is OK for this if your
licencing needs are compatible with either case).

------
pryelluw
Re: frameworks

My experience with the language (building multiple production systems) is that
the language itself is sort of it's own framework. You don't need to add much
to build an application with the standard library. Which is a huge plus and
makes things simpler.

~~~
pjmlp
That applies to all languages with exception of C, because they didn't want to
standardize it as part of the language, hence we got ANSI C + POSIX instead.

~~~
simias
Don't forget Javascript which is ridiculously under-featured natively. At
least C has the excuse of having to run on the bare metal of a wide range of
architectures.

------
kanishkdudeja
Here is a similar piece if someone is interested:

[https://hackernoon.com/the-beauty-of-
go-98057e3f0a7d](https://hackernoon.com/the-beauty-of-go-98057e3f0a7d)

------
catnaroek
> Another great aspect of concurrency in Go is the race detector. This makes
> it _easy_ [emphasis mine] to figure out if there are any race conditions
> within your asynchronous code.

Am I reading correctly?

~~~
squiguy7
It can be a bear to try and track down some race conditions but at least it
will not report false positives. However, it will not catch all race
conditions or data races you may have.

~~~
catnaroek
Is Go even memory-safe in the presence of data races? Don't get me wrong,
“memory safety” isn't a hard requirement in my book, but “memory safety or a
formal semantics” is.

~~~
cdoxsey
If you're curious, the behavior is well defined: golang.org/ref/mem

~~~
catnaroek
My English reading comprehension is admittedly poor, but I don't see any
portion of the text that automatically implies that unsynchronized reads and
writes are atomic.

------
StreamBright
I like these "Why we switched from X to Y" articles. I can be summarized in
one sentence most of the time. "Because it supported our use case better."

------
apple4ever
It has func and var compiler hints, which I hate (just like in Swift). Its
harder to read too (just like Swift).

I'll stick with Python.

------
k_bx
The post never mentions PyPy. Have you tried it? Could increase the
performance dramatically for free.

------
gbersac
Did you consider scala ?

I use it at work, and it is awesome. It has awesome error handling
(Either/Option >>> exception) on my opinion, a much stronger type system (many
errors are checked at compile). It is harder to learn, but you also have top
notch package manager with the even bigger scala + java ecosystem.

------
radiowave
"Plan to throw one away. You will, anyhow." \- Fred Brooks

------
luord
Oh, terrific, another one.

The only solid reason this article gave was the second one and, really, is the
only one that would ever make sense: If the language one's using becomes the
bottleneck then, by all means, change it[1].

Everything else is fluff and opinions. Every single other reason is stuff that
is entirely subjective and/or python already has and even the article itself
acknowledges, at least for one "reason", python as the better option.

Well, at least they tried to be impartial by mentioning the absolutely odious
error handling in Go. It's the biggest reason I became so disillusioned with
the language once I actually tried it.

[1]: _I_ , however, would try switching CPython for pypy before rewriting the
entire architecture from scratch. It's more performant.

~~~
eadmund
I don't think that performance is the key reason to switch from Python to Go
(although it _is_ nice): as someone who switched from Python to Go, what
really made it worthwhile for me was knowing that my code is _significantly_
more likely to be correct when it runs. Go's typing is much nicer than
Python's, for this use case.

Performance is just gravy.

~~~
thesmallestcat
Type errors/misuses aren't my biggest problem and Go's type system isn't very
powerful. The Python code is smaller, more expressive, easier to review, etc.
I have more confidence in the correctness of pylinted Python code. I wouldn't
jump to trade conciseness for compile-time type safety, particularly for
applications, because it's easier to create/not see a logic error in heavy
code. And depending on what you're doing, Python's type system may be more
powerful/appropriate.

------
charred_toast
You had me at 4. I'm definitely GOing to give this language a GO now. That was
a GOod introduction to the language, a veritable advertisement, if you will.

~~~
charred_toast
The audience on Hacker News takes themselves way too seriously, apparently.

~~~
charred_toast
Case in point. Thanks. Also, the moderators seem to have no life. Please
deactivate my account if you're offended. I'd prefer not to spend more time
attempting to communicate with one dimensional, armchair experts.

