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

Ten years of “Go: The good, the bad, and the meh”

blog.carlmjohnson.net

Post reply on HN
Print view View original

11–20 of 305 posts

Re: Ten years of “Go: The good, the bad, and the meh”

#11

Post by aliasxneo »

veber-alex wrote: post #9

> Go’s error handling is more verbose than those other languages, but structurally, there’s a lot of commonality under the surface. In Go the type system doesn't force you to check for errors, the same way as languages with null pointers don't force you to check pointers before dereferencing them. That's the real problem with errors and null in Go, not the verbosity (though that doesn't help)

The typical answer is that Go doesn't allow you to not address values returned from a function. So, to ignore an error, you'd typically have to write:

result, _ := myfunc()

That being said, I most certainly prefer the approach that Rust takes to this problem.

Re: Ten years of “Go: The good, the bad, and the meh”

#12

Post by jeswin »

Veraticus wrote: post #10

Very insightful. Re: the generics point — As a Go programmer I always thought the generics complaint was kind of silly in practice — complicated code should be simplified and made more concrete, not more generic. I’m glad generics were implemented, if only to silence the chorus of people who didn’t even use Go but whined about the lack of them. Their inclusion has simplified the stdlib and led to some cool new functi…

> power

What power?

Re: Ten years of “Go: The good, the bad, and the meh”

#13

Post by Thaxll »

aliasxneo wrote: post #11
veber-alex wrote: post #9

> Go’s error handling is more verbose than those other languages, but structurally, there’s a lot of commonality under the surface. In Go the type system doesn't force you to check for errors, the same way as languages with null pointers don't force you to check pointers before dereferencing them. That's the real problem with errors and null in Go, not the verbosity (though that doesn't help)

The typical answer is that Go doesn't allow you to not address values returned from a function. So, to ignore an error, you'd typically have to write: result, _ := myfunc() That being said, I most certainly prefer the approach that Rust takes to this problem.

If there is a single result you can also on ignore the return value by calling myfunc()

Re: Ten years of “Go: The good, the bad, and the meh”

#14

Post by tail_exchange »

I was very skeptical of Go, but after trying it, it quickly became my main and favorite language. I think the drawbacks of the language are easily offset by how powerful and simple it is.

Its biggest flaw imo, which I don't think was mentioned in the article, is that Go did not learn from The Billion Dollar Mistake in Java: null references. You have zero protection against nil pointers, and this is likely not something that can be changed now without breaking backwards compatibility.

Re: Ten years of “Go: The good, the bad, and the meh”

#15

Post by icholy »

Veraticus wrote: post #10

Very insightful. Re: the generics point — As a Go programmer I always thought the generics complaint was kind of silly in practice — complicated code should be simplified and made more concrete, not more generic. I’m glad generics were implemented, if only to silence the chorus of people who didn’t even use Go but whined about the lack of them. Their inclusion has simplified the stdlib and led to some cool new functi…

> Nevertheless I think people implementing them in their own projects is basically code smell and they are a symptom of poorly thought-out code rather than excellent code.

Who needs data structures right?

Re: Ten years of “Go: The good, the bad, and the meh”

#16

Post by ilyt »

tail_exchange wrote: post #14

I was very skeptical of Go, but after trying it, it quickly became my main and favorite language. I think the drawbacks of the language are easily offset by how powerful and simple it is. Its biggest flaw imo, which I don't think was mentioned in the article, is that Go did not learn from The Billion Dollar Mistake in Java: null references. You have zero protection against nil pointers, and this is likely not somethi…

Lack of sum types and thus impossibility of just having Result-like type for returning errors is bigger one for me, I didn't get bitten by nulls all that much in Go

Although I guess that feeds into eachother, sum types would eliminate any need for null types in the first place.

Re: Ten years of “Go: The good, the bad, and the meh”

#17

Post by rowanseymour »

Veraticus wrote: post #10

Very insightful. Re: the generics point — As a Go programmer I always thought the generics complaint was kind of silly in practice — complicated code should be simplified and made more concrete, not more generic. I’m glad generics were implemented, if only to silence the chorus of people who didn’t even use Go but whined about the lack of them. Their inclusion has simplified the stdlib and led to some cool new functi…

Prior to generics we relied heavily on dynamic typing via interface{}, for example:

  BulkInsert(db *sql.DB, objs []interface{})
This unfortunately meant that any time you had []Foo.. you had to allocate a new []interface{} and copy over the items. Now a function like that can look like:

  BulkInsert[T any](db *sql.DB, objs []T)
And we're not wasting CPU cycles to copy the slice of []Foo. I'm struggling to see how that's code smell or less excellent than using []interface{} or duplicating the code for BulkInsert for every insertable type in our application.

Re: Ten years of “Go: The good, the bad, and the meh”

#18

Post by fsociety »

tail_exchange wrote: post #14

I was very skeptical of Go, but after trying it, it quickly became my main and favorite language. I think the drawbacks of the language are easily offset by how powerful and simple it is. Its biggest flaw imo, which I don't think was mentioned in the article, is that Go did not learn from The Billion Dollar Mistake in Java: null references. You have zero protection against nil pointers, and this is likely not somethi…

Nil is a carefully chosen name in Go, and was a trade-off which was made. It’s not quite right to compare it to null in other languages.

I agree it is not as safe as a language like Rust, however it was the right trade-off to make in my opinion.

The main protection you have against nil pointers are nil receivers, and knowing when to use reference semantics vs value semantics.

Re: Ten years of “Go: The good, the bad, and the meh”

#19

Post by whimsicalism »

ilyt wrote: post #16
tail_exchange wrote: post #14

I was very skeptical of Go, but after trying it, it quickly became my main and favorite language. I think the drawbacks of the language are easily offset by how powerful and simple it is. Its biggest flaw imo, which I don't think was mentioned in the article, is that Go did not learn from The Billion Dollar Mistake in Java: null references. You have zero protection against nil pointers, and this is likely not somethi…

Lack of sum types and thus impossibility of just having Result -like type for returning errors is bigger one for me, I didn't get bitten by nulls all that much in Go Although I guess that feeds into eachother, sum types would eliminate any need for null types in the first place.

Yes, sum types would solve the problem - you are both identifying the same issue imo

Re: Ten years of “Go: The good, the bad, and the meh”

#20

Post by ilyt »

Veraticus wrote: post #10

Very insightful. Re: the generics point — As a Go programmer I always thought the generics complaint was kind of silly in practice — complicated code should be simplified and made more concrete, not more generic. I’m glad generics were implemented, if only to silence the chorus of people who didn’t even use Go but whined about the lack of them. Their inclusion has simplified the stdlib and led to some cool new functi…

> As a Go programmer I always thought the generics complaint was kind of silly in practice — complicated code should be simplified and made more concrete, not more generic.

I guess you have never written a library. It's extremely useful there, stuff like "generic function that runs a channel thru X workers doing f() on it" is now easily possible with full type safety.

> Nevertheless I think people implementing them in their own projects is basically code smell and they are a symptom of poorly thought-out code rather than excellent code.

You can say that about literally any feature used by the incompetent.

But overall yes, they are far more useful for writing libraries than actual applications

Post reply on HN