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?

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

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.