I'm certainly thankful for golang as it made my https://github.com/purpleidea/mgmt/ project possible!
Thanks Russ!
Strongly disagree. Beyond very simple codebases lack of generics means either duplicating a bunch of code or eschewing type safety - neither of those things are particularly attractive to me. I can't imagine writing code in a strongly typed language that doesn't have support for generics.
Even if you don't use them directly it's almost certain you're using libraries that would be forced to be less ergonomic or type safe because of a lack of generics.
Type casts are checked.
> that doesn't have support for generics.
We get first class functions and compiled closures with zero syntax overhead. It's entirely manageable.
> or type safe because of a lack of generics.
Case in point: sort.Slice(). It lacks ergonomics, otherwise, entirely usable.
That being said, the generic version is faster and easier to use, so they are not without purpose, but they're not fundamental to large scale design either. Used without caution they can become a burden in and of themselves.
I like them just fine, but I could completely live without them.
Generics are a basic language feature for a statically typed language. Go needs a lot more features to be usable, like better error handling, but the ultra-conservative community that opposes any changes is a drag on the language and makes developing in it a miserable experience.
I guess what I'm caught up on is the idea of "usable" is entirely subjective. To my eyes and fingers, Go has been fine without generics, and since their addition I've only used them once to clean up an odd bit of code around instantiating "module" like initializers.
> and makes developing in it a miserable experience.
Subjective or not I find this a bit harsh. I spent years in an environment where C was the only option that could be used and Go is a complete dream compared to this. You may dislike the environments, you may find fault with them, but there are many examples of both of them being used to build large and complex systems that aren't completely "miserable" to work on.
I wonder if the split is something like "batteries must be included." I don't feel this way. I'm content to mine up Zinc and Copper and forge my own batteries if needed. I'm not at all put out by this.
You have been using a generic data-structure since Go 1.0 but did not realize this.
Did you mean replace `map[string]string` with `map[string]interface{}`? You should take a look at Go's runtime map code. This is not a "generic" data structure. It's an unsafe data structure with some thin compiler sugar on top of it which is also something worth taking a look at.
For example see how it handles something like `m["x"]` versus `m[12]` or a map using structs as keys. Put it in Godbolt then chase down the various runtime implementations you encounter. Unless I'm misunderstanding you, then I apologize, but what else did you mean?
> explain to all your stakeholders that you have done so because generics is bad.
I also write code based upon engineering principles and not on the difficulty of explaining it to my peers or customers. I'm more concerned with the results they experience when they use the software.
> generic data-structure
What we call "go generics" has nothing to do with "typed go maps." To the extent that I've needed something "generic" up until they were formally introduced into the language careful interface design was enough to cover 90% of use cases. For the ones that weren't a map holding a function which wrapped a type-checked cast operation did the rest.
So all we're left with is the ability for the current go generics to automatically populate functions into your compiled image based upon instantiated and optionally constrained type usage rather than some explicit and planned mechanism implemented through interface.
> I also write code based upon engineering principles and not on the difficulty of explaining it to my peers or customers.
I believe that difficulty of explaining code to "my peers or customers" is a basic engineering principle.
Also, I consider what the compiler does behind the scenes as irrelevant as long as you have reasonable performance and usability qualities. That's one of the fundamental principles of abstraction after all.
Btw, the inventor of the C programming language also said this. Dennis Ritchie -> "Code should be written for humans first, machines second"
ok errors.As is a little stupid, I'll give you that. But that's all.
I strongly disagree. Sure, like anything in programming, generics can be misused. But even comments can be misused!
OTOH I am able to build things in Go with generics that I would not be very happy building without them.
But generics as a high-level concept are wonderfully simple and useful ("let me use different types with certain code constructs without having to manually duplicate them, and stop me from doing anything that doesn't make sense"). It would be a far easier call for languages to add them if they were just a bit of syntactic sugar instead of a whole new section in the manual. (I do think adding generics was a good call; practicality trumps a fussily clean design, in my book.)
And arguably are in Go, where they are used for all kinds of things that are not inline documentation!
That doesn't look like is going to happen — the leadership change announced here seems to me to continue on the Google path. Both Austin and Cherry are relatively unknown outside Google and are to my knowledge not active in the community outside Google.
I don't believe this is true at all. They are both highly active in external Go development, far more active than I have been these past few years. (It's true that neither gives talks or blogs as much as I do.)
What does this even mean? Google basically just finances the project, but doesn't really "control" anything, never mind that "Google" isn't a monolithic entity in the first place.
Who is "they"? Who is "the community"? Who qualifies for a vote and who doesn't? I never contributed any code to the Go compiler or stdlib, but have contributed to some aspects of the "wider ecosystem", including some things that see fairly broad usage, and am (coincidentally) wearing a 2018 GopherCon t-shirt as I write this. Do I qualify? Does someone who has been writing Go for a year qualify? A week? Someone who never even wrote Go code? Someone who sent in a single patch to stdlib? And how do you verify all this?
Saying "let the community vote" is easy, but if you think about it for more than a second you will realize there's tons of difficulties and that it doesn't really work. I also don't really know of any project that works like this: it's pretty always a fairly small group of "core contributors" that get to decide.
Python, Postgres, Rust..
A small amount of core contributors doesn't mean they all have to come from a single corporate entity either.
The notion that only Google could shepherd a programming language is hilarious.
I never said anything of the sort. I said that "let the community vote on who new leaders are" doesn't work. Python, PostgreSQL, and Rust don't work like that either; it's just members of a fairly small "core team" that can vote, or some variant thereof. I have no inside knowledge here, but I'll stake a good amount of money that the Go core team had a lot of discussions about this, and de-facto, it's more or less the same as having a vote – except maybe a bit less formal.
And Go would obviously be fine without Google, just as Rust was fine without Mozilla. But why bother? It's working fine as it is and Google wants to spend the money on developer salaries, so why not let them? People get far too hung up on "Google bad". I say this as someone who doesn't even have a Google account or Chrome installed.
I think Rust is better divorced from Mozilla, and Go would be better if it was divorced a bit from Google for a lot of the same reasons.
I don't really follow what you mean with that.
People keep going on that Big Tech needs to invest more in open source projects and maintainership. "But no, not like that!" Hmkay...
In the end, the people doing the work get to decide. That's how it works everywhere. Go originated at Google and many (though far from all) of the core people working on it are still paid by Google. The people doing the work seem to have no problem with this relationship, so standing on the sidelines shouting "no no, do the work differently!" is not really brilliant IMO.
And as I said, I don't see Google "controlling" anything. What does that even mean? Larry Page deciding what happens in the next Go release or something?
I've worked at Google, I've used Go for about 8 years at this point and I've met a few of the key Go figures at some point. I have to say that I have _no_ idea who would be best to run the project. And neither do you.
This isn't politics where the winner gets to vanquish their enemies and make themselves and their friends and family rich. It's developing and maintaining a programming language. The only real reward you'll get is admiration IFF you do a good job. Do a crap job and you ruin the project and/or become a pariah.
I would rather have those people who make up the core leadership tell me who should run the project since they not only know the technology, but they know the people and they know how to provide continuity. Continuity and discipline is all-important.
I'd prefer it if whoever runs the project works for Google since that is where Go was born. In part for continuity reasons and that Google has proven to be a very good home for Go, but also because it is good to have direct access to an organization that has resources to support you.