
The Selection of Go at Apcera - timf
http://www.slideshare.net/derekcollison/go-conference-japan
======
shurcooL

      "Google starting to kill off projects, would Go be on that list?"
    

Key difference here, unlike Reader, golang is fully open source. So even if
they did (which is unlikely because it is good and used by Google itself), it
could survive that and still thrive. I feel it's got enough critical momentum
even at this point (and even more so in the future).

This is one of the main reasons why I believe in its future and feel
passionate about it. They started off right by making it open source. I would
have very mixed feelings if it were closed.

~~~
continuations
Remember Unladen Swallow? It was open source. It had non-Google contributors.
It was going to be the future of Python. Google was a heavy Python user and
_needed_ Unladen Swallow to succeed. It had a specific, ambitious goal. And
then it just fizzled out because Google reassigned its people.

Will Go survive (and thrive) if Google pulled its support?

~~~
zellyn
Unladen Swallow never released a version 1, let alone 1.1. Also, clearly,
Google did did not _need_ Unladen Swallow to succeed...

------
jallmann
Were Node.js and Go the only two choices considered? Erlang, Haskell, etc seem
like they would fit the choice criteria, save for dependency management which
is generally handled externally via rebar or such. Works pretty well though.
Moreover, Erlang has solutions for the listed pain points of Go -- an
excellent scheduler, fast GC thanks to per-process stacks, mature libraries
including HTTP, crypto, etc.

Perhaps if they had spent more than 15 minutes deciding on the language...

~~~
voidlogic
Go 1.1 which will be out soon (maybe this month?) addresses a lot of these
pain points to varying extents and is completely backwards compatible with
1.0.X code.

Also, I don't know if Erlang would have met their performance needs?
[http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...](http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=hipe)

~~~
Refefer
Erlang is faster than most people give it credit for. I imagine performance
might also have made their bullet points, coming from Ruby:
[http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...](http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=yarv&lang2=hipe)

------
zacharyvoase
One thing that worried me was the slide with just this text on it:

    
    
        Team selected Go in 15 minutes
    

Is that really long enough to make a decision? I'm not saying it was
necessarily the wrong decision. Just that 15 minutes isn't a whole lot of
time.

~~~
ams6110
And then they had to write their own interface to OpenSSL, their own logging
framework, their own ORM, their own HTTP server, and their own implementation
of map. That seems like a lot of "non-value-added" stuff to have to reinvent.

~~~
krobertson
(I work at Apcera)

We didn't write our own HTTP server, but rather a framework that sits on top
of it and makes it easier to use.

The logging library is quite unlike anything else we're aware of, and the
goals of it were language independent. The author of it is giving a talk about
the library and our experiences with Go at GlueCon next month.

The ORM is the one which is more a result of what we wanted not being
represented by existing libraries, and the community being still smaller
compared to Node.

However, with all those still considered, we've gained a lot of velocity with
Go, better concurrency without doing full async development, etc. Personally,
I've hated testing async code in the past with both Node and EM+Ruby.

~~~
drivebyacct2
Any chance you'll release the ORM?

------
zik
I'm using Go at my new startup. I've only been working with it for a couple of
weeks but I'm loving it so far. They just got so many things _right_ with this
language.

------
hyperpape
This is really a minor point, but lots of people seem to hate function level
scoping, including these guys. Having started out in languages with function
level scoping, and only later used block level scoping, the former strikes me
as the most ordinary thing in the world.

Am I missing some compelling advantage of block level scopes, or is it just a
matter of taste/familiarity?

~~~
codexon
If your functions get big, you will start getting naming collisions and bugs.

~~~
trhtrsh
That's a sign your functions are too big.

------
douglasisshiny
I'm curious why Java isn't customer neutral. Clojure (and Scala) both seem to
be more mature, and concurrency is a core part of clojure (with a rich
ecosystem and runtime in the JVM).

~~~
voidlogic
Many people, right or wrong, do not feel comfortable running the JVM for
patent, ideological and/or security reasons.

~~~
tptacek
Security reasons? What?

~~~
voidlogic
I have heard some security researchers are not pleased with Oracles security
fix response time.

Other people feel the JVM is highly targeted. Or has more security bugs than
it should. Or is too bloated for the limited services they use it for and
could be smaller and this present a smaller target. etc

I'm not saying these concerns are necessarily valid, but I have had customers
who had no JVM rules...

~~~
tptacek
You are confusing the Java applet sandbox with the JVM. Serverside JVM
applications don't try to safely execute arbitrary JVM opcodes from random
Internet hosts.

~~~
voidlogic
"You are confusing the Java applet sandbox with the JVM" I tried to be clear I
was expressing common views customers and people I have interacted with have
expressed, not my own. In the context of marketing, perception matters.

But I hope you are not saying the server side JVM has never has security
bugs..

------
petrohi
Looking at Choice Criteria slide one might ask: why not Erlang?

------
rurounijones
Enterprise ODM + logging etc. Any of that being open-sourceD?

~~~
krobertson
(I work at Apcera)

Soon™

------
afshinmeh
In the page 10 of presentation I saw "Callback Spaghetti" for NodeJs. I think
he means "Callback Hell".

There's several good approaches that helps you to manage and write better
JavaScript codes (even NodeJs) to prevent callback hell problem, it's not a
problem of NodeJs or JavaScript, it's you that should manage this situation.

~~~
reactor
|it's you that should manage this situation. With Go, you don't need to worry
about this.

------
ams6110
The prediction that go will become the predominant language in IaaS and PaaS
seems to be a stretch... python has a HUGE lead and is well entrenched.

------
kristianp
On slide 15, he says of Stacks : "I spent 3+ months designing this in C in the
90s".

Anyone know what that means? Is he talking about segmented stacks?

------
lnanek2
As a cloud platform startup, I'm kind of surprised they didn't just go with
NodeJS due to it's huge popularity advantage meaning they'd have many more
customers. Even investors are asking for it nowadays. If you are writing
internal software for your own company, OK, pick what you want. But if you are
building a cloud platform that will presumably have customers with their own
wants/needs/demands/codebases, I think they would have been better off with a
platform written in the same language and engineers steeped in the same
language as everyone wants right now.

~~~
voidlogic
I'm not familiar with their product, is their back-end choice going to limit
their customers?

I think that a lot of developers that didn't start with front-end work find
Javascript disgusting, maybe this team is in that group. When I worked at a
consulting firm (that used a lot of C#) and we talked about node.js when it
came out, everyone agreed they hated the idea of having to write more yucky JS
than they had too. I think node.js was high on hype for a while and is less
loved (esp outside of CA) than you might expect.

I've ported node.js apps to Go 1.0.1 and even back then the result was better
performing, used less memory, about the same LOC and IMHO much cleaner,
straight-forward and maintainable code.

~~~
cygwin98
_I think they a lot of developers that didn't start with front-end work find
Javascript disgusting, maybe this team is in that group._

I am not a Javascript fanboy, but the syntax of GoLang is not better either.

~~~
voidlogic
I disagree, Go is slightly more verbose, but it leads to very clear code that
is easily understood. Go code is beautiful.

Javascript's dynamic typing, extensive use of callbacks, its approach to OO,
inconsistent braces and semicolons, etc are all felt by a lot of people to be
messy.

For me lack of something like gofmt and a compile time errors also greatly
detract.

