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

Go Developer Survey 2022 Q2 Results

go.dev

Post reply on HN
Print view View original

111–120 of 186 posts

Re: Go Developer Survey 2022 Q2 Results

#111

Post by bilinguliar »

AtNightWeCode wrote: post #105

Some thoughts. There is no best practice on how to structure a Go code base. go.dev is still ugly. It is ok in comparison to the old Win95-styled design. That awful closure fib example on go.dev is still a good reason to ignore Go. I would guess most of all devs don't understand it when they read it the first time. Fuzzing in general is an anti-pattern but can be useful.

I struggled with examples of codebase structure when I was learning the language. I looked into code written by Go contributors, and it struck me as “procedural.”

This is where a significant shift in my programming started: abandoning OOP, removing unnecessary dependencies, moving from Linux to OpenBSD, from k8s to VM, and from clouds to bare metal. Pros: I understand computers better and have more fun. Cons: companies are still at the stage of moving to a cloud. And now I have to wait for trends to catch up.

Re: Go Developer Survey 2022 Q2 Results

#112

Post by klodolph »

gregwebs wrote: post #54
klodolph wrote: post #17

Earlier quoted context omitted.

I would love to see some in-depth discussion about this. Even in 2022, I don't think it's clear what we want error handling to look like. You can ask for correctness guarantees from the compiler, but it's easy to ask, it's harder to design a system that actually works. > The lack of exhaustive switch case statements makes this worse because the compiler doesn't care if you're handling all the expected error types (or…

In Rust you can use the anyhow library if you want a similar level of overhead to Go and similarly aren’t worried about differentiating error cases. What do you think of adopting Zig’s error handling approaches to Go?

> [...] and similarly aren’t worried about differentiating error cases.

I differentiate error cases in Go, so I'm not sure what you're talking about. Sometimes it's done with ==, other times it's done with type assertions, type switches, and some helper functions in the errors package.

I've barely touched Zig.

I think it's contributing some important ideas, and maybe those ideas will get further developed in newer languages.

Re: Go Developer Survey 2022 Q2 Results

#113

Post by 37ef_ced3 »

bilinguliar wrote: post #91
37ef_ced3 wrote: post #82

Earlier quoted context omitted.

It's used like this p := new(int) since you can't say p := &int{}

Indeed, this may be the use case. I am curious how often you may need a pointer to an int.

Are you seriously suggesting that the language should not have notation for allocating zeroed primitive types and receiving the address of the allocation?

  var (
      p1 = new(int)
      p2 = new(*int)
      p3 = new(**int)
      p4 = new(complex64)
      p5 = new(complex128)
  )
I feel like you must be joking. Should we say

  var (
      c complex128
      p = &c
  )
every time?

Re: Go Developer Survey 2022 Q2 Results

#114

Post by icholy »

cletus wrote: post #66

I was glad to see Go get generics. Not because it was super-important but rather so we didn't have to hear about it anymore. I think exceptions are a false economy so I have no real issue with Go's error handling. It could be cleaner. Rust's match expressions are better. Multiple returns are a bit awkward. Something like a result or error union type would be better and could fit in with the type system. Standard erro…

> Putting domain names in import statements is a massive mistake.

Why do you say that? I appreciate the lack of indirection.

Re: Go Developer Survey 2022 Q2 Results

#115

Post by AtNightWeCode »

bilinguliar wrote: post #111
AtNightWeCode wrote: post #105

Some thoughts. There is no best practice on how to structure a Go code base. go.dev is still ugly. It is ok in comparison to the old Win95-styled design. That awful closure fib example on go.dev is still a good reason to ignore Go. I would guess most of all devs don't understand it when they read it the first time. Fuzzing in general is an anti-pattern but can be useful.

I struggled with examples of codebase structure when I was learning the language. I looked into code written by Go contributors, and it struck me as “procedural.” This is where a significant shift in my programming started: abandoning OOP, removing unnecessary dependencies, moving from Linux to OpenBSD, from k8s to VM, and from clouds to bare metal. Pros: I understand computers better and have more fun. Cons: compani…

C was the lang I first really learned. You can look at opensource projs and they are all very different. C# solutions for instance are so generic it is almost boring.

Re: Go Developer Survey 2022 Q2 Results

#116

Post by bilinguliar »

37ef_ced3 wrote: post #113
bilinguliar wrote: post #91

Earlier quoted context omitted.

Indeed, this may be the use case. I am curious how often you may need a pointer to an int.

Are you seriously suggesting that the language should not have notation for allocating zeroed primitive types and receiving the address of the allocation? var ( p1 = new(int) p2 = new(*int) p3 = new(**int) p4 = new(complex64) p5 = new(complex128) ) I feel like you must be joking. Should we say var ( c complex128 p = &c ) every time?

In five years, I needed to do the latter only once or twice because a library I was using demanded a pointer to a primitive. Forgive my arrogance, but why does one need a pointer to a zero-value primitive in Go? I sincerely believe there is a use case for it, but I never needed this.

Re: Go Developer Survey 2022 Q2 Results

#117

Post by clpm4j »

beltsazar wrote: post #65

I wonder if what I heard from some people is true, that at Google Go isn't used as widely as people think.

Wasn't YouTube rewritten mostly in Go several years ago? Java and C++ won't be displaced as the primary languages at Google, but I think Go is in the top 4 languages they use (along with TypeScript).

Re: Go Developer Survey 2022 Q2 Results

#118

Post by bheadmaster »

stouset wrote: post #108
bheadmaster wrote: post #64

Earlier quoted context omitted.

You are right, I have missed that, as I have written under the sibling comment. Though I'd like to ask - does that scenario really happen in practice? It is idiomatic to handle every error right after the function call that returns the error. To me, the lack of "if err != nil {" under the "bar(foo)" call really stings my eyes. I know, compile time checking is different from "it doesn't happen in practice". It's a tra…

You're looking at a minimal test case, not an example of it happening in real production code. Of course it's obvious in the minimal test case, that's the point. I've personally written something akin to the following, which triggered no errors (at the time, maybe this is fixed): foo, err := foo() if err != nil { nil, err } return foo, nil The worst part is because all of the error-handling is copypasta boilerplate,…

> Also note that now we've gone from "Doesn't [go] provide compile time check for errors?" to "Well I guess it doesn't check that errors are used, but that would never happen to me."

True, but there was also a "you are right" in between :)

Re: Go Developer Survey 2022 Q2 Results

#119

Post by randomdata »

mekster wrote: post #96
randomdata wrote: post #76

Earlier quoted context omitted.

> Error handling is very painful Wait until you try Typescript. First you have to try/catch and then you also need an if statement to type assert the error in order to do anything with it. Now that's painful. If errors were commonly returned as values you could beautifully reduce it to if statements alone.

If the called function only returns a specific type, how is there a need to type check the returning value?

Thrown errors are always of type unknown, so you have to assert them back into a known type.

Or throw caution to the wind and arbitrarily cast them to a type of your choosing, but that never ends well. A robust and maintainable system can’t reasonably do that.

Re: Go Developer Survey 2022 Q2 Results

#120

Post by geodel »

beltsazar wrote: post #65

I wonder if what I heard from some people is true, that at Google Go isn't used as widely as people think.

Well I don't know who are those people. Reasonable people would think Google would not let employees simply re-writing major chunk of existing code for production services in Go. So tons of huge projects in C++/Java/Dart will remain in same languages unless the product itself is sunset. Even then also Go will not be used to write OS kernel, device drivers and such.

So where ever else Go is used it is decent enough.

Post reply on HN