Live data from Hacker News

Twelve Years of Go

go.dev

41–50 of 244 posts

Re: Twelve Years of Go

#41

12 years and still no proper error handling. World stars. ;) Seriously, the error handling is a big problem with Go. Not the way it works, the way it effects how people do control flow in general.

Error handling is easily one of my favorite things about Go. No 'oops I forgot to put in a try/catch and now my code died with no explanation'. No 'I forgot a finally ( or didn't realize I needed one ) and now I'm leaking resources'. No 'should I return Null or false or an error code?'. No '20 log messages for the same error because every function is reporting it'. The Go model - Return err, always as the last parame…

> Return err, always as the last parameter

Well unfortunately, not always.

Re: Twelve Years of Go

#42

A good twelve years. Go really changed the way I think about programming. I used to be excited by programming language features instead of what problem I was actually trying to solve with programming. I'd spend hours condensing 10 lines of perfectly working code into 1 line of the most concise text possible; huffman encoded better than even gzip could imagine. And I'd feel great about it. I'd imagine people reading i…

> I'd spend hours condensing 10 lines of perfectly working code into 1 line of the most concise text possible

Which is also the hardest part of convincing people to use Go for me: "Why can't I just .map()/.filter()/.find()?" followed closely by "Why do I always have to check for errors?"

What is odd to me is that while yes, my Go code is more verbose than my node services - I always end up writing less Go for the same thing.

Re: Twelve Years of Go

#44

Would you say Go is suitable for web services and apps? I was trying to compare it with a rapid development framework like Rails but felt Go Web Frameworks aren't as mature and ready like Rails. Any insight would be appreciated, thanks!

Yes.

I've used Rails extensively before writing some larger sites in Go. Quick comparison of Go vs Rails:

Pros: More performance, multi-threaded extremely capable web server built-in, culture of simplicity and low-dependencies, no breaking changes, goroutines, ideal for small services, static binaries (all deps included) so no need for rbenv, docker etc etc, no included JS, great stdlib (far better than Ruby's IMO), NO INHERITANCE.

Cons: No standard structure others are familiar with, you'll need to find/write code for things like migrations, auth, rendering views, skeleton code generation.

For things you need to find/write this may seem intimidating but it's an opportunity to explore the bits you liked about rails and jettison the bits you didn't like or need, and the stdlib includes a lot of what you need at a low level (e.g. html templating, crypto libs). I cannot emphasise the importance of no breaking changes, it's so refreshing compared to other language ecosystems like Ruby or JS.

Overall I'm really happy with Go for web apps and would choose it again in a heartbeat, particularly over Ruby and Rails (which I also like, but has performance issues and cultural issues IMO).

Re: Twelve Years of Go

#45

Earlier quoted context omitted.

Error handling is easily one of my favorite things about Go. No 'oops I forgot to put in a try/catch and now my code died with no explanation'. No 'I forgot a finally ( or didn't realize I needed one ) and now I'm leaking resources'. No 'should I return Null or false or an error code?'. No '20 log messages for the same error because every function is reporting it'. The Go model - Return err, always as the last parame…

1. You have something that catches and logs all uncaught exceptions. 2. Defer is nice. As easy to forget as using in C#. 3. Always null/nil. Uncle Bob is plain wrong here. 4. Stack trace. But you should keep things wide and shallow. No matter what technology you use. In Go it is about as easy to swallow errors as with try-catch. But my post was more about how all the if-statements generates more unnecessary if-statem…

>But you should keep things wide and shallow. No matter what technology you use.

This is literally the exact opposite of what I believe, and the bane of my existence at work. Wide and shallow code is spaghetti. Too many APIs = continuous confusion and relearning.

Re: Twelve Years of Go

#46

Earlier quoted context omitted.

Programming is always going to be complicated as long as the domain is complex. Go as is has traded having no learning curve for having nothing to offer.

I think a dumb language for dumb programs is a really valuable contribution - hardly nothing to offer. is it less suitable for hard programs than other environments - almost certainly

Thank you, that’s an excellent point.

Re: Twelve Years of Go

#48

Would you say Go is suitable for web services and apps? I was trying to compare it with a rapid development framework like Rails but felt Go Web Frameworks aren't as mature and ready like Rails. Any insight would be appreciated, thanks!

I suggest going Rails/Next.js/Django and then extracting Go microservices if you ever need it.

Re: Twelve Years of Go

#49
post #39
post #9

I’ve only picked up Go recently and I must say that the beginner experience is superb. Way easier to get started, learn new concepts and put them in use compared to some other languages.

can you recommend any video lectures?

I suggest running through each example at https://gobyexample.com

This personally helped me build a good foundation on Golang.

Re: Twelve Years of Go

#50

A good twelve years. Go really changed the way I think about programming. I used to be excited by programming language features instead of what problem I was actually trying to solve with programming. I'd spend hours condensing 10 lines of perfectly working code into 1 line of the most concise text possible; huffman encoded better than even gzip could imagine. And I'd feel great about it. I'd imagine people reading i…

If you think there's some virtue in writing verbose and inexpressive imperative code, what does Go provide in that department that you couldn't have got from Java 1.44?
Post reply on HN