5 ms·

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 s

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 14y 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 14y 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.
- krobertson 14y 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.
  - drivebyacct2 14y ago
    Any chance you'll release the ORM?
- voidlogic 14y 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.
  - tptacek 14y ago
    The Go developer he's citing is probably Adam Langley, who is responsible for a good chunk of pkg/crypto and is also Chrome's TLS security person. I started with Go some months back and ran into a compat issue with their SSL library almost immediately (it couldn't handle Firefox's goofy SSL compat dance in proxy mode). Assuming that any new crypto implementation was safe sounds like magical thinking to me.
    - voidlogic 14y ago
      I would agree that OpenSSL is safer than using Go crypto. But I haven't seen any compelling evidence that it is any less secure than other non-Open SSL solutions. Like anything else, find a bug, report it/fix it.
      - tptacek 14y ago
        That's because you're not looking for evidence. Just look at Langley's Twitter feed: Golang's SSL still has Lucky13 timing channels, and the RSA and elliptic/ECDSA code hasn't been assessed for side channels. I like Go, a lot, but I think you should hold off on recommending crypto libraries ("I wouldn't hesitate to use this library in production"); that's something you want to be sure about before you develop opinions.
        voidlogic 14y ago
        To be clear I said I thought the Go crypo was suitable for some production uses. The text you put it quotes was not anything I ever said. I would rather use OpenSSL for a banking app for example. Since Go is >= version 1.0 and the crypo libraries in the standard library and not in go/exp, etc Go is implicitly endorsing them for some production use. I found closed issues that might be the ones you mentioned. If you are aware of issues, you should file them: http://code.google.com/p/go/issues/list?can=2&q=crypto&colspec=ID+Status+Stars+Priority+Owner+Reporter+Summary&cells=tiles http://code.google.com/p/go/issues/list?can=2&q=crypto&#...
jemeshsu 14y ago
Probably just to hilight it's an easy decision, or one that is unanimously agreed by the team members.
krobertson 14y 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.
- think33 14y ago
  EG: You had nobody qualified to make such a decision, and consequently, nobody qualified to produce what you claim to be building. The only reason to talk about node is because it's "hot". Ruby is "hot" too. Erlang, boring, but it actually does what you're trying to do. Well, I guess if your business model is replicating OTP, then you need to choose a platform without OTP so your engineers have something to do, right?

ams6110 14y 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 14y 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.
krobertson 14y 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.
- drivebyacct2 14y ago
  Any chance you'll release the ORM?
voidlogic 14y 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.
- tptacek 14y ago
  The Go developer he's citing is probably Adam Langley, who is responsible for a good chunk of pkg/crypto and is also Chrome's TLS security person. I started with Go some months back and ran into a compat issue with their SSL library almost immediately (it couldn't handle Firefox's goofy SSL compat dance in proxy mode). Assuming that any new crypto implementation was safe sounds like magical thinking to me.
  - voidlogic 14y ago
    I would agree that OpenSSL is safer than using Go crypto. But I haven't seen any compelling evidence that it is any less secure than other non-Open SSL solutions. Like anything else, find a bug, report it/fix it.
    - tptacek 14y ago
      That's because you're not looking for evidence. Just look at Langley's Twitter feed: Golang's SSL still has Lucky13 timing channels, and the RSA and elliptic/ECDSA code hasn't been assessed for side channels. I like Go, a lot, but I think you should hold off on recommending crypto libraries ("I wouldn't hesitate to use this library in production"); that's something you want to be sure about before you develop opinions.
      - voidlogic 14y ago
        To be clear I said I thought the Go crypo was suitable for some production uses. The text you put it quotes was not anything I ever said. I would rather use OpenSSL for a banking app for example. Since Go is >= version 1.0 and the crypo libraries in the standard library and not in go/exp, etc Go is implicitly endorsing them for some production use. I found closed issues that might be the ones you mentioned. If you are aware of issues, you should file them: http://code.google.com/p/go/issues/list?can=2&q=crypto&colspec=ID+Status+Stars+Priority+Owner+Reporter+Summary&cells=tiles http://code.google.com/p/go/issues/list?can=2&q=crypto&#...

jemeshsu 14y ago

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

krobertson 14y 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.

think33 14y ago
EG: You had nobody qualified to make such a decision, and consequently, nobody qualified to produce what you claim to be building. The only reason to talk about node is because it's "hot". Ruby is "hot" too. Erlang, boring, but it actually does what you're trying to do. Well, I guess if your business model is replicating OTP, then you need to choose a platform without OTP so your engineers have something to do, right?