Like painting or architecture, woodworking have a finished state, after that, you just ship it and not worry about it again. whereas in software, everything is so malleable that a rewrite is often going to happen again and again.
My speculation: the authors didn't know / understand algebraic data types.
Also, to make algebraic data types useful, you really want parametric polymorphism. But yet again, the others of Go weren't familiar with this. The only vaguely related technique they knew about were C++ templates, and they (reasonably!) decided that they didn't want C++ template hell in their language.
That last part about templates is the least speculative of the bunch: I read some of the discussion they had about generics, and they explicitly mentioned templates (and how complicated they are) and pretty much mentioned nothing else for how to design or implement generics.
Go recently got some generics, partially thanks to some help from Phil Wadler who's otherwise more known for his work in functional programming.
You can use sum types without pattern matching and vice versa, but you are absolutely right that they synergies well.
I don't know enough about Golang: do you know whether it's possible to add pattern matching with destructuring as a fairly shallow syntactic sugar?
Generics were a much bigger change to the underlying language (and so would be Rust-like lifetimes, or even immutability); but pattern matching seems like something that should be relatively easy to add with only local repercussions?
Unfortunately for the same reason it lacks many other modern features introduced by CLU and Standard ML in the mid-70's, language designers don't want to overburn Go developers with PhD level concepts.
Algebraic data types (more technically sum types) are very much not “PhD level concepts”, despite the name. They’re just what C developers would call “tagged unions”.
I sympathise with the idea but I do think they put the line in the sand too close. Go that had generics and sum types from the start would be my near-perfect GC-ed language
Not having generics was never a fixed decision. The FAQ said since day one that they "may well be added at some point" and that "The topic remains open", so there was no "walking back".
By the way, not having ADTs is not a fixed decision either.
You seem to mistake the fact that the Go team is in no rush to add things to the language as a general rejection of these things.
It doesn't matter. What does is Go 1.0 shipped without generics. That single decision immutably affected the entire language. Now that generics have been retrofitted, the issues are clear as day:
- Awkward transition period between a stdlib with and without generics: [1]
- Completely different APIs for built-in data structures (slices, maps) and generic ones
- Lack of obvious follow-up features that would have been there at 1.0 if generics were added, e.g. iterators
They took the time to do it properly with input from experts on type systems (e.g Phil Wadler). The result is probably much better than what we'd have if the Go developers had quickly thrown together an implementation of generics 10-15 years ago. For example, the resulting type system is known to be sound.
Where did you get the information that the Go team never wanted Generics, even the hype around having generics yet the stats shows 50% of Go developers wasn’t interested in it
>Where did you get the information that the Go team never wanted Generics
By them acting as if they never wanting Generics, not having Generics from day zero, delaying their implementation for a decade with BS excuses, pretending they are some kind of unsurmountable problem....
They were literally pressureed into getting them in, after years of resistance, when they recognized the mess they've made
I have watched this talk back then when it came out, and I just rewatched the parts you linked. Nowhere in this talk he said that he isn't into generics. He said that he is not yet satisfied with design drafts (that existed at that time), and that he would like to bring in experts. Which he did, when he asked Phil Wadler to join, which led to the current design. The talk is actually proof that he was and is open to generics.
"If we can implement these and learn about it a lot of what becomes important will clarify and something will come out of it, maybe something wonderful."
Again, you make up some warped interpretation in your head.
And over that period, not a single person put forward a viable and fully worked-up proposal for how generics should work in Go. It's almost as if programming languages aren't developed by anonymous people complaining on the internet.
>And over that period, not a single person put forward a viable and fully worked-up proposal for how generics should work in Go.
That was the official excuse (while each and every proposal coming in was shot down, just to get.a sub par, half-thought, Generics implementation, full of sui generis and NIH details implementation.
It's not rocket science, there are 100s of languages with Generics, including languages with many orders of magnitude more than the adoption Go has.
Which proposal would you rather had been adopted instead?
It's strange to describe the current implementation has "half thought". A lot of work was done to make sure it was correct: https://arxiv.org/pdf/2005.11710.pdf It's probably one of the most carefully thought through generics implementations in a mainstream programming language.
>It's not rocket science, there are 100s of languages with Generics, including languages with many orders of magnitude more than the adoption Go has.
It's easy to add generics but not so easy to get it right (see e.g. Java's soundness issues, the total mess of C++ templates). Rust's generics also have some dark corners (e.g. https://github.com/rust-lang/rust/issues/84857).
There’s nothing stopping language maintainers implementing a feature if you really hate the slow and thoughtful journey then the language isn’t meant for your “ideal programming language”
Also generics is mostly stuff that make libraries more convenient, not average user code. It also reduces bugs where otherwise interface{} and type checking would be used.
If you compare the amount of attention, language bashing, dedication and sweat being put in it I should expect the survey to show at least 75% adoption
I am not sure this is true. Every single go project I have seen at work has pkg/ and internal/
If anything, I wish people would have main.go be a bit longer so I can see the main bones of the application but people always like to a := app(conf) ; a.run()
The design philosophy is what makes a programming language, any language maintainers could one day decide to have any of these, when you begin to understand “why this is language existed” you begin to understand its purpose
That’s also my question. ADT seems really to fit well with the no-class no-inheritance design that go took. I don’t see how it would affect the language in any major way. But then, i’m not an expert.
I wonder what happens, though, if you ask ChatGPT, "Is there a better toothpaste than Colgate"? The instance this question is not answered truthfully, ChatGPT becomes garbage.
They'll spend a lot of effort scrubbing any facts that they don't like or don't suit their agenda and narrative. Whether that's the agenda of advertisers, the powers that be, or the "privileged" classes won't matter.
You think Googles search results are opaque now?? Wait till it's hidden behind a 2 trillion parameter neural network.
And by extension of that, "fake news" will be targeted and the all knowing AI knowledge base will be used to determine what is false or true. This will be the end of disent. When they say we won't own anything, and we'll be happy, they also mean knowledge.
This will be a game of cat and mouse between the search companies and the regulators. It has to be clear it is an advertisement of sorts, at least in most countries, however, there are different ways to do this. It will put a significant number of lawyers' kids through university.
Isn't it lovely, just when OS vendors (at least iOS) finally decide to tighten their privacy controls to avoid ad-revenue-based companies to track more and more, a new and more subtle form of advertising comes up.
It would be very difficult for people to differentiate what's an ad and what's not. At least google and likes showed "Ad" or "Sponsored'. Will AI do it?
It will be a game of cat and mouse between the search companies and the regulators. I am sure it needs to be "clear" it is an advertisement. However, this can be done in several ways, some too subtle for the regulator's taste.
If anything, there have to be people in the loop to check balances (write good prompts to generate code and fix them) and take responsibilities for downtime.
That is why such generalizations is really bad for understanding. There are so many schools and “college” that are private. In fact nearly all are private except a few official one. And because of that there are many different schools of thought throughout. That exam system whilst extract a lot of student into it, it is much later first. And when it is bad it did kill a lot of innovation but it is not the examination. In fact it reflect something else.
