The Selection of Go at Apcera

http://www.slideshare.net/derekcollison/go-conference-japan

by timf • 13 years ago

54 49 13 years ago

slideshare.net

rurounijones• 13 years ago

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

krobertson3• 13 years ago

(I work at Apcera)

Soon™

zik• 13 years ago

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.

zacharyvoase• 13 years ago

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.

ams61102• 13 years ago

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.

lbarrow• 13 years ago

Our experience with Go at Braintree was similar. While the language is great, you still have to reinvent the wheel sometimes. For some companies this might make sense if they get a ton of value out of the language. We ultimately decided we could use Ruby for our purposes, so we switched.

krobertson3• 13 years ago

(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.

voidlogic10• 13 years ago

I think the OpenSSL binding are really only necessary if you follow the train of though that, "its new so it must be broken". I prefer tests and evidence and I would not hesitate to use the Go cypto in many production scenarios. To distrust something with no evidence of being broken seems like magical thinking to me.

Go 1.1 includes a better map implementation, so if they were starting now that probably would not have been needed.

Most large systems always end up performing some customization to standard logging solutions as well.

jemeshsu• 13 years ago

Probably just to hilight it's an easy decision, or one that is unanimously agreed by the team members.

krobertson3• 13 years ago

(I work at Apcera)

The "15 minutes" part was hyperbole.

The timeframe referenced the length of the discussion of the two, not the knowledge the decision was based on. Several of us had previous experience with Node, and some of the team had prior Go experience.

jallmann• 13 years ago

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...

voidlogic10• 13 years ago

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...

Refefer• 13 years ago

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...

burntsushi• 13 years ago

Your analysis omits the fact that Erlang and Haskell are mostly functional languages, which is different enough from what most programmers are comfortable with. This is typically a very large barrier to overcome.

ams61102• 13 years ago

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.

hyperpape• 13 years ago

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• 13 years ago

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

trhtrsh2• 13 years ago

That's a sign your functions are too big.

trhtrsh2• 13 years ago

It's deeply aesthetically offensive, for one. It's error-prone, for two:

    if False: 
      p = 1
    print p

No, thank you.

reissbaker• 13 years ago

That's not how function-level scoping works in Javascript.

    function p() {
      if(false) var p = 10;
      return p;
    }
    p(); // evaluates to undefined

What you'd get in a block-scoped language is some sort of ReferenceError; you still don't get 10 in JS, though. The variable is accessible outside of the block, but the block itself isn't executed. The above is just equivalent to the following transformation:

    function p() {
      var p;
      if(false) p = 10;
      return p;
    }
    p();

Aesthetic offense is a matter of taste. I prefer Scheme over C for aesthetic beauty, but many prefer the opposite.

douglasisshiny2• 13 years ago

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).

voidlogic10• 13 years ago

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

douglasisshiny2• 13 years ago

I see. I was not aware that this was the case. Thank you.

tptacek4• 13 years ago

Security reasons? What?

lnanek2• 13 years ago

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.

thirsteh• 13 years ago

Reading this at the top of the comments made me really sad.

voidlogic10• 13 years ago

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• 13 years ago

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.

shurcooL• 13 years ago

  "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.

voidlogic10• 13 years ago

Agreed. If Google stopped working on Go, it would live on.

weareconvo• 13 years ago

Go is not some side-project started by a mid-level engineer. This is Rob Pike and Ken Thompson we're talking about. They're demi-gods, even at Google.

zura• 13 years ago

This is actually a pretty weak point for the language - that it is tied with personalities (no matter how great they are).

For instance, a contrary example would be - as a C++ engineer, I'm more than happy and think that it is one of the strongest point of C++ that it is not tied with Bjarne nor with any other company/personality.

continuations• 13 years ago

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• 13 years ago

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

jesstaa• 13 years ago

Unladen swallow fizzled out because it was tackling a problem that was theoretically difficult and they weren't having much luck with it.

petrohi• 13 years ago

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

afshinmeh• 13 years ago

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• 13 years ago

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

kristianp• 13 years ago

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?

The Selection of Go at Apcera

Related Stories