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

71–80 of 207 posts

Re: Go best practices, six years in

#71

Post by asimuvPR »

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.

My experience over the years is that Go serves a specific niche ver well. The niche being boring long running services that do simple tasks in unison with other services. It's better to see it as a language wi th which you can build little self contained machines that work well together. I have a system made up of such little machines and it quietly works away at some low end server.

Re: Go best practices, six years in

#72

Post by shurcooL »

gkya wrote: post #61
spriggan3 wrote: post #54

Earlier quoted context omitted.

The second you launch a Go routine, gdb becomes useless.

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

See another answer in this thread, https://news.ycombinator.com/item?id=11607829.

Re: Go best practices, six years in

#73

Post by ntonozzi »

weberc2 wrote: post #62
MichaelGG wrote: post #58

Earlier quoted context omitted.

Rust has that built in, but managed to be a much more solid language (feature wise).

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 don't think there's anything wrong with that. Rust is designed for a specific market, and it sounds like you aren't part of it.

Re: Go best practices, six years in

#74

Post by sacado2 »

gkya wrote: post #61
spriggan3 wrote: post #54

Earlier quoted context omitted.

The second you launch a Go routine, gdb becomes useless.

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.

Re: Go best practices, six years in

#75

Post by nvarsj »

zzzcpan wrote: post #69
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…

Well, hundreds of lines of mock structs is probably a sign that there is something very fundamentally wrong with the code. Go, as a language, has nothing to do with it. Testing is one of its nicest features. I only had to improve my testing experience just a bit, like stringifying complex outputs to compare them easily, comparing all of outputs with expected outputs in a single if statement and issuing a single verbo…

100s of lines. It feels very much like mocking objects in Java before mocking libraries came about. The explicitness is nice, but the verbosity increases very quickly as you start adding state to your mocks.

Re: Go best practices, six years in

#76

Post by catnaroek »

weberc2 wrote: post #62
MichaelGG wrote: post #58

Earlier quoted context omitted.

Rust has that built in, but managed to be a much more solid language (feature wise).

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…

It's not just about performance, but also (perhaps primarily!) correctness: making sure that resources (not just memory) are freed in the right places, that your code won't try to use resources that have already been freed, that the same object can't be mutated by two or more parties at any single point in time, etc.

Re: Go best practices, six years in

#77

Post by striking »

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.

Reminds me of when systemd parsed the kernel command line for the kernel debug parameter, making life hell for kernel devs.

It was so ridiculous, someone ended up sending in a patch for the kernel to modify the command line once it had been parsed to remove the debug parameter.

https://lkml.org/lkml/2014/4/2/415

Re: Go best practices, six years in

#78

Post by brightball »

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.

Re: Go best practices, six years in

#79

Post by eternalban »

spriggan3 wrote: post #53
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. What are you talking about ? the hype is strong with Go. So strong devs are persuaded they need to use Go at all cost then complain Go has a garbage collector ( just go go-nuts mailing list). So strong there are countless articles on the net about "How we moved from X to Go..." just like in 2007/8 with Rails. > The minute we see a bloated…

> just like .. Rails

Uncanny, isn't it?

Re: Go best practices, six years in

#80

Post by xixixao »

nedsma wrote: post #16
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…

I concur. Go syntax is dead simple and even the most basic tools like https://play.golang.org/ can be used without hesitation for some quick and dirt POCs. In the discovery mode, when you're learning a new library, any tool that supports code completion and provides documentation links is nice to have.

Surprises me it doesn't have syntax highlighting.
Post reply on HN