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

161–170 of 186 posts

Re: Go Developer Survey 2022 Q2 Results

#161

Post by dwattttt »

randomdata wrote: post #159
josephcsible wrote: post #148

Earlier quoted context omitted.

> As someone who's not a day-to-day developer/software engineer: the Go code is more readable. COBOL is what you get when you optimize for readability by people who don't know how to program. > The Rust is interesting, for sure, but I don't know what "?" is doing. I like the use of the question mark as it makes the act of calling the function a question - did it work or not? But what's not obvious is what happens if…

> It gets returned to the next level up, exactly like in the analogous Go code above. That sounds utterly horrible. You would never actually write that Go code in the real world. Let's modify the original example slightly: res1, err1 = canFailA() if err1 != nil { return err1 } res2, err2 = canFailB() if err2 != nil { return err2 } Let's assume an error was returned. You realize from the error that there is a bug in t…

> Which function did the error come from? Who knows. And what if canFailA/canFailB return errors from other functions up the stack the same way? Now you've got a massive tree of possibilities to try and work through. A complete nightmare.

This is why the popular approach in Rust is to add "failed to do X" to the error before returning it, which is handled by popular libraries.

An example of the effect:

Failed to start, caused by

Failed to load config, caused by

File not found (the error from the OS)

> This is a real problem that should be solved, but it's not a problem of errors. It's a problem of values in general. Remember, the Go language has no inherit concept of error. Anything that we happen to call an error is actually just a user-defined type, same as any other type a user might define (birthdate, order number, stock price, etc.).

The concept that a function can fail is pretty fundamental, ignoring it at the language level is like saying "a function failing is not common enough to address consistently"

Re: Go Developer Survey 2022 Q2 Results

#162

Post by randomdata »

dwattttt wrote: post #161
randomdata wrote: post #159

Earlier quoted context omitted.

> It gets returned to the next level up, exactly like in the analogous Go code above. That sounds utterly horrible. You would never actually write that Go code in the real world. Let's modify the original example slightly: res1, err1 = canFailA() if err1 != nil { return err1 } res2, err2 = canFailB() if err2 != nil { return err2 } Let's assume an error was returned. You realize from the error that there is a bug in t…

> Which function did the error come from? Who knows. And what if canFailA/canFailB return errors from other functions up the stack the same way? Now you've got a massive tree of possibilities to try and work through. A complete nightmare. This is why the popular approach in Rust is to add "failed to do X" to the error before returning it, which is handled by popular libraries. An example of the effect: Failed to star…

> The concept that a function can fail is pretty fundamental

Not at all. This is a grave misunderstanding of computing. Functions fundamentally can't fail. They can only enter different states. Only under exceptional circumstances, like the programmer screwed up or the machine is literally on fire, could they fail.

Indeed, Go does provide a method for dealing with exceptional circumstances (what we often call exceptions for short). See: panic/recover.

Re: Go Developer Survey 2022 Q2 Results

#163

Post by klooney »

BobbyJo wrote: post #107
bheadmaster wrote: post #72

Earlier quoted context omitted.

