The site blocks Tor users; ugh.
Go best practices, six years in
41–50 of 207 posts
Re: Go best practices, six years in
#42Earlier quoted context omitted.
Median 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 te…
> Median 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. Umm, you do not get the median latency by averagin…
I think if you reread my comment you'll find that what you're saying does not actually disagree and is a restating of what I said.
Re: Go best practices, six years in
#43Earlier quoted context omitted.
Median 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 te…
Sure, 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 th…
That 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.
Re: Go best practices, six years in
#44The article sort of glosses over IntelliJ with the golang plugin as an "other" IDE, but it's best in class hands down. At one point in my past I had sworn off of Java-based IDEs, and used Sublime Text for years with primarily Python and Go. Something convinced me to try Go in IntelliJ, and really it's fantastic. It also covers "important-to-me" features the author mentions. I haven't tried VSCode yet, but have tried…
I second this. I've given Gosublime (and more recently VSCode) a solid try on several occassions. Neither hold a candle to the Intellij Go plugin. Being able to give solid rename refactor, and code navigation, even when your code is in a partial spaghetti, non-compiling-mid-development state is hard. And the Intellij plugin does a decent job at it. Not quite Java-level good. But pretty darn good.
The existing command line Go tooling (while great) just don't do a good job at providing that kind of support to your IDE.
Re: Go best practices, six years in
#45Slightly tangential, but, could someone share their experience using Go specifically for building websites? How does Go (including Go frameworks specifically geared towards web development) compare in terms of performance, ease of development with RoR, Laravel? Is building websites using Go a good use case or is Go better suited for building high performance microservices?
RoR is an awesome framework that has (almost) everything you need to build monolithic web apps.
Go is a different story. You need to join the pieces together to make something functional. You will probably need:
- A router like [Gin](https://github.com/gin-gonic/gin)
- A [XSRF token generator and validator](https://github.com/golang/net/blob/master/xsrftoken/xsrf.go)
- An ORM like [Gorm](https://github.com/jinzhu/gorm) or [XORM](https://github.com/go-xorm/xorm)
- A template lib like the one that comes with the stdlib
- Node for front-end (ugh, this is the harder part)
- The testing library in stdlib plus maybe [testify](https://github.com/stretchr/testify)
- etc...
Many nice things are missing. Some were [shamelessy copied by other people](https://github.com/go-testfixtures/testfixtures). Some you may need to implement yourself.
The big advantages is that Go has much better performance, and run on Windows, etc.
Re: Go best practices, six years in
#46Earlier quoted context omitted.
Sure, 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 th…
That 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.
Grandparent's point is that 99th percentile latency is, for their application, unrelated to the ruby-vs-Go comparison.
Re: Go best practices, six years in
#47Earlier quoted context omitted.
> Median 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. Umm, you do not get the median latency by averagin…
I think if you reread my comment you'll find that what you're saying does not actually disagree and is a restating of what I said.
It is not. Your comment confuses the median with the mean latency. The comment you replied to did not mention using averages - it mentioned only using the median. You introduced scathing critique of using averages when those are only used for means and therefore totally irrelevant here (even if I totally agree that people that use them should be educated. But that wasn't the case here).
Re: Go best practices, six years in
#48The stages of go enlightenment: 1. Holy crap, this is like coding in early Java days, what the heck were the language designers smoking?! They just ignored everything! Where's my testing framework! DI?! Build system, dependency management?! WTF. 2. Holy crap, this is like coding in the early Java days! This is awesome! I can understand all golang code I read! Everything is so simple and easy. I finally get "less is m…
Appreciate it was written as tongue in cheek, but I am glad that today a developer can start with Go, test, write code, build, deploy all with Go, whereas nearly every other ecosystem requires additional tools, often external competing tools. Then life becomes about having to learn whole new toolbekt before even coding.
Go still keeps it lean, and is great.
The fact it does not have hipster dev approved status is also an added bonus. The minute we see a bloated testing suite with yet another DSL, for Go, we are in trouble.
Re: Go best practices, six years in
#49Earlier quoted context omitted.
I think if you reread my comment you'll find that what you're saying does not actually disagree and is a restating of what I said.
It is not. Your comment confuses the median with the mean latency. The comment you replied to did not mention using averages - it mentioned only using the median. You introduced scathing critique of using averages when those are only used for means and therefore totally irrelevant here (even if I totally agree that people that use them should be educated. But that wasn't the case here).
I actually don't, and you're reacting to the use of "averaging" as a verb. That's why I encouraged you to reread. When you're discarding 50% of the samples in a 50th percentile median, I think "averaging" is an acceptable verb to proxy the situation in English since "medianing" isn't a word. I could have said "computing the median," but that's just tedious.
Notice later in the comment I say average/median, implying that they are separate but related concepts. I think it's safe to assume that someone who can conversationally use the word "quantile" is not confusing median with mean. You're assuming that my (intentional) selection of a lower-fidelity term to describe a concept, which I carefully illustrated with ancillary points to give specificity to said concept, demonstrates a misunderstanding of the very field I'm explaining. That is pretty obviously wrong and a bit condescending.
We agree, which is what's frustrating. You're just latching on to a pedantic correction of my point, and rather than belabor that correction I encouraged you to reread to see that we do actually agree. Now, I do see average latency far more often than I'd care to admit, which is why I got lazy and just said "average" at the end there once I started referring to generality instead of specificity, but I think it's pretty clear that I understand the distinction regardless.
Re: Go best practices, six years in
#50Slightly tangential, but, could someone share their experience using Go specifically for building websites? How does Go (including Go frameworks specifically geared towards web development) compare in terms of performance, ease of development with RoR, Laravel? Is building websites using Go a good use case or is Go better suited for building high performance microservices?
The other answers provided plenty of info on Go, so if you're looking for a new language and framework for web dev I suggest checking out elixir and Phoenix. They're inspired by ruby/rails (without some of the problems) and have many of the benefits of erlang.