It’s been available for most of last year. I’ve been using it for about 14 months. It’s been an “okay” experience. There are certainly some things that are better but there are major criticisms as to how certain issues are being handled in the name of progress.

But, the blogpost author is spot on about the community. Too many are defensive and dismissive of comments and concerns raised by users.

It would be nice if they weren’t defensive about it, but can you seriously blame them? Go has been getting crap for lacking generics for a very long time. It just gets tiring after a while. It’s the same trope over and over. (I’m not saying the criticism shouldn’t be made, but at the same time, we should understand the other side of things.)

Don’t let complacency kill the language.

I really don’t think this is about complacency. It’s about a concerted effort to say No to additional features. It seems people either love or hate this policy.

Too many are defensive and dismissive of comments and concerns raised by users. Sure, you may not have figured out the best way to do generics, but at least have it as a goal somewhere in your roadmap.

I agree.

I see things like algebraic data types and type traits in languages like Rust and I think to myself, wouldn’t it be great if I could use those in Go.

A lot of people think that some form of generics can be added to Go at some point. But I’m less optimistic with ADT. They were some discussions about this on golang-nuts and the general conclusion was that it would very difficult to introduce ADT without a large change in the language. ADT would interact in a lot of ways with fundamental features of the language like zero values and the way variable are initialized.

Stability isn’t complacency. There is a value to letting the community build on top of a stable base, while that base is made better. If you want features and constant language development – look to Rust. I don’t think Go should try to be Rust – nor vice versa.

Yeah, I hang out with the hg devs (and I have the teeshirt to prove it!).

durin42 is the big Google guy using hg, and he’s also in charge of parts of code.google.com. He’s grown the hg Google team, as you can see by the commit logs, and they’re replicating Facebook’s move of scaling git by replacing it with hg. I don’t think they have a PR announcement yet, but the amount of work going into Mercurial from @google.com emails should be evident.

Big companies are seeing the benefit of having gigantic repos and a DVCS. I have heard gossip of trying to court other big companies with replacing their gargantuan and slow git repos with gargantuan and faster hg repos.

Google uses a modified perforce with an optional git frontend.