Live data from Hacker News

Twelve Years of Go

go.dev

11–20 of 244 posts

Re: Twelve Years of Go

#11

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

Re: Twelve Years of Go

#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 are social herdy beast - they are human. Their code must follow the social norm. The consequences of that could be terrible for the language.

I dont understand why they move forward with this. Go is absolutely awesome, it's a gem, adding generics is too risky. This is such a bad news for me (i didnt know). I'm trully affected.

Re: Twelve Years of Go

#13

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

Re: Twelve Years of Go

#14

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…

Generics are not that complicated or hard to understand, and most of the time developers don’t even need to interact with them, except to say what type of data will be used in a collection.

Re: Twelve Years of Go

#15

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.

Thats your opinion. I love the error handling in go. I think its superior to the traditional try/catch approach most other languages use.

Re: Twelve Years of Go

#16

Earlier quoted context omitted.

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

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.

If it's helping keep the "'if' considered harmful" crowd away, I say keep it. There are plenty of other languages.

Re: Twelve Years of Go

#17

Earlier quoted context omitted.

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

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

Re: Twelve Years of Go

#19

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.

Re: Twelve Years of Go

#20

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

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.

Post reply on HN