Official Go support
stripe.com
Official Go support
1–10 of 117 posts
Re: Official Go support
#2It'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.
Re: Official Go support
#3Interestingly, 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`[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...
Re: Official Go support
#4Interestingly, 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 `[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-…
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.
Re: Official Go support
#5What language/platform were you using that had "2-4x" lower throughput than the port to Go?
Re: Official Go support
#6What language/platform were you using that had "2-4x" lower throughput than the port to Go?
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.
Re: Official Go support
#7Interestingly, 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 `[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-…
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.
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.
Re: Official Go support
#8What language/platform were you using that had "2-4x" lower throughput than the port to Go?
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]
Re: Official Go support
#9Interestingly, 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 `[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-…
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.
I believe the issue is that new parameters wouldn't be accessible without a library update.
Re: Official Go support
#10Earlier quoted context omitted.
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]
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.