12 ms·

Official Go support

189 points by gdb 12y ago

cnbuff410 12y ago
It's both interesting and suprising that how steady this exponential growth curve is. The increasing speed of Go usage on stripe doesn't slow down as time goes by. Of course without knowing the base we don't know how big usage it actually is, also we don't know if it's counting one-per-client or one-per-request. Still nice to see that nonetheless.
- darren2000 12y ago
  Right, just look at August! Although I wish there were numbers on that graph. Was there a conference talk? Glad to know there'll be lots of fellow devs using it anyway.
masklinn 12y ago
Interestingly, it looks like the Go library uses structs rather than `map[string]interface{}`, even though the Java library was recently criticised for its usage of `Map<String, Object>`[0], a decision defended by the developer[1] on grounds that "[they] add new parameters to the API frequently, so it's a tradeoff to avoid devs needing to update stripe-java every time." [0] http://movingfulcrum.tumblr.com/post/97624791473/critique-of-stripes-java-apis http://movingfulcrum.tumblr.com/post/97624791473/critique-of... [1] https://twitter.com/JimDanz/status/511730705387110400 https://twitter.com/JimDanz/status/511730705387110400
- ericwaller 12y ago
  Go's JSON parser ignores fields that aren't present in the destination type, so the addition of new parameters shouldn't be a problem.
  - masklinn 12y ago
    AFAIK GSON (which stripe-java users) also ignores fields which are not present in the destination type, but the original post was about parameters so that's not even relevant: deserialisation would only be relevant for responses.
  - rsanders 12y ago
    I believe the issue is that new parameters wouldn't be accessible without a library update.
    - djur 12y ago
      My sense is that the Go developer culture is a lot more open to frequently updating their dependencies than the Java developer culture. Fetching dependencies from git is built into Go, after all.