> Python’s venv dance only really comes into play if you need a third-party dependency that you haven’t installed globally. True. Though installing third-party dependencies globally is considered bad practice, since it can easily break system packages. > The Go dance is always necessary, which makes it slightly more annoying for short scripts or tests. Well, if you just want to compile/run a single file (or a couple…

I can't tell you how many time global dependencies in python have cause me headaches. Do a small project then do another small project 6 months later and the formers dependencies conflict with the latter's.

It's such a nightmare for internal scripts. Even for ruby shops where theoretically bundler solves the problem there's all these cowboys with ten external dependencies and no lockfile

Re: Go Developer Survey 2022 Q2 Results

#164

Post by throw_m239339 »

randomdata wrote: post #139
throw_m239339 wrote: post #109

Earlier quoted context omitted.

> Random internet comments don't mean anything. These weren't random internet comments, these were a bunch of well known gatekeepers in the main go mailing list trying to gaslight everybody else and threatening to quit Go if Go ever added generics. Obviously that didn't work and now these people have lost any form of power they thought they have. But these are very public people I won't name here. > Nobody who matter…

> these were a bunch of well known gatekeepers in the main go mailing list Celebrity status doesn't make someone's comments any less random. > Let's not try to rewrite history. No need to rewrite anything. It was written right on golang.org for most, if not all, of Go's public life. Though obviously no longer relevant these days. The various generics proposals (eight of them, if I recall correctly) were also publishe…

> The various generics proposals (eight of them, if I recall correctly) were also published publicly.

And? It doesn't make go generics "always explicitly on the table", Pike didn't want them and it's profusely documented in his blog. So please don't invent facts now.

Re: Go Developer Survey 2022 Q2 Results

#165

Post by BreakfastB0b »

nominusllc wrote: post #141
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…

> so we didn't have to hear about it anymore Generics were a mistake, and this is spot on.

Go always had generics, map, slice, chan are all generic. Go just didn't let the user write any generics, so fuck you if you want any other data structure until 1.18.

If you really think you don't need generics, take your code code and replace every

  []int{}, []string{}, map[string]string{}
with

  []interface{}{}, map[interface{}]interface{}{}
and see how much you "don't need generics"

Re: Go Developer Survey 2022 Q2 Results

#166

Post by awb »

Aduket wrote: post #156
awb wrote: post #151

Earlier quoted context omitted.

No, I am. Companies just seem to want their web app backend built on a JS stack, and ask for Node devs. Maybe Go is more systems/ops heavy, of which I’m not recruiting actively for.

thanks for the reply. and what stack, tools do companies ask for ML/AI recruiting?

Python / Tensorflow / PyTorch mostly. And then other specifics depending on the AI/ML discipline or problem space.

Re: Go Developer Survey 2022 Q2 Results

#167

Post by pjmlp »

awb wrote: post #151
rochak wrote: post #77

Earlier quoted context omitted.

The reason why you are not getting any requests for Go is because you are not asked to find people for backend.

No, I am. Companies just seem to want their web app backend built on a JS stack, and ask for Node devs. Maybe Go is more systems/ops heavy, of which I’m not recruiting actively for.

Different set of companies, because I get spammed for .NET, Java and C++ backend positions almost every day, and zero node stuff.

Re: Go Developer Survey 2022 Q2 Results

#168

Post by nirui »

kitkat_new wrote: post #138
bilinguliar wrote: post #19

I am delighted with the error handling in Go. Overall I would prefer to Go with the current features and not add more, maybe even deleting some inconsistencies in Go v2.

I find that interesting, and like the Rust way of error handling much more. Go error handling blows the code up a lot and makes the code less comprehensible. res1, err1 = canFail() if err1 != nil { return err1 } res2, err2 = canFail() if err2 != nil { return err2 } return res1 + res2, nil becomes res1 = canFail()? res2 = canFail()? return Ok(res1 + res2) guess what is more readable

I like how currently Go handles errors.

It's not just about

    res1, err1Error = canFail()
it's also about

    res1, successful1Bool = canFail()
and many other ways that communicates an abort event. Current Go syntax handles every case in a consistent way, while the Rust-like syntax could only apply to error type specifically. But you don't always have to return an error if something failed (say Hashmap lookup, strings.Index, or even just `if res1.IsValid()` without `err1` all together), right?

Another thing to add is that, syntax sugar such as `canFail()?` cannot help you with situations when you need to do something if the error happened, say:

    res2, err2 = canFail()
    if err2 != nil {
        res1.Drop()
        return err2
    }
you still have to write the flow in the old way. Rust can do that safely because it can automatically/magically drop things, Go can't and don't.

All and all, the application for sugars such as `canFail()?` is very narrow. IMO not worth to consider add.

Re: Go Developer Survey 2022 Q2 Results

#169

Post by strager »

nobleach wrote: post #153
throwaway893031 wrote: post #51

I begrudgingly use Go. Go really fucked us by not having sum types or exhaustive type-safe switches or pattern matching. It doesn't even have optionals, or type-safe nillables. The error handling is the least of my concerns. Moving on, I'd like to see an ML-like language (with hindly milner) that has M:N threading, with pre-emptive multitasking, and safe concurrency with borrow checker like Rust, with both structural…

Whether it's Thread.new() or go func() or whatever. There needs to be an explicit way to say, "do this concurrently, NOT synchronously". That's pretty much all async/await is trying to accomplish, no?

Function coloring is a problem with async/await: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

Re: Go Developer Survey 2022 Q2 Results

#170

Post by thiht »

klodolph wrote: post #17
aniforprez wrote: post #5

I'm genuinely hoping that after generics, the focus will be on error handling from the survey results Go devs in a lot of communities love to put their heads in the sand going "error handling is perfectly fine". But it's not fine. Not even close. And I'm very happy there's a lot of demand for some solution in this space. It's just plain too verbose without any of the actual benefits of that verbosity. You don't have…

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…

> I've seen some proposals but I haven't seen anything that was clearly a good proposal

I have one! Allowing inline ifs, like this:

    err := func()
    if err != nil { return err }
1 line instead of 3 for simple error handling, yeaah
Post reply on HN