Go best practices, six years in • Hacker News Board

Re: Go best practices, six years in

#51

Post by spriggan3 » Sun, May 01, 2016, 8:42 PM UTC

ver4no wrote: post #28

matthewmacleod wrote: post #20

Earlier quoted context omitted.

My experience says "don't use Go for building web applications". Compared to something like Ruby on Rails, the development story with Go is much less batteries-included. You'll find yourself gluing together lots of components, and they're not really that friendly. Plus, for any front-end code, you'll end up using Node or whatever anyway to build assets. It's big and messy and not a good match. Go does excel at two ki…

what would you use go for then?

People use Go to write "infrastructure services", such as Rest APIs, caches, proxies,queues ... and command line tools. That's what Go does best since it requires minimal investment upfront( the language is tiny, the standard library has a lot of network oriented code...).

Whether one can effectively write a classic website with complicated HTML templates and web forms like Rails,JSF and co allow is however questionable since Go type system lacks of expressiveness. Go fans answer is "use client side javascript" which is ironic since javascript is the antithesis of Go in terms of design.

Re: Go best practices, six years in

#52

Post by gkya » Sun, May 01, 2016, 8:43 PM UTC

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…

> - debugging is way harder. Hope you like printf.

Can't you use gdb with Go? https://golang.org/doc/gdb

Re: Go best practices, six years in

#53

Post by spriggan3 » Sun, May 01, 2016, 8:47 PM UTC

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

GoConvey and co ...

Re: Go best practices, six years in

#54

Post by spriggan3 » Sun, May 01, 2016, 8:48 PM UTC

gkya wrote: post #52

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…

> - debugging is way harder. Hope you like printf. Can't you use gdb with Go? https://golang.org/doc/gdb

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

Re: Go best practices, six years in

#55

Post by Philipp__ » Sun, May 01, 2016, 8:51 PM UTC

nedsma wrote: post #25

alexellisuk wrote: post #21

After working with .NET/Java/Node.js/Ruby/Python etc the move to Go involved a larger investment in time. I found this really informative and it's great to have the learnings condensed down.

Check out YouTube conf. talks from the same author, where he shared his experience developing services in Go, while working at SoundCloud. Also, very helpful.

Could you please provide the link?

Re: Go best practices, six years in

#56

Post by pstuart » Sun, May 01, 2016, 8:55 PM UTC

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…

> debugging is way harder. Hope you like printf.

You have other options: https://github.com/derekparker/delve

Re: Go best practices, six years in

#57

Post by catnaroek » Sun, May 01, 2016, 9:05 PM UTC

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.

Not even for pointers, maps and slices?

Re: Go best practices, six years in

#58

Post by MichaelGG » Sun, May 01, 2016, 9:09 PM UTC

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…

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

Re: Go best practices, six years in

#59

Post by fludlight » Sun, May 01, 2016, 9:15 PM UTC

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…

Is this different from statically linked libraries (as opposed to dynamically linked)?

Re: Go best practices, six years in

#60

Post by dllthomas » Sun, May 01, 2016, 9:17 PM UTC

> No statements go by where the object is in an intermediate, invalid state.

This seems kind of misleading. Per my understanding of Go, omitted fields in a struct initialization are defaulted not reported as errors. So you're equally likely to be passing invalid state, in the two situations.

One pattern I like in Haskell, for this kind of thing, is to define a defaultConfig value that contains typical defaults and which can then be tweaked as desired.

One big advantage this has is that when some functionality is made newly configurable, you set the default to be the old behavior and existing code continues to work correctly unmodified without any additional effort.