jy3

No. All the ones you mentioned are up.

Just implement methods in your config struct in such a way that they are safe for concurrent access?! Using a mutex for example.

Why would you need it to lock mutexes everywhere?

I hope you have the presence of mind to realize the amazing benefit this has for the entire Go codebase in existence.

> errors thrown for unused imports

You're doing something wrong if it doesn't get cleaned up automatically.

> It's far better than this.

I don't know what you're referring to. Any links?

Can anyone enlighten and explain why there were restrictions in the first place?

> There are a number of patterns to limit the number of goroutines, and none of them are exactly easy. A simple example might be something like:

This is probably what the author was looking for https://pkg.go.dev/golang.org/x/sync/semaphore

net/http is all you need. You don't need any library or framework.

Looks a lot like the already proposed check/handle keywords that was met with a lot of push back from the Go community:

https://go.googlesource.com/proposal/+/master/design/go2draf...

Doesn't look like the proposal adds anything new.

Describing its concurrency model as one of its weakness is a bold statement, because it's probably one of the biggest reason it became widely adopted.

Everyone is different, but Go 's concurrency model has been the easiest for me to reason about. And I've dealt with my fair share of "async/await".

One would think that syadmins love native executables with no system dependencies.

I'm taken aback. I didn't mean to sound condescending.

I won't argue with you my use of the imperative mood as I'm not a native speaker. I'll take note of it.

Reading HN, it feels like some people just want every language to have the same features and have them implemented the same way.

Sad indeed.

That means Go is not the right tool for you. Don't use it.

It's so sad to see people pushing to radically alter a language that they will probably never use because it will never be suitable for their needs.

My gut feeling is a significant part of people who voted for them don't really intend to use Go that much.

They might try to please different crowds with Go 2. At the end of the day, they might just loose everyone.

> Just because a feature can be misused doesn't mean it's not legitimately useful.

The point isn't that it can't be useful.

In the real world, the amount of code I'm forced to understand that uses overly complicated abstractions is the issue. I'm glad one language finally took the opposite direction.

Except it's just a returned value and not a goto lookalike.

I'm not sure I understand the relationship between union-types and exceptions. You mean something like <Result, ErrorData>? Could you expand on that?

> Thanks to panics, even in Go.

Fortunately, for some reason Go developers don't use panic like exceptions and recover them at library boundaries.

That's precisely why Go is loved.

I've always been annoyed by the parallel control flow introduced by exceptions in any language. They are used so often in many languages where it doesn't feel necessary.

The fact that I don't even have to think if the function call I'm looking at can throw and if I should catch it or not outweighs everything.

Just using WithStack() from "github.com/pkg/errors" on any error that originates from outside my repository has been my go-to rule for any Go project. It has never disappointed.

I have the same question. I've never bothered looking back extensively at Atom since using VS Code.

As previously stated, Go for video game servers feels like a no brainer.

It's kinda hilarious to see that as more and more successful projects and companies use Go in their stacks, the number of comments like these increases in HN.

Of course it's written in Go.

It's amazing to see the language embraced that much for server side apps.

I'm sorry it went badly then.

Your example intrigues me, isn't an interface enough?

Is what bother you that the return value won't be typed T but IIncrementable in go?

> I’ve tried porting some of my Java code, and it quickly grew to some classes being duplicated hundreds of times

Who would have thought. Maybe a rewrite would have been more appropriate.

I think you are missing the point. Of course you can't assume what a function will do with certainty.