91–100 of 186 posts
Earlier quoted context omitted.
I never use new(). It gives a way to allocate, that I would prefer to avoid in favor of declaring zero-value explicitly. Maybe I am missing the point of new().
It's used like this p := new(int) since you can't say p := &int{}
I wonder if what I heard from some people is true, that at Google Go isn't used as widely as people think.
Earlier quoted context omitted.
I get constant requests for Node & React (web) and Python (AI / ML) developers. I do a little recruiting in the mobile space too and there’s a small need for React Native but a huge need for native mobile devs.
The reason why you are not getting any requests for Go is because you are not asked to find people for backend.
I wish they would ask what makes it difficult to work with dependencies in Go.
I agree with the sibling: go dependencies generally work exactly they way I want them to, and I find it very refreshing relative to other ecosystems. My guess is that folks coming from those other ecosystems are frustrated that it doesn't work exactly like NPM, which is the general model other ecosystems have decided to follow, despite it being unstable and insecure by design. Internally, we use a build tool called P…
The general model for package management in other language ecosystems is rubygems and bundler.
Like: a GitHub founder invented semantic versioning.
Earlier quoted context omitted.
I recently spent about 3 weeks looking for new Go positions, just by advertising open for work on LinkedIn. There are plenty of companies interested, many of them startups. I don't think anyone with a strong Go background looking for a job right now would have any trouble at all.
What is your process for this? Do you have a lot of Go related content in your LI profile or just have your title as Go developer? Any chance I could email you a few questions?
I think recruiters are perhaps able to scrape skills for keywords? I don't want my identity tied to HN, but if you drop me your email(or add it to your profile) i'll make a throwaway to reach out if you want.
Surprised to see language satisfaction so high. Error handling is very painful, and Go's own tools don't work together (eg. go mod tidy doesn't work properly with `go.work` since being released in 1.18). So many things in the language feel bad for no reason. At least they finally added generics!
> 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.
I wonder if what I heard from some people is true, that at Google Go isn't used as widely as people think.
The fact that it was developed at Google is incidental. That's where Robert Griesemer (Oberon) and Rob Pike (Plan 9) and Ken Thompson (Unix, Plan 9) and Russ Cox (Plan 9) and Ian Lance Taylor, etc., happened to be employed.
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.
if err != nil
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.
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…