Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Twelve Years of Go

go.dev

Post reply on HN
Print view View original

21–30 of 244 posts

Re: Twelve Years of Go

#21

Post by jrockway »

mountainriver wrote: post #11
AtNightWeCode wrote: post #10

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.

It’s never actually been a problem for me, I prefer Go errors over most languages

I agree with this. What I like about the Go method is that all errors are equal -- they look the same if it's a stack of microservices running at different companies, a bunch of goroutines communicating state with each other, or if you're just calling a local function that fails. It's the same every time, and the programmer can cut through the noise and make a complicated error from a complicated system simple, concise, and easy to understand.

People seem mad that they have to plumb around `err`, and that they have to provide useful context with fmt.Errorf. I see that as letting good programmers make good systems. The default in other languages is useless -- line numbers and arguments is all you are allowed to have, and when something goes wrong it takes up your entire screen with noise. Not as good as everyone thinks it is.

Re: Twelve Years of Go

#22

Post by convolvatron »

ohCh6zos wrote: post #19
quadcore wrote: post #12

I cant believe they are moving forward with "generics". Programmers on average already tend to make things more complicated than they should be. Now every single module in the ecosystem is gonna use more abstractions, generics to fit their social environment. Its well known that abstractions are the devil. How many modules are gonna use generics when they should not? Most? Programmers are bad at programming and they…

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

Re: Twelve Years of Go

#23

Post by noah_buddy »

quadcore wrote: post #12

I cant believe they are moving forward with "generics". Programmers on average already tend to make things more complicated than they should be. Now every single module in the ecosystem is gonna use more abstractions, generics to fit their social environment. Its well known that abstractions are the devil. How many modules are gonna use generics when they should not? Most? Programmers are bad at programming and they…

I think there are many very simple and understandable situations where having the option of generics gives you a lot of power. Like any programming concept, it's just another tool in the box, if you don't want to use it, don't use it. If you disagree with how others are using it, wouldn't that mean these programmers are bad in your view and you shouldn't be using their modules anyway?

Re: Twelve Years of Go

#24

Post by jrockway »

quadcore wrote: post #12

I cant believe they are moving forward with "generics". Programmers on average already tend to make things more complicated than they should be. Now every single module in the ecosystem is gonna use more abstractions, generics to fit their social environment. Its well known that abstractions are the devil. How many modules are gonna use generics when they should not? Most? Programmers are bad at programming and they…

If you want to write unmaintainable code in Go, it's already very easy; just use interfaces incorrectly. Go lets bad programmers write bad programs. If you have a solution to that problem, your programming language will be the one that kills all current programming languages.

Generics will be similar; people will misuse them, and you'll curse their names when you have to dive in and debug it. But it will also let good programmers write very good programs and libraries, and that's going to be a huge benefit for everyone. As we've seen with interfaces, they can be misused, but they can also be used correctly. Just look at the standard library for examples of how they work well. io.Copy() was written once and can work on buffered streams, disk files, HTTP bodies, ... anything! That's a good use of interfaces. We're going to see the same with generics, and it will make a lot of people's lives easier and more enjoyable.

Re: Twelve Years of Go

#25

Post by nineplay »

AtNightWeCode wrote: post #10

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 parameter

- When you need more context, add it to the error before you return it

- There is a calling function that reports errors. Maybe main(), maybe a subscriber, maybe a goroutine. There can be other situations of course but the point is that there's a clear ownership. If someone is logging errors in a higher up method, they should be prepared to explain why in code reviews.

Re: Twelve Years of Go

#26

Post by AtNightWeCode »

mseepgood wrote: post #17
AtNightWeCode wrote: post #13

Earlier quoted context omitted.

I can live with the error handling. But as I wrote. The problem is that it encourages if-programming. Something that is a problem in the Go community.

since when is if-programming a bad thing

What you learn at school when it comes to programming is to avoid if-statements for control flow. It is error prone. If-statements are mainly used for various types of guards.

Re: Twelve Years of Go

#27

Post by princevegeta89 »

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!

Re: Twelve Years of Go

#28

Post by mseepgood »

skybrian wrote: post #20
mseepgood wrote: post #17

Earlier quoted context omitted.

since when is if-programming a bad thing

It depends on what kind. I didn’t find maintaining codebases littered with platform-specific ifdefs all that fun. If statements used for error checking are a bit verbose but basically fine.

Go doesn't have platform-specific ifdefs sprinkled throughout the source. Platform-specific code is separated into files guarded by build tags as recommended in 'The Practice of Programming'. Compile-time control flow is not mixed with runtime control-flow.

Re: Twelve Years of Go

#29

Post by jrockway »

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 it and thinking "wow, there's no way I'll ever be as smart as jrockway, I should nominate him for Extreme Excellence And Awesomeness award!" Sadly, there is no such thing. Go taught me that it's just structs, for loops, and if statements, and if you want someone to be impressed, they should be impressed by what the program does for them, not what language features you used to implement it.

It has also ruined other programming languages for me. "go get" doesn't print 30 lines of text telling me that a new minor version of "go get" is available, and that I should stop what I'm doing, rm -rf node_modules, upgrade it, and then resume what I'm doing. It just pauses for a bit, and then I have the library. (I also love reading about the node community's push to make installing libraries not run arbitrary code on your machine. Yeah, I've been doing that for years with Go. It's great. I can use a library and it can't print a "hire me!!!" ad at install time. What an innovation!)

I also remember struggling for years with not being able to run other people's software. There was an RPM package, but not a Debian package, so I have to build it from source. ./configure; make; oh no, the c compiler I have can't compile this code. With Go, you can just emit a binary for every supported platform dump the binary somewhere, and everyone in the world can download it and run it. No installing packages, no finding the right version of Go (that doesn't exist in your Linux distribution because they never ship up to date versions of programming languages). Just software, running, forever.

It's really good stuff. Go is the tool that lets me make software, and not worry about bullshit. And that's revolutionary, even 12 years later.

Re: Twelve Years of Go

#30

Post by handrous »

ohCh6zos wrote: post #19
quadcore wrote: post #12

I cant believe they are moving forward with "generics". Programmers on average already tend to make things more complicated than they should be. Now every single module in the ecosystem is gonna use more abstractions, generics to fit their social environment. Its well known that abstractions are the devil. How many modules are gonna use generics when they should not? Most? Programmers are bad at programming and they…

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.

What it offers is that code you didn't write is significantly easier to read & understand than in most languages.
Post reply on HN