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

81–90 of 207 posts

Re: Go best practices, six years in

#81

Post by lastofus »

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…

Can you explain more about using Node for the front end? Do you mean you use `npm` for front-end package management, or are you running a Node server process along side your Go process on the backend?

Re: Go best practices, six years in

#82

Post by Mahn »

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…

You forgot 5. (In a more distant future) After a plethora of features, long time Go developers become disappointed with how much bloat the language acquired over the years, decide to start from scratch and design the definitive language to replace it. Go to 1.

Re: Go best practices, six years in

#83

Post by jimjimjim »

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…

err... RoR is a full-size framework. Ruby is the language. Go is a language. Go has frameworks.

You are comparing apples to oranges. With go you can then select what functionality, libraries, toolkits or frameworks you want to use with your system.

ps. why would you mention node? would you use node with a php site?

Re: Go best practices, six years in

#84

Post by bbrazil »

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.

Re: Go best practices, six years in

#85

Post by tujv »

xixixao wrote: post #80
nedsma wrote: post #16

Earlier quoted context omitted.

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.

Possibly because Rob Pike is not a fan of syntax highlighting, calling it juvenile.

https://groups.google.com/forum/#!msg/golang-nuts/hJHCAaiL0s...

Re: Go best practices, six years in

#86

Post by valarauca1 »

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

Re: Go best practices, six years in

#87

Post by twic »

askyourmother wrote: post #48
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…

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 minute we see a bloated testing suite with yet another DSL, for Go, we are in trouble.

https://github.com/onsi/ginkgo

Re: Go best practices, six years in

#88

Post by twic »

jaimeyap wrote: post #44
themartorana wrote: post #9

The article sort of glosses over IntelliJ with the golang plugin as an "other" IDE, but it's best in class hands down. At one point in my past I had sworn off of Java-based IDEs, and used Sublime Text for years with primarily Python and Go. Something convinced me to try Go in IntelliJ, and really it's fantastic. It also covers "important-to-me" features the author mentions. I haven't tried VSCode yet, but have tried…

I second this. I've given Gosublime (and more recently VSCode) a solid try on several occassions. Neither hold a candle to the Intellij Go plugin. Being able to give solid rename refactor, and code navigation, even when your code is in a partial spaghetti, non-compiling-mid-development state is hard. And the Intellij plugin does a decent job at it. Not quite Java-level good. But pretty darn good. The existing command…

go-plus for Atom is pretty good. I haven't used the IntelliJ plugin, so can't compare them.

Re: Go best practices, six years in

#89

Post by IanCal »

jsmthrowaway wrote: post #15
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…

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…

> Average latency is unimportant

That feels like an overly-bold claim. Improving your 99th percentile latency from 2 seconds to 1 second may not be worth it if you bring your average latency up from 0.05 seconds to 0.99 seconds.

> It's that 1% of clients sitting there for 2sec that impacts perception of your UX.

Well, surely that depends on what endpoints those are and what people are expecting from them. A 2s wait for a whole rendered dashboard page of your entire organisation may not really be a concern. A 2s wait for 'find out more about our fast CDN' might really harm sales.

Now, if your point was "you shouldn't only look at average latencies" then you're entirely right, but I cannot see how they're irrelevant. The overall distribution is important and I'd actually recommend that people look at this shape. Just picking one percentile is always going to be misleading because you're throwing away a vast amount of data.

Re: Go best practices, six years in

#90

Post by dlor »

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.

The flag libraries I've used always make this easy, but the problem comes in when you try to reuse that dependency in another binary as a library.

Maybe you've seen a better flags library than I have, though.

Post reply on HN