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

121–130 of 207 posts

Re: Go best practices, six years in

#121

Post by jud_white »

krat0sprakhar wrote: post #2

> That advice still holds today: vendoring is still the solution to dependency management for binaries. This might be a stupid question, but can someone explain to me what this means? Thanks!

A point of clarification for anyone skimming the original article:

> Top Tip — Libraries should never vendor their dependencies.

Peter goes on to clarify:

> You can carve out an exception for yourself if your library has hermetically sealed its dependencies, so that none of them escape to the exported (public) API layer. No dependent types referenced in any exported functions, method signatures, structures—anything.

I think this is the way to go if you're writing a library which has its own dependencies. You get a repeatable build and free yourself to change which dependencies you rely on without impacting users of your package.

There are exceptions, such as if your dependency has an init which only makes sense to run once. Loggers come to mind, where the setup should be determined by the main package. The f.Logger point in the article is friendlier to users of your package than just using log.Printf, and frees you from having to vendor logrus, for example, if you want to support structured logging.

Re: Go best practices, six years in

#122

Post by BuckRogers »

takeda wrote: post #107
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…

Rust really aims to be replacement for C. It allows you to program in low level, but you have much more powerful type checking and keeps track of ownership which reduces number of errors that plagued C language. Yes go also claims to be C replacement, but probably the only similarity is its simplicity, but unlike C it is not as expressive.

I haven't used Rust extensively, more Go for sure. But it seems to me that Go was aiming for simplicity more than being a true innovation. It's basically a compiled Python with type annotations and unfortunately a GC to spoil it all.

Rust was aiming at innovating and advancing the PL space with meaning. I can't say looking back the time I invested with Go was well-spent.

Rust is probably worth the effort if you have the need for what it offers. It just requires more out of you than Go does.

Re: Go best practices, six years in

#123

Post by cyphar »

platz wrote: post #35
bboreham wrote: post #27

Earlier quoted context omitted.

Just to add: the name comes from the convention of storing all those dependencies in a subdirectory named "vendor".

Is vendoring strictly storing the source code, or can it include storing compiled libraries?

Go doesn't have support for using compiled libraries (although support is coming). It's always using the source code.

Re: Go best practices, six years in

#124

Post by cyphar »

dlsniper wrote: post #63
pred_ wrote: post #41

The site blocks Tor users; ugh.

Try a different exit node, the website uses Cloudflare so if you could access HN you should be able to access that one as well.

Tor creates new routes every X minutes (usually 15). It also uses a different route for every IP it routes to. So they'll always go through a different exit node.

Re: Go best practices, six years in

#125

Post by BuckRogers »

matthewmacleod wrote: post #111
ver4no wrote: post #28

Earlier quoted context omitted.

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…

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

Those reasons aren't really convincing to add another platform into the stack for me. I'd just continue using the many good-enough technologies to build those things on.

I was getting into Go some years ago and came to the same conclusion as you stated. It's good of course if its someone's favorite language to use, then it doesn't matter what it is and isn't great at. But in the end for me it didn't do enough, or do enough better than existing broad PLs that I already knew.

I think Go is still in need of a "killer usecase" to justify its usage for people like me. Rails was that for Ruby. Linux entrenchment and Django was that for Python (now numerics and scientific computing). Node for JS. That said, I'm a Go fan in theory as a "simple is better" type.

Re: Go best practices, six years in

#126

Post by jsmthrowaway »

dalyons wrote: post #113
jsmthrowaway wrote: post #43

Earlier quoted context omitted.

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…

It's not, actually, and I'm not sure why you think I'm talking past you. Your claim was that Ruby is comparable performance-wise to Go in your application, and you cited median latency to make that case. I pointed out that interpreted languages often have a long tail and that the long tail is more interesting and undermines the comparison. You replied that I am correct and, indeed, you do have a long tail but you wrote it off as "stuff that happens" regardless of language. I am replying that the "stuff that happens" is the interesting stuff that undermines the flawed comparison you attempted to make, and I disagree that all of it can be written off to language-independent concerns; if you investigate it further, you might find some of it comes from the choice of language itself.

I have not wandered off topic into irrelevancy nor talked past you. This is still addressing the point you attempted to make by citing median latency in defense of the performance characteristics of your chosen language, in order to assuage general hesitance to adopt Ruby over performance concerns. I think you'll find that your metrics do not support your data if you dig into that p99.

