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

101–110 of 207 posts

Re: Go best practices, six years in

#101

Post by jud_white »

dalyons wrote: post #14
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?

I've done a lot of ruby and go. Honestly, I would think twice before building a major website/product API on go. Development time is markedly slower in go, some causes off the top of my head: - testing is way harder (ruby has some amazing mocking/stubbing/testing tooling). - debugging is way harder. Hope you like printf. - Json; the strict typing & struct searialization rules make dealing with Json a pain in the arse…

> having no stack for errors is insanely frustrating.

Check out https://github.com/pkg/errors

If you want more rich control of the output of the stack trace there's https://github.com/go-stack/stack

Re: Go best practices, six years in

#102

Post by twr »

ramchip wrote: post #94
tujv wrote: post #85

Earlier quoted context omitted.

Possibly because Rob Pike is not a fan of syntax highlighting, calling it juvenile. https://groups.google.com/forum/#!msg/golang-nuts/hJHCAaiL0s...

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.

Re: Go best practices, six years in

#103

Post by jzwinck »

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.

I agree but find it bizarre that this tip comes in a list of best practices for the major language invented at Google, when the same company's "gflags" library, also heavily used, advertises right at the top that it allows definition of flags in any source file! https://gflags.github.io/gflags/

Re: Go best practices, six years in

#104

Post by MichaelGG »

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 know a whole lot about C++, but I've worked on projects using C. Seems to me Rust is straightforward and just enforces what you have to do in your mind otherwise.

Once IDEs start coming around it should be quite competitive. I'll admit to thinking the same thing: I'll use Rust for the absolute critical parts, then F# for the rest. But more and more parts I'm writing are easy enough to do in Rust, and I get the perf as a bonus.

Re: Go best practices, six years in

#105

Post by bkeroack »

andreynering wrote: post #45
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?

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/jinzh…

You don't actually need most of that.

Re: Go best practices, six years in

#106

Post by jasonwatkinspdx »

ramchip wrote: post #94
tujv wrote: post #85

Earlier quoted context omitted.

Possibly because Rob Pike is not a fan of syntax highlighting, calling it juvenile. https://groups.google.com/forum/#!msg/golang-nuts/hJHCAaiL0s...

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

On the whole I've found the golang community to be quite positive and enforcing good norms about crappy behavior. I wouldn't assume too much from a post Rob made 4 years ago.

Re: Go best practices, six years in

#107

Post by takeda »

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…

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.

Re: Go best practices, six years in

#108

Post by takeda »

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.

I would say it is second after node.js

Re: Go best practices, six years in

#109

Post by dalyons »

jud_white wrote: post #101
dalyons wrote: post #14

Earlier quoted context omitted.

I've done a lot of ruby and go. Honestly, I would think twice before building a major website/product API on go. Development time is markedly slower in go, some causes off the top of my head: - testing is way harder (ruby has some amazing mocking/stubbing/testing tooling). - debugging is way harder. Hope you like printf. - Json; the strict typing & struct searialization rules make dealing with Json a pain in the arse…

> having no stack for errors is insanely frustrating. Check out https://github.com/pkg/errors If you want more rich control of the output of the stack trace there's https://github.com/go-stack/stack

Yeah, we've started using that. Kind of amazing that you need an addon lib & Wrap() everywhere to make errors useful. Just more boilerplate! :)

Re: Go best practices, six years in

#110

Post by pacala »

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…

What do people use mocks for?
Post reply on HN