5 ms·
I've done a lot of ruby and go. Honestly, I would think twice before building a major website/product API on go. Development time is markedly slower in go, som
by dalyons 11y ago
I've done a lot of ruby and go.
Honestly, I would think twice before building a major website/product API on go.
Development time is markedly slower in go, some causes off the top of my head:
- testing is way harder (ruby has some amazing mocking/stubbing/testing tooling).
- debugging is way harder. Hope you like printf.
- Json; the strict typing & struct searialization rules make dealing with Json a pain in the arse, and heavy on boilerplate
- interfacing with Sql (if you have to do a lot of it) is a pain in the arse, for similar reasons to json.
- having no stack for errors is insanely frustrating.
- templating in go is primitive
Go is amazing for services. The parallelisation primitives are fantastic, and allow you to do things that would be hard/impossible in ruby/Python.
Go is undeniably much faster, execution wise. (Although our super high volume ruby product api is at 50ms median so, it matters less than you think)
Decide what you care about most; if your prime goal is to get a product in front of customers as soon as possible, I'd pick a higher level language.
If you want to make a rock solid service that sips on resources & scales to the moon, use go.
- jsmthrowaway 11y agoMedian latency is a completely useless number. There is literally no use for it, ever. Satan invented median latency to confuse people, because it lies to you and whispers sweet nothings in your ear. Averaging latencies in your monitoring leaves the outliers out in the cold because you will never see them, and tail latency is way more important for user experience. Quantile your latency. I suspect you'll find 99th tells an interesting story between Ruby vs. Go. The best latency graph has five or six lines at different percentiles (yes, including 50) stacked in a latency sandwich. I'm willing to bet your app has a rough 99th. Maybe even a rough 95th. Nothing against Rails (honest, this applies to most interpreters), but most scripted stuff has a pretty rough latency tail, and you ignore that with median. (Go is not off the hook either; GC pauses can blow out high percentiles if you're memory-heavy.) I'm pretty passionate about this, sorry. I'm on a mission from God to purge our mortal plane of average/median latency, because it's one of those misapplications of statistics that everybody does without a second thought. Don't even collect it. Average latency is unimportant and misleads people, and misleads people more as you get more popular. It's that 1% of clients sitting there for 2sec that impacts perception of your UX.
- stock_toaster 11y agoYour cause is just. Keep fighting the good fight!
- dalyons 11y agoSure, and I thought twice before putting that in :) We of course monitor our 95th & 99th primarily, for reasons that you said. But I didn't quote those because they're usually blown out by slow db queries, n+1 selects,n+1 cache gets, etc, issues that happen regardless of language. often they're on rarely used end points, where the cost-benefit of optimising isn't worth it. I feel median gives a resonable proxy for the language/framework execution capabilities.
- jsmthrowaway 11y agoThat response actually illustrates my point, oddly enough; median has comforted you to organizationally disregard the super interesting data you're getting from the percentile aggregations. Those blowouts are far more interesting than you're saying, I wager. p99 blowout is generally an operational smell, even on low-RPS endpoints.
- bumbledraven 11y agoGrandparent's point is that 99th percentile latency is, for their application, unrelated to the ruby-vs-Go comparison.
- dalyons 11y agoI think we might be talking past each other a little :) The median has absolutely not "comforted" us, nor do we disregard the percentile data. In fact, we have a whole perf team basically dedicated to looking at 95/9th & other slow transaction trace data, and fixing these. In big projects, serving 10's of millions of users, with a handful of devs, you've gotta pick your battles, you cant fix everything always. We do our best, just like anyone else. So obviously we agree with the importance of percentiles. Dont make assumptions :) And all of this is rather irrelevant to the main point now, which is overall _language_ speed.
- gkya 11y ago> - debugging is way harder. Hope you like printf. Can't you use gdb with Go? https://golang.org/doc/gdb https://golang.org/doc/gdb
- spriggan3 11y agoThe second you launch a Go routine, gdb becomes useless.
- gkya 11y agoHow do you debug then? (I'm not a Go coder, tho I'm familiar a bit with it)
- shurcooL 11y agoSee another answer in this thread, https://news.ycombinator.com/item?id=11607829 https://news.ycombinator.com/item?id=11607829.
- sacado2 11y agoOh, that's simple. We gophers don't make any mistake. Ever. It makes our lives easier.
- jsmthrowaway 11y agoThis is wrong. The answer is obviously "Go is debugged in production with extensive logging," so I question whether you're actually a gopher.
- pstuart 11y ago> debugging is way harder. Hope you like printf. You have other options: https://github.com/derekparker/delve https://github.com/derekparker/delve
- jud_white 11y ago> having no stack for errors is insanely frustrating. Check out https://github.com/pkg/errors https://github.com/pkg/errors If you want more rich control of the output of the stack trace there's https://github.com/go-stack/stack https://github.com/go-stack/stack
- dalyons 11y agoYeah, we've started using that. Kind of amazing that you need an addon lib & Wrap() everywhere to make errors useful. Just more boilerplate! :)