Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go best practices, six years in

peter.bourgon.org

Post reply on HN
Print view View original

111–120 of 207 posts

Re: Go best practices, six years in

#111

Post by matthewmacleod »

ver4no wrote: post #28
matthewmacleod wrote: post #20

Earlier quoted context omitted.

My experience says "don't use Go for building web applications". Compared to something like Ruby on Rails, the development story with Go is much less batteries-included. You'll find yourself gluing together lots of components, and they're not really that friendly. Plus, for any front-end code, you'll end up using Node or whatever anyway to build assets. It's big and messy and not a good match. Go does excel at two ki…

what would you use go for then?

Go is great for what is describe as "plumbing" - things like proxies, infrastructure tools or simple microservices. The simplicity is a great benefit in these cases.

I've also found it unexpectedly useful for some embedded applications. Deployin code to the raspberry pi is super simple and that makes it quite attractive - there are projects that provide for thing like i2c, GPIO and SPI, and combined with the built-in HTTP support its a pretty compelling platform.

Re: Go best practices, six years in

#112

Post by honua »

brightball wrote: post #78
nvarsj wrote: post #38

The 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…

At some point mid #3 I finally hit the "I think it's time to just learn Elixir for every situation where I don't need a portable binary..." So far, looking like a solid decision.

This is helpful to read because I've been debating between learning Elixir vs Go

Re: Go best practices, six years in

#113

Post by dalyons »

jsmthrowaway wrote: post #43
dalyons wrote: post #19

Earlier 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.

I 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.

Re: Go best practices, six years in

#114

Post by skj »

daurnimator wrote: post #97
askyourmother wrote: post #48

Earlier quoted context omitted.

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 als…

> The fact it does not have hipster dev approved status is also an added bonus Huh? In my experience Go is the most hipster dev language around at the moment.

The insight here is that the "hipster" devs are always the ones who have strong opinions that you do not share.

Re: Go best practices, six years in

#115

Post by MereInterest »

valarauca1 wrote: post #86
weberc2 wrote: post #62

Earlier quoted context omitted.

I don't know, I want to like Rust, but every time I pick it up I feel like I'm relearning C++. It's learning curve is steep, the sorts of applications I write benefit more from solid development velocity and a good concurrency story. I might be wrong, but I get the feeling that Rust really only shines where performance and meticulous control are paramount. I want to like it, but it feels ill-suited to the application…

>I feel like I'm relearning C++ Because you are. You likely wrote widly unsafe things which are perfectly legal in C++. Rust is really just enforcing RAII which C++14 already has, and you've likely avoided.

Wait, people avoid RAII? With how useful it is in every circumstance, I can't imagine C++ without it.

Re: Go best practices, six years in

#116

Post by MereInterest »

bbrazil wrote: post #84
MereInterest wrote: post #37

> Only func main has the right to decide the flags that will be available to the user. This one applies to every language. I was working with a python package that decided that, since `sys.argv` was available from anywhere, it should parse `sys.argv` to configure its own behavior. For a long time, their suggestion was to first parse `sys.argv` yourself, then to modify it before going into the library.

This defeats the purpose of a good flags library though. Where flags shine is when you've some obscure tunable deep in the dependency tree that you need to tweak (particularly in an emergency). Plumbing through potentially thousands of flags through to main is nonsensical in that scenario.

Which works great, until you want to modify that parameter on the fly, or adjust it based on the current load of the system. Then you're sink, because you had that tunable parameter read from some global state, instead of being set from its parent.

Re: Go best practices, six years in

#117

Post by QuercusMax »

twr wrote: post #102
ramchip wrote: post #94

Earlier quoted context omitted.

Wow, his second response is really demeaning. Or maybe it's just a shock to me after hanging out in really friendly communities (Elixir etc.) for a while...

Pike literally quoted a passage from the bible: https://en.wikipedia.org/wiki/1_Corinthians_13 I won't argue that it was in good taste.

If by "literally quoted", you mean paraphrased... Or is this just another case where literally doesn't mean literally?

Re: Go best practices, six years in

#118

Post by skj »

jsmthrowaway wrote: post #49
yxhuvud wrote: post #47

Earlier quoted context omitted.

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 t…

In statistician-land, the median is simply one way of averaging, as is the mean. Introducing (or at least using) the extra term takes care of some ambiguity.

Re: Go best practices, six years in

#119

Post by dig1 »

gtrubetskoy wrote: post #92
nvarsj wrote: post #38

The 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…

Java was: 1. Wow, this program runs on any platform! 2. Wow, no need to free memory! 3. Wow, threads and locks are so easy to do! Then many years later 4. Who really cares about cross-platform code if all I do is on Linux? 5. Why does this program require 4GB of ram? 6. Must I really download and install the JVM all the time, and what is it good for anyway? Go: 1. Wow, I can write stuff that previously could only be…

2. Yea, right. Obviously you haven't run enough Go binaries

Re: Go best practices, six years in

#120

Post by twr »

QuercusMax wrote: post #117
twr wrote: post #102

Earlier quoted context omitted.

Pike literally quoted a passage from the bible: https://en.wikipedia.org/wiki/1_Corinthians_13 I won't argue that it was in good taste.

If by "literally quoted", you mean paraphrased... Or is this just another case where literally doesn't mean literally?

No. Sorry. I should have linked to the NASB translation, which was the source of his (literal) quote.

https://www.biblegateway.com/passage/?search=1+Corinthians+1...

Post reply on HN