- cosn 12y ago
  (Stripe's Go library dev here) There's a tradeoff space here, as that tweet indicates. Doing things generically makes the library less idiomatic, but means developers don't need to churn their library dependency as often. Go's a different language from Java, and it's less common to have to deal with casting, etc. As that tweet conversation indicates (particularly https://twitter.com/JimDanz/status/511732603884294145 https://twitter.com/JimDanz/status/511732603884294145), we're also considering changing the Java library implementation in the future.
- mrweasel 12y ago
  Honestly parsing json as map[string]interface{}, rather than using a struct is a major pain in the butt. I'm currently doing a project that takes json, with no predefined structure, or at least very varying struct and transforms it. Dealing with checking for keys and doing type conversion it's that much fun. The same project need to parse an XML file, with a clear and defined structure, it took something like five minutes and work on my first try. I don't think you would need to update the Go library in the case of just adding new parameters, not if the parameter can be excluded. The json parser should just skip that value, it won't be available to you of cause, but it should break the parser. Given that I haven't touched Java in 10 years I don't know how Java deals with unexpected parameters.
  - nkozyra 12y ago
    Isn't this generally done anytime you don't know the structure of the json document that will be unmarshalled? If a new field is added and you're parsing to a struct that struct will have to be changed to accommodate that field, rather than letting it happen anonymously as through an interface.
seansh 12y ago
What language/platform were you using that had "2-4x" lower throughput than the port to Go?
- gdb 12y ago
  That was porting from Ruby. Go is particularly good for any application where you want to get better utilization out of your CPU, or want to cut down on memory usage. Most of the code we've been porting has been infrastructure: parsers, reverse proxies, and the like. We're still getting a feel for what it's like writing complex application logic in Go, but what we've seen so far has been promising.
  - deleted 12y ago
    [deleted]
    - gdb 12y ago
      Well if you're not particularly CPU- or memory-bound, you probably won't want to spend your time optimizing them. As well, there are plenty of softer aspects you might care to optimize: productivity, maintainability, library support, etc.. There's unfortunately never a free lunch with software engineering.
fizixer 12y ago
Can someone explain? I'm a big fan of C and python and I've never used Go. My initial impressions from readings were that Go is a better C. But then I came across a Go person who was lamenting that misunderstanding and that Go is python but with better performance. What's it all about? Also even if we compare it to C I don't like the garbage-collection thing at system level. Also what does Go let you do in terms of garbage collection that cannot be done with a C gc library (which anyone can use if they want but then also have the choice to do raw/manual memory management if they want too).
- schmichael 12y ago
  The comparison to C has always struck me as strange. It has curly braces and pointers, but few semicolons, no pointer arithmetic, garbage collection, and tons of high level language primitives (maps, slices, channels, select, goroutines, a userland scheduler). Many people, myself included, find it a wonderful language suitable for all sorts of service development whether it's data processing systems or web APIs.
  - bkeroack 12y ago
    I love Go and I consider it to be the spiritual successor to C, in a way (sort of an anti-C++, which the creators have said they used as an explicit example of what not to do). Given that it was co-created by Ken Thompson (of Unix/C/Plan9 fame), I think the comparison is justified.
  - jimmysawczuk 12y ago
    Another similarity is that both Go and C compile to dependency-free and portable binaries with no VM needed to run them. In my mind, that's the biggest similarity. And regarding semicolons: you don't use them as much while coding, but the lexer puts them in for you, so they're there on some level.
  - nkozyra 12y ago
    I think the general idea is C++ (not C) in the style of Python. You still have access to memory/pointers/unsafe, it shares a C-style syntax (go ahead, put in the semicolons if you want!), is compiled but offers the gentle, elegant watchfulness of a Python-like scripting language. In most cases it can be a relatively drop-in replacement for C++ or Python as a binary. It will never be like C in that there's a lot of overhead and lack of memory control for embedded systems, so you probably can't treat it as a C competitor in any way.
jrobn 12y ago
Official lua support would be peachy.
- cosn 12y ago
  (Stripe dev here) You're probably already aware of this, but there are 3rd party[0] libraries, including one for Lua[1] [0]: https://stripe.com/docs/libraries#third-party https://stripe.com/docs/libraries#third-party [1]: https://github.com/wsummerlin/stripe-lua https://github.com/wsummerlin/stripe-lua
- rurounijones 12y ago
  Out of curiosity: Where would this be used? The only places I ever hear the word "lua" being used are with "embedded in a game as a scripting language". Is this the case here? Does lua have a lot of use elsewhere?
  - jrobn 12y ago
    Lua is compiled into OpenResty (NGINX). There is also a nice webframework called Lapis thats built on top of openresty and lua.
    - rurounijones 12y ago
      Thank you for the information!
deleted 12y ago
[deleted]
pavanky 12y ago
Guys slightly off topic, but please do keep the colorblind people in mind. The colors used for the graphs are so similar that I can not differentiate them.
- fossuser 12y ago
  Interesting - I thought it'd be red/green, but it's blue/purple (which I thought were colors chosen for the color blind). Is blue/purple color blind less common? Can you differentiate between red/green?
  - Sanddancer 12y ago
    If you're red-deficient, then purple/blue is also a bad choice for colors because you can't see the red components of purple.
    - pkulak 12y ago
      Blue and purple are the same color as far as I can tell.
  - DigitalJack 12y ago
    Red/blue would be safer colors to differentiate for many colorblind people. Red/green colorblindness is so common it baffles me that comparisons using red/green are still so prevalent. Especially considering how heavily biased the tech population is toward men. And as Sanddancer points out, any colors that make use of red/green are going to be problems as well. (hence blue/purple being an issue as the difference is the red component). In a given group of 5 men, you have a 50% chance that 1 is red/green color deficient.
    - Swizec 12y ago
      > In a given group of 5 men, you have a 50% chance that 1 is red/green color deficient. Soooo, 1 in 10 men are red/green colour deficient?
pavanky 12y ago
Guys slightly off topic, but please do keep the colorblind people in mind. The colors used for the graphs are so similar that I can not differentiate them.
deleted 12y ago
[deleted]
linguafranca 12y ago
I'm a bit baffled by Go. The majority of developers I know (across several camps) strongly oppose Go, often to the point of ridiculing it. But then I see Go support being added to everything, usually by a few key people who strongly prefer it. In fact I hear Heroku is internally adopting Go pretty rapidly. So every time I see an announcement like this, I look up whether Go has added some kind of generics yet. And as usual, they haven't. But to me, the worst part of this is that the whole community has Stockholm syndrome, being perfectly content to instantly defend every position the Go team makes, no matter what.
- jvehent 12y ago
  So I'm gonna make a wild guess here and assume you haven't written in Go. If you had, you'd probably find it fun and convenient. Not revolutionary, just fun and convenient. That's enough for me to like it better than python or ruby or perl.
- shadowmint 12y ago
  I'm not the greatest fan of Go; the pain points of api weirdness and generics are too irritating for me. ...but you've got to admit: look at the graph. That's an exponential increase in people using go to access the service. If you're a service based company you can't just ignore the people who use your service. If people are using go? Provide a go library. If you see an exponential curve of people accessing it using lua, write a lua library. It's pretty obviously the right thing for them to do.
  - general_failure 12y ago
    The graph has no numbers.
    - NateDad 12y ago
      Developers & managers at Stripe decided that Go was being used often enough to spend precious dev time writing an official library which will have to be supported from here on. They wouldn't do that if the numbers didn't justify it.

189 points by gdb 12y ago

It's both interesting and suprising that how steady this exponential growth curve is. The increasing speed of Go usage on stripe doesn't slow down as time goes by. Of course without knowing the base we don't know how big usage it actually is, also we don't know if it's counting one-per-client or one-per-request. Still nice to see that nonetheless.

darren2000 12y ago
Right, just look at August! Although I wish there were numbers on that graph. Was there a conference talk? Glad to know there'll be lots of fellow devs using it anyway.

masklinn 12y ago

Interestingly, it looks like the Go library uses structs rather than `map[string]interface{}`, even though the Java library was recently criticised for its usage of `Map<String, Object>`[0], a decision defended by the developer[1] on grounds that "[they] add new parameters to the API frequently, so it's a tradeoff to avoid devs needing to update stripe-java every time." [0] http://movingfulcrum.tumblr.com/post/97624791473/critique-of-stripes-java-apis http://movingfulcrum.tumblr.com/post/97624791473/critique-of... [1] https://twitter.com/JimDanz/status/511730705387110400 https://twitter.com/JimDanz/status/511730705387110400

ericwaller 12y ago
Go's JSON parser ignores fields that aren't present in the destination type, so the addition of new parameters shouldn't be a problem.
- masklinn 12y ago
  AFAIK GSON (which stripe-java users) also ignores fields which are not present in the destination type, but the original post was about parameters so that's not even relevant: deserialisation would only be relevant for responses.
- rsanders 12y ago
  I believe the issue is that new parameters wouldn't be accessible without a library update.
  - djur 12y ago
    My sense is that the Go developer culture is a lot more open to frequently updating their dependencies than the Java developer culture. Fetching dependencies from git is built into Go, after all.
cosn 12y ago
(Stripe's Go library dev here) There's a tradeoff space here, as that tweet indicates. Doing things generically makes the library less idiomatic, but means developers don't need to churn their library dependency as often. Go's a different language from Java, and it's less common to have to deal with casting, etc. As that tweet conversation indicates (particularly https://twitter.com/JimDanz/status/511732603884294145 https://twitter.com/JimDanz/status/511732603884294145), we're also considering changing the Java library implementation in the future.
mrweasel 12y ago
Honestly parsing json as map[string]interface{}, rather than using a struct is a major pain in the butt. I'm currently doing a project that takes json, with no predefined structure, or at least very varying struct and transforms it. Dealing with checking for keys and doing type conversion it's that much fun. The same project need to parse an XML file, with a clear and defined structure, it took something like five minutes and work on my first try. I don't think you would need to update the Go library in the case of just adding new parameters, not if the parameter can be excluded. The json parser should just skip that value, it won't be available to you of cause, but it should break the parser. Given that I haven't touched Java in 10 years I don't know how Java deals with unexpected parameters.
- nkozyra 12y ago
  Isn't this generally done anytime you don't know the structure of the json document that will be unmarshalled? If a new field is added and you're parsing to a struct that struct will have to be changed to accommodate that field, rather than letting it happen anonymously as through an interface.

seansh 12y ago

What language/platform were you using that had "2-4x" lower throughput than the port to Go?

gdb 12y ago
That was porting from Ruby. Go is particularly good for any application where you want to get better utilization out of your CPU, or want to cut down on memory usage. Most of the code we've been porting has been infrastructure: parsers, reverse proxies, and the like. We're still getting a feel for what it's like writing complex application logic in Go, but what we've seen so far has been promising.
- deleted 12y ago
  [deleted]
  - gdb 12y ago
    Well if you're not particularly CPU- or memory-bound, you probably won't want to spend your time optimizing them. As well, there are plenty of softer aspects you might care to optimize: productivity, maintainability, library support, etc.. There's unfortunately never a free lunch with software engineering.

fizixer 12y ago

Can someone explain? I'm a big fan of C and python and I've never used Go. My initial impressions from readings were that Go is a better C. But then I came across a Go person who was lamenting that misunderstanding and that Go is python but with better performance. What's it all about? Also even if we compare it to C I don't like the garbage-collection thing at system level. Also what does Go let you do in terms of garbage collection that cannot be done with a C gc library (which anyone can use if they want but then also have the choice to do raw/manual memory management if they want too).

schmichael 12y ago
The comparison to C has always struck me as strange. It has curly braces and pointers, but few semicolons, no pointer arithmetic, garbage collection, and tons of high level language primitives (maps, slices, channels, select, goroutines, a userland scheduler). Many people, myself included, find it a wonderful language suitable for all sorts of service development whether it's data processing systems or web APIs.
- bkeroack 12y ago
  I love Go and I consider it to be the spiritual successor to C, in a way (sort of an anti-C++, which the creators have said they used as an explicit example of what not to do). Given that it was co-created by Ken Thompson (of Unix/C/Plan9 fame), I think the comparison is justified.
- jimmysawczuk 12y ago
  Another similarity is that both Go and C compile to dependency-free and portable binaries with no VM needed to run them. In my mind, that's the biggest similarity. And regarding semicolons: you don't use them as much while coding, but the lexer puts them in for you, so they're there on some level.
- nkozyra 12y ago
  I think the general idea is C++ (not C) in the style of Python. You still have access to memory/pointers/unsafe, it shares a C-style syntax (go ahead, put in the semicolons if you want!), is compiled but offers the gentle, elegant watchfulness of a Python-like scripting language. In most cases it can be a relatively drop-in replacement for C++ or Python as a binary. It will never be like C in that there's a lot of overhead and lack of memory control for embedded systems, so you probably can't treat it as a C competitor in any way.

jrobn 12y ago

Official lua support would be peachy.

cosn 12y ago
(Stripe dev here) You're probably already aware of this, but there are 3rd party[0] libraries, including one for Lua[1] [0]: https://stripe.com/docs/libraries#third-party https://stripe.com/docs/libraries#third-party [1]: https://github.com/wsummerlin/stripe-lua https://github.com/wsummerlin/stripe-lua
rurounijones 12y ago
Out of curiosity: Where would this be used? The only places I ever hear the word "lua" being used are with "embedded in a game as a scripting language". Is this the case here? Does lua have a lot of use elsewhere?
- jrobn 12y ago
  Lua is compiled into OpenResty (NGINX). There is also a nice webframework called Lapis thats built on top of openresty and lua.
  - rurounijones 12y ago
    Thank you for the information!

deleted 12y ago

[deleted]

pavanky 12y ago

Guys slightly off topic, but please do keep the colorblind people in mind. The colors used for the graphs are so similar that I can not differentiate them.

fossuser 12y ago
Interesting - I thought it'd be red/green, but it's blue/purple (which I thought were colors chosen for the color blind). Is blue/purple color blind less common? Can you differentiate between red/green?
- Sanddancer 12y ago
  If you're red-deficient, then purple/blue is also a bad choice for colors because you can't see the red components of purple.
  - pkulak 12y ago
    Blue and purple are the same color as far as I can tell.
- DigitalJack 12y ago
  Red/blue would be safer colors to differentiate for many colorblind people. Red/green colorblindness is so common it baffles me that comparisons using red/green are still so prevalent. Especially considering how heavily biased the tech population is toward men. And as Sanddancer points out, any colors that make use of red/green are going to be problems as well. (hence blue/purple being an issue as the difference is the red component). In a given group of 5 men, you have a 50% chance that 1 is red/green color deficient.
  - Swizec 12y ago
    > In a given group of 5 men, you have a 50% chance that 1 is red/green color deficient. Soooo, 1 in 10 men are red/green colour deficient?

pavanky 12y ago

Guys slightly off topic, but please do keep the colorblind people in mind. The colors used for the graphs are so similar that I can not differentiate them.

deleted 12y ago

[deleted]

linguafranca 12y ago

I'm a bit baffled by Go. The majority of developers I know (across several camps) strongly oppose Go, often to the point of ridiculing it. But then I see Go support being added to everything, usually by a few key people who strongly prefer it. In fact I hear Heroku is internally adopting Go pretty rapidly. So every time I see an announcement like this, I look up whether Go has added some kind of generics yet. And as usual, they haven't. But to me, the worst part of this is that the whole community has Stockholm syndrome, being perfectly content to instantly defend every position the Go team makes, no matter what.

jvehent 12y ago
So I'm gonna make a wild guess here and assume you haven't written in Go. If you had, you'd probably find it fun and convenient. Not revolutionary, just fun and convenient. That's enough for me to like it better than python or ruby or perl.
shadowmint 12y ago
I'm not the greatest fan of Go; the pain points of api weirdness and generics are too irritating for me. ...but you've got to admit: look at the graph. That's an exponential increase in people using go to access the service. If you're a service based company you can't just ignore the people who use your service. If people are using go? Provide a go library. If you see an exponential curve of people accessing it using lua, write a lua library. It's pretty obviously the right thing for them to do.
- general_failure 12y ago
  The graph has no numbers.
  - NateDad 12y ago
    Developers & managers at Stripe decided that Go was being used often enough to spend precious dev time writing an official library which will have to be supported from here on. They wouldn't do that if the numbers didn't justify it.