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

31–40 of 207 posts

Re: Go best practices, six years in

#31

Post by eternalban »

Thaxll wrote: post #7
dineshp2 wrote: post #6

Slightly 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?

Go is pretty good for anything backend related.

No, that is definitely not correct, unless your "anything" is merely that which is fully defined & composed at compile time.

(And yes, you can go the IPC route to introduce dynamism that you get out of the box from a VM based language. But here is the classic case of the Go [tail] wagging the architecture [dog]..)

[edit: correct tail endian]

Re: Go best practices, six years in

#32

Post by _0w8t »

sudhirj wrote: post #3
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!

To vendor a dependency is to store a copy of all the source code you're trying to use inside your project itself. That way, when you compile your project, you also compile the code it depends on. Updating code you depend on is a semi-manual process - you choose to copy the latest version of the code you depend on into your project again. This is contrast to stacks like Java, where I can give you a pre-compiled JAR fi…

I have found that using git-subrepo is a great help with vendoring as single

    git subrepo pull --all
is enough to update all dependencies.

Re: Go best practices, six years in

#33

Post by meddlepal »

themartorana wrote: post #29
sagichmal wrote: post #10

Earlier quoted context omitted.

In my experience most Go developers seem to favor a terminal-heavy workflow, sometimes frequently shutting down and re-opening their editors in new paths and projects. The barebones simplicity of Go-the-language seems to be a nice match to this workflow. It's a different thing altogether to how large IDEs like IntelliJ expect you to work: opening up a project and staying in the IDE for a long period of time. Both app…

Oh me too - my setup is usually split screen IntelliJ and iTerm2. But as projects grew larger, (and I wasn't a vim-er) a lot of the tools that come with a full fledged IDE became nice-to-haves (definition-on-hover as source code, click-to-definition, tree and object graph always open, and so on). I know my setup isn't for everyone, but if you're looking for a good Go IDE experience, especially if your projects are of…

As a Java developer that uses Intellij exclusively this is great news. Maybe I'll check out Go more. I really hate using languages without good IDE integration.

Re: Go best practices, six years in

#34

Post by sagichmal »

dllthomas wrote: post #30

"those parameters should be part of type constructors" I'm not sure if this is a nit, a misunderstanding on my part, or a difference in terminology, but I think what is meant here is "value constructors" (or more commonly, just "constructors"). As I understand the term, "type constructors" construct types .

Well, there are no type constructors in that sense in Go.

Re: Go best practices, six years in

#35

Post by platz »

bboreham wrote: post #27
bitwize wrote: post #5

Earlier quoted context omitted.

"Vendoring" means maintaining local copies of third-party libraries and other dependencies in your local repo so exactly what you depend on is a part of your internal history. Git provides ways of doing this easily, such as subtrees.

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?

Re: Go best practices, six years in

#36

Post by dllthomas »

sagichmal wrote: post #34
dllthomas wrote: post #30

"those parameters should be part of type constructors" I'm not sure if this is a nit, a misunderstanding on my part, or a difference in terminology, but I think what is meant here is "value constructors" (or more commonly, just "constructors"). As I understand the term, "type constructors" construct types .

Well, there are no type constructors in that sense in Go.

That was my understanding, but being new to Go I wanted to be sure (and be sure there wasn't some other specialized use in which "type constructor" meant something different than "constructor").

Re: Go best practices, six years in

#37

Post by MereInterest »

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

Re: Go best practices, six years in

#38

Post by nvarsj »

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 more", and "worse is better"!

3. (Many months later) Oh god, I'm getting so sick of writing this test assertion in 4 lines over and over, and writing 100s of lines of mock structs. My tests are 5% substance and 95% setup. Okay let's write a junit/mockito assertion library. Oh crap, I'm having to manually wire everything everywhere and it's such a pain. Let's write a DI library. Ugh my project is getting too big and `go get` just doesn't cut it - time to use a dependency management library. Ugh, makefiles only go so far, time to write a build tool. Ugh code generation and metacoding is nonexistent, let's write our own code generation tool so we don't have to hand build 100s of types. ETC.

4. (Distant future) As golang's stubborn designers finally accept some flaws in their original thinking, they add features to make the language look a lot like another widely used language at the Googplex. Mission accomplished?

P.S. This is somewhat tongue in cheek - I do enjoy using golang day to day. It is a refreshing change :).

Re: Go best practices, six years in

#39

Post by [deleted] »

yxhuvud wrote: post #22
jsmthrowaway wrote: post #15

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

[deleted]

Re: Go best practices, six years in

#40

Post by RyanZAG »

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…

It will get extremely meta when golang's infrastructure gets good enough for other languages to want to use. Then they'll split it out into a 'GoVM', or I guess 'GoRT', and then you'll have a 'GoVM' competing with the JVM...
Post reply on HN