
Why Tech Startups Should Look at Go - ardan-bkennedy
http://startupedmonton.tumblr.com/post/107921476571/why-tech-startups-should-look-at-go
======
ryeguy
Essentially all of the quoted usecases switched from a slow dynamically typed
language to Go. Of course that's an improvement.

But I still don't see why you would choose Go over Java (or Scala) for serious
backend development. Java has more libraries, is faster, has generics (for the
love of god), has better IDE support, and has a larger hiring pool. In
summary, the ecosystem is more mature.

Java's checked exceptions are less painful then Go's C-style error handling.
They could have gone with something sane like Rust/Haskell style error
handling (using the type system), but they instead regressed to return value
checking.

The complaints about Java's overwhelming verbosity are mostly dated both on
the language-level and the ecosystem-level. Java 8 has lambdas, streams, and
more. Spring Boot and Dropwizard are 2 modern, lightweight frameworks that do
away with the XML configuration nonsense.

I'm actually genuinely asking why anyone would choose Go over Java and not
trying to start a flame war. An API I'm working on is due for a rewrite and
it's currently written in PHP. I'd like to give Go a chance but it just seems
like a poor choice compared to Java.

~~~
voidlogic
>But I still don't see why you would choose Go over Java (or Scala) for
serious backend development.

    
    
      1. Less verbose code
      2. Platform Ind. + native binaries, no runtime dependency
      3. Built in unit testing/benching
      4. Fast compile time
      5. Better tooling, no Ant etc needed
      6. Better core language support for multithreading/concurrency
      7. A memory model that makes it easier to read the code and understand how the resulting data will be layed out in memory
      8. Related to 7, better stack vs heap allocation control
    

>Java has more libraries

Many of which are of low quality / filled with code-rot, I used to play in the
Java ecosystem the Go stdlib is cleaner and the Go 3rd party libraries tend to
be better, more single function.

>is faster

This is not always the case and is changing for Go's better fast. To paint Go
as non-competitive would be unfair as its in the same league as Java and it
usually faster than C# Mono.

>has generics (for the love of god)

I used to miss this, but I find I don't anymore... I wrote proxies, databases,
systems applications.

>has better IDE support

True. This used to pain me until I found LiteIDE and I started writing unit
tests more and using the debugger less. Go's profiler is awesome though...

>and has a larger hiring pool.

Not really, any smart C/C++/C#/Java developer can be highly productive in Go
in weeks.

>In summary, the ecosystem is more mature.

A double edged sword mind you, not to mention Go is maturing at faster rate
then Java did.

>Java's checked exceptions are less painful then Go's C-style error handling.

No. C++/Java got it wrong, ignoring error paths lead or letting random low
level errors bubble up are some of the horrible results of the Java way to
handle exceptions.

Forcing programmers to consider which operations may fail- how to handle those
failures is one of the best decisions Go made. Multiple returns make this much
less painful than C.

~~~
pjmlp
> 2\. Platform Ind. + native binaries, no runtime dependency

Also available in Java. It is just a matter of choosing the right compiler.

Java like many other languages, enjoys a standard, certification process and
multiple implementations to choose from.

~~~
voidlogic
GCJ is dead. Are you referring to proprietary implementations?

~~~
pjmlp
Yes, who still bothers with GCJ? I really don't understand why GCC still ships
it.

However there are also open source implementations like RoboVM and JikesRVM,
among a few others.

------
onion2k
AWS is cheap enough that "throw more hardware at the problem" is a viable
option for most startups. So long as you're not being completely stupid with
the way you've coded the first version, pretty much any language is going to
work, and the cost of people who can code well in more esoteric languages that
_might_ be better suited to the problem domain are going to be increasingly
expensive. Obviously there _is_ a time to rebuild with technologies that scale
better than what you started out with, but I doubt all that many startups ever
actually get to that point.

~~~
bad_user
I don't think you've ever calculated just how much that cost is.

Lets say that you have a web service that is serving 30,000 requests per
second, with a 1 Kb request size and a 4 Kb response size and you're setting
up an elastic load-balancer setup that on average keeps 300 c3.xlarge
instances open.

Do the math and you'll find that the cost on AWS, considering the instances
used and the bandwidth, is over $80,000 per month. And that's a conservative
example, since by my calculations that's about $1,000,000 per year and I know
companies paying much more than that.

