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

21–30 of 305 posts

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

#21

Post by veber-alex »

fsociety wrote: post #18
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.

What's the tradeoff? what advantage having null pointers give?

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

#22

Post by etiennedi »

whimsicalism wrote: post #8

Go was successful because it came after decades of pretty much no language putting good networking tools in their stdlib.

Not sure if that alone is what made Go successful. But yes, having great networking tools in the stdlib is very refreshing! One of the things Go got right.

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

#23

Post by veber-alex »

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.

  a, err := f()
  if err != nil {
      return
  } 
  a, err = f()
This will compile.

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

#25

Post by ilyt »

whimsicalism wrote: post #8

Go was successful because it came after decades of pretty much no language putting good networking tools in their stdlib.

Not just networking but focusing on concurrency.

In before if you needed to make a highly concurrent network app you had to get into asynchronous programming that generally makes code looks shit (or at least slightly worse) and harder to debug.

With Go and goroutines taking IIRC around 8k for start you can "just" spawn as many of them as there are connections and write your code as if it was serial one. Add some half-decent concurrency primitives and it's pretty easy to not fuck up highly concurrent and highly parallel code.

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

#26

Post by aliasxneo »

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

Earlier quoted context omitted.

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.

a, err := f() if err != nil { return } a, err = f() This will compile.

I'm not at all defending the practice. I agree it's very easy to navigate around this. My answer is just the canonical one I've seen over and over again in books about Go.

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

#27

Post by stpedgwdgfhgdd »

Worked with Go over 6 years; my biggest annoyance at the beginning, verbosity of error handling, has mostly gone away. In most cases the explicit error handling helped us hardening the code.

What does still bother me is the lack of proper enum support. I remember when Java boosted their enum support and the way it impacted the quality of the code. Sure would love to see something similar in Go.

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

#28

Post by wolfspaw »

Go has turned into an Awesome language.

I'm one of those that cannot use a PL that has no generics... It kills the DX of Algorithms and Data Structures.

Now it has Generics, soft RT GC, and it might even get official Arena Allocation.

I /LOVED/ the Matklad comment of |error handling converging|, indeed -- it seems that PL community evolved to "any-error" + annotation-at-call-site.

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

#29

Post by packetlost »

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.

I would have taken sum types over generics, personally. It kinda sucks because you can't create something like Rust's `?` operator without them or making serious kludgy compromises.

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

#30

Post by ilyt »

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

Earlier quoted context omitted.

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.

a, err := f() if err != nil { return } a, err = f() This will compile.

a isn't used so it won't ;p

Honestly the thing that I think lacks more is macros. With macros it would be trivial to write

   a := Must!(f())
that

* assigns last return value to err

* calls return with that error if it is not nil

Post reply on HN