(I share that experience from handling tens of millions of users myself, which is all I can admit to publicly, so that request re: assumptions goes both ways.)

To recap: claim submitted with flawed supporting data, thread addressing why the supporting data is flawed. No talking past taking place.

Re: Go best practices, six years in

#127

Post by [deleted] »

BuckRogers wrote: post #122
takeda wrote: post #107

Earlier quoted context omitted.

Rust really aims to be replacement for C. It allows you to program in low level, but you have much more powerful type checking and keeps track of ownership which reduces number of errors that plagued C language. Yes go also claims to be C replacement, but probably the only similarity is its simplicity, but unlike C it is not as expressive.

I haven't used Rust extensively, more Go for sure. But it seems to me that Go was aiming for simplicity more than being a true innovation. It's basically a compiled Python with type annotations and unfortunately a GC to spoil it all. Rust was aiming at innovating and advancing the PL space with meaning. I can't say looking back the time I invested with Go was well-spent. Rust is probably worth the effort if you have…

[deleted]

Re: Go best practices, six years in

#128

Post by dalyons »

jsmthrowaway wrote: post #126
dalyons wrote: post #113

Earlier quoted context omitted.

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…

It's not, actually, and I'm not sure why you think I'm talking past you. Your claim was that Ruby is comparable performance-wise to Go in your application, and you cited median latency to make that case. I pointed out that interpreted languages often have a long tail and that the long tail is more interesting and undermines the comparison. You replied that I am correct and, indeed, you do have a long tail but you wro…

Never claimed ruby was as fast as go. Our go services run at about 5-15ms(excluding 95/99 etc), so they're def faster(they do a lot less too!). I'm just saying ruby (or other dynamic langs, i dont mind, I dont have a "chosen language") can make a decently fast product API, and thats all.

And of course we've investigated further... (this is anecdotal i know), but of all the degenerate 99th cases we've investigated/solved, I can only think of 2 or 3 that were lang related, rather than logic, db, n+1s, etc. If you're curious, those were: - degenerate GC behaviour in a specific circumstance - JSON serialization (specifically crossing the C/ruby boundary shiteloads of times to serialize an object) Sure these issues sucked, but we mitigate/sidestepped those issues for the most part.

It's all a trade off when you're trying to decide what to use for your project; right tool for the job etc. Im not evalganizing for or against anything.

Curious what would you propose instead to roughly compare speeds of a product API? (Keeping in mind my anec-data about nearly all of 99ths being a logic/db issue). Comparing 99ths (from my experience) would be more like comparing which codebase has more bugs, because thats how we treat degenerate cases.

Re: Go best practices, six years in

#129

Post by jsmthrowaway »

sacado2 wrote: post #74
gkya wrote: post #61

Earlier quoted context omitted.

How do you debug then? (I'm not a Go coder, tho I'm familiar a bit with it)

Oh, that's simple. We gophers don't make any mistake. Ever. It makes our lives easier.

This is wrong. The answer is obviously "Go is debugged in production with extensive logging," so I question whether you're actually a gopher.

Re: Go best practices, six years in

#130

Post by curun1r »

wtbob wrote: post #64
curun1r wrote: post #26

Earlier quoted context omitted.

> IMHO, that's just ugly, uglier than foo/foo or foo/foolib or foo/libfoo. > I also think that anything which has commands other than a single-command project which will always be a single-command project (there are fewer of these than one might think …) should put all commands, even a single one, in cmd/. It's this kind of inflexibility in the directory structure of ones repo that really turned me off of Go. It's su…

> For instance, there's a ton of Go repositories out there that are not go gettable because the author wanted to put source code under a src directory and hacked that together using make. Are there? If someone's that ignorant of the language, I don't think I'd want to run something written by him … > And good luck with organizing any repository that contains multiple languages where go is one of them...go's "code liv…

> Are there? If someone's that ignorant of the language, I don't think I'd want to run something written by him …

Yes, there are. I don't know any off the top of my head, but I see them all the time. So, just for fun, how about a little test:

Step 1: Google 'notable applications written in golang'

>> first result: http://www.infoworld.com/article/2843821/application-develop...

Step 2: Click through to github repos

>> Result 9/10 of them won't work with go get.

So, are Docker, Kubernetes and Etcd the kind of software you wouldn't want to run because their creators are too ignorant of the language?

Post reply on HN