Don't know what startups you're thinking about, but from where I'm standing,
for startups that's a recipe for burning cash.

~~~
onion2k
30,000 requests per second is 2,592,000,000 per day... That's quite a lot.
Obviously we're not talking page views (because that'd be _crazy successful_
and well beyond 'startup' territory), so we're presumably in the domain of
data logging, analytics, social networking etc. Sure, AWS might not be
appropriate for those. But then, the level of traffic you're talking about
represents maybe 0.1% of startups. People doing "a CRUD app for a niche",
which is most SaaS startups TBH, could run their software on 1 AWS medium
instance for the first year or two quite happily.

~~~
bad_user
You're right, we aren't talking about page views or CRUD, but it can happen in
a B2B application.

I ended up working for a startup like that, so this was a real anecdotal
example. Our stuff was built to run on the JVM and we managed to get away with
a variable number of instances between 15 and 30 (at the time we used
c1.medium, which are now deprecated) - AWS's ELB is great in such a scenario
as it can be configured to bring up new instances in case of traffic spikes,
or kill them in case they were unused. So for us, AWS was saving us money,
however that's because we were very efficient.

My opinion is that if you're expecting your startup to grow soon (and I'm not
talking about wishful thinking, but about requirements that have to happen for
survival - i.e. you either get the desired contracts or you don't), then you
have to prepare for it.

------
MCRed
While go has some nice features-- standalone executables and fast execution
are two. I don't really see a compelling reason to switch to it from
Elixir/Erlang.

Biggest downside seems there's no real easy way to handle errors being
returned from function calls.

Easier deployment would be good, but once you solve it for elixir it's not a
big issue. On the other hand Erlang is very well tested and established and
pretty complete-- though go's libraries and open source support is growing by
leaps and bounds.

So really, it's that error issue. Oh, and pipe. I really love elixir's pipe (
|> ) operator.

~~~
Thaxll
Let be honest here, who really use Erlang? How do you find people that knows
this language?

~~~
MCRed
I've recruited and built a team which was writing code in Elixir, even more
obscure than Erlang. It wasn't really a problem finding people who knew it or
were strong programmers who were interested in it.

Good languages attract good programmers.

The idea that we need to stick to popular languages is, I think, driven by
business guys who want commodity programmers.

If you want 100 engineers added to your team in a year, then sure, use Java.
But you will still be less effective, I bet, than 10 engineers doing erlang in
that same year.

~~~
kyrra
I would argue that you can pick any new'ish (last 5 years) language that is
suitable for development and find the same results. Anyone who knows the
language well taught themselves how to use it without the guarantee of being
able to use it at a job.

This will be a fairly small subset of developers, the ones that have
motivation and time to put into growing themselves. So this probably means
that the devs that know new language X are just more interested in software
development (compared to devs that just know the language(s) they learned in
school, and whatever they were taught on their jobs). So they have a much
higher chance of being good developers.

------
emehrkay
I watched the Rob Pike Concurrency is Not Parallelism video
([http://vimeo.com/49718712](http://vimeo.com/49718712)) a few days ago and
thought that "maybe I should be using Go instead of Python." Then I thought
about all of the work that would have to be redone, all of the learning that
I'd have to do, all of the retooling, all of the etc., just to get back to
where I'm at now. If I were starting again Id probably start with Go,
probably.

~~~
NateDad
2/3rds of our devs working on juju hadn't written a line of Go before they
were hired. Getting up to speed on Go is very far (like a week to get
productive). Many of them have very Python heavy backgrounds. Just dive in,
it's easy.

------
nkozyra
Tech startups who hit this phase (or "wall," as it's described here), should
look at _all_ options. Even if Go is the best technical option, it may not be
the best business decision. That's an unfortunate reality for startups - if
you can't bring in the staff you want / need, the best tool for the job might
not be the right one.

This ends up being another pro for the distributed microservice model,
allowing some experimentation and internal learning in new languages without
impacting an entire product.

~~~
voidlogic
> Even if Go is the best technical option, it may not be the best business
> decision

Why might Go not be the best business option? I see technical case for or
against Go as very much religious and shaped by personal preference. But what
could be a business reason not to use Go for a new startup that is independent
of the technical side?

~~~
0xCMP
You could assume that Go, although popular, isn't at the level of Python and
Ruby in terms of available developers. The ones that would know Go are most
likely very good and also expensive compared to just finding that one
Ruby/Node/Python programmer of the many out there which will go low enough and
suddenly Go doesn't make sense anymore for startups without the cash.

~~~
voidlogic
>You could assume that Go, although popular, isn't at the level of Python and
Ruby in terms of available developers.

Not really, any smart C/C++/C#/Java developer can be highly productive in Go
in weeks.

Side thought: If your startup isn't on the west coast, C/C++/C#/Java
developers are far MORE common than Python/Ruby devs. Although C/C++/C#/Java
developers are not rare anywhere.

------
orenbarzilai
at the end of the day, on the first days of (most) startups you focus on
showing results as fast as you can. Prototyping languages (Pyhon / Ruby etc)
are the right choice.

Nice stories about how iron.io reduced 30 ruby servers to 2 go servers became
relevant only after they proven good market fit and working growth engine.

So GO? maybe yes but probably only when the prototyping languages, can't carry
weight.

~~~
falcolas
I have found Go to be high level enough to make prototyping very
straightforward.

~~~
orenbarzilai
Define "high level enough" python / ruby are much faster...

~~~
falcolas
Exactly what I said. Just like Python/Ruby can be "fast enough" to do many
things, Go is "high level enough" that I don't have to spend too much time
thinking about the lower level details.

The few seconds of difference is small enough that it effectively does not
matter.

For example, I don't have to worry about maps (dicts, hashes, etc); they're in
place, but require one additional statement before they use them. I don't have
to worry about array lengths; I can just use append(). I don't have to worry
about finding a third party library to do network requests, it's part of the
standard library (and doesn't require too many convolutions to use).

I do have to think a bit more about pointers when writing function signatures
in Go than in Python or Ruby (not that those two languages really free me from
that concern: some structures when modified in a function modify the
underlying data from the callee as well).

------
copsarebastards
It's not at all surprising that those startups solved their problems with Go:
if you switch from a language that doesn't address your problems to one that
does, you're going to see a big benefit. But there are lots of languages that
address the problems mentioned by those startups, and I think that Go is
possibly the worst of the options.

It's telling that none of the startups in question switched out of a language
which provides good compile-time type and thread-safety guarantees:

1\. iron.io: ruby -> go 2\. SendGrid: perl -> python -> go 3\. TJ
Holowaychuck: node.js -> go

Go would have a reasonable compile-time type system, except that without
generics you end up having to cast a lot, which renders your compile-time type
system almost irrelevant.

It's also telling that none of the authors mentioned experience with
functional programming. Go supports some functional programming, but it
doesn't seem to be a very big part of the language. The only one who mentions
that they even considered any functional languages is the iron.io guy, and it
seems like a big part of his choice was not technical: he mentions that he had
to sell the idea of Go to his team by mentioning that Google supports it. A
language that was a more serious paradigm shift (OO -> functional) would have
been an even harder sell.

(EDIT: Okay, the SendGrid guy did mention considering Scala.)

The fact is, there are a bunch of languages that would have solved their
problems, in addition to a few they didn't know they had. Julia has coroutines
similar to Go, but is much more expressive, Rust has a more traditional
threading model but a type system and focus on immutability that provides
better safety guarantees. There are other choices, but those two stand out as
the major ones that could have solved their problems better than go.

~~~
rogpeppe1
> Go would have a reasonable compile-time type system, except that without >
> generics you end up having to cast a lot, which renders your compile-time >
> type system almost irrelevant.

In my experience of Go, this is not actually true. For example, in the latest
project I've been working on, there are 8487 lines of non-test code. In that
code, there are a total of 16 dynamic casts, more than half of which are
checked (mostly checking for particular error types). There are a total of 4
occurrences which might possibly be amenable to generics.

The type system is totally relevant, and checks 99.9% of our code.

~~~
copsarebastards
How do you deal with container-type classes? The only way I can see to do this
without casts is to duplicate the same container class for each contained
type, which is fraught with its own problems.

------
ChikkaChiChi
If your team has a common skillset that can be used to rapidly and efficiently
deliver a thing and you don't yet have the same confidence in your collective
Go abilities: do not use Go.

Otherwise, feel free. Not sure why this is such a huge point of contention.

------
amencarini
The Iron.io blogpost was what got me looking into Go. As a Rubyist it was
quite eye-opening!

~~~
codygman
You'd probably enjoy Haskell more than Go as a Rubyist imo. Most Rubyist I've
known seem to really like Haskell.

------
mrcwinn
Here's my take on this as someone who loves both Go and PHP (yeah, I know!). I
agree that startups can get entrenched in their legacy code, but I also think
there is a false choice here:

1\. Write with a system language from the start. Yikes!

2\. Do a total rewrite of your application later when you hit scale issues.
Yikes!

In my opinion, though, Go is not well-suited (today) for rapid prototyping or
web application development, even with some of the frameworks. This shouldn't
be a surprise. Go is a systems language.

I think languages like PHP, Ruby, and the lot are much better suited early
stage startups. When you hit problems of scale, it's very straight-forward to
isolate parts of your application that do not scale well and translate those
components to Go.

Introducing Go for only the components that require high availability and
guarantee a level of performance / memory safety as an _iteration_ to your
original application code is probably a much saner choice.

------
nine_k
tl;dr:

* Stratups don't have time to rewrite the prototype the right way, and then hit the performance wall.

* A few startups explain how Go is faster and more reliable than Ruby/Rails, Python, and JS/Node.

~~~
voidlogic
Some thoughts on those points.

>Startups don't have time to rewrite the prototype the right way, and then hit
the performance wall.

I would guess that for experienced C/C++ programmers (and probably C#/Java) Go
isn't going to be slower to build in than Python/Node etc. I actually build
things the fastest right off the bad in Go... I've ported node.js applications
to Go, and let me tell you it was not fun. Even if the first throw away
prototype was in Go, it would have made the rewrite much easier.

>A few startups explain how Go is faster and more reliable than Ruby/Rails,
Python, and JS/Node.

Considering Go was built to compete with Python/C/C++/Java at Google I would
hope so. I think a key metric that often is left out is maintainability. I
think Go's very straight forward code (which some people call boring) is an
asset here.

------
jonpress
Node.js is way better than Go! It's more expressive, more flexible and more
portable.

... Thanks for the downvotes. Well worth the bad karma :)

------
maxer
its hard enough to hire decent developers never mind decent go developers

------
jonpress
Gophers love to quote TJ Holowaychuk to justify choosing Go over Node.js. In
my eyes, TJ is a traitor - If he preferred Go, that's fine - He could just go
ahead and use it as he likes, but he wrote a post completely debasing Node.js
without pointing to any real, concrete issue.

I bet he is still using Node.js from time to time - The 'Goodbye' article is
obviously just a stunt.

He probably cashed out! I read somewhere that he got a decent sum for his
Express framework. I would be interested to know who else is behind this.

~~~
perturbation
Speaking only for myself, I've found the following to be broadly true with
Node.js and Go:

If I'm building a strictly server-side app using Express, it's a joy to use
Node.js (especially for a prototype) - everything more or less works, and the
NPM ecosystem is rich and broad. Very easy way of getting a RESTful JSON API
up-and-running from FooDB.

If I'm building a client (web scraper, getting stuff out of an API to load
into R, etc.) then I really quickly run into "Too Much Concurrency" TM with
Node. I quickly find myself building something with Go (or Ruby) to do the
following:

\- Limited Number of workers

\- Automatically re-try request N number of times if fails, depending on
response code

\- Log all successes/failures

\- Throttle total # of requests/second based on site-specific rate limiting

To make the above work in Node, I have to use caolan's async + Q promises +
other libraries (or write in Icedcoffeescript, which I like but is very weakly
typed and has inferior tooling) and find myself refactoring most of the small
script just to fit into the async libraries. With Go, I can use mutexes or
simple channels to control throttling, and do whatever I want with errors.
There's a lot of boilerplate to get the above up-and-running robustly for
Node, or at least that's been my impression the last few times that I've used
it. Node has solutions for advanced concurrency (Generators, promises, CSP
libraries), but why reinvent the wheel when Go has that out of the box?

