Explanation: go has been missing generics for a long time. Finally we understand why: Rob Pike, one of the main authors of the language, believed that OOP inheritance was worse than composition. After 10 years, they finally learned that generics and OOP inheritance are different things and added them to the language. I had to shorten the quotes a bit for brevity. But the point is that he really believed that generics and inheritance are the same thing.
The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly old, long out of school, probably learned Basic, maybe learned C or Cobol, probably learned Algol68. They’re not capable of understanding a brilliant language but we want to use them to create a programming language. So the language we create should be easy to understand and easy to create.
/uj You can read the original post yourself, link at the very top of the page. It seems that all his knowledge of types is limited to the fact that there are languages like Java and C++ (which he says "Plus C++ just made it all seem too cumbersome, although I admit I was never truly facile in the language") and there is OOP inheritance, which is bad.
You might want to check out its implementation of basic functions like map and filter by Rob Pike for go:
Notice how the author says "with as nice an API as I could manage". This "nice" API accepts any type, does type checks at runtime via slow reflection, and throws a panic if the types don't match. This is a programming best practice, like in JavaScript with undefined is not a function.
Rob: name: 'go'. you can invent reasons for this name but it has nice properties. it's short, easy to type. tools: goc, gol, goa. if there's an interactive debugger/interpreter it could just be called 'go'. the suffix is .go.
Staggering insight! Surely this statement isn't true for all 2-letter (and perhaps even 3- or 4-letter) strings, only this one specific 2-letter string, which also happens to be one of the most commonly used words in the English language.
Surely this won't mean everyone comes up with a longer name that is actually google-able
The name Rust is also a bit of a misnomer: someone made a game with the same name, which leads to confusion. But sometimes it's fun, for example when someone asks why their FPS is low, you can clarify whether they added the --release flag and whether they use .clone() on heavy objects.
Fun fact, the game was named after the programming language primarily for the search engine confusion. The developers stated in an IGN interview in 2019, "knowing our game would be a hit, we chose the name to destabilize their search results, because if we couldn't be blazingly fast with zero cost abstractions and memory safety, nobody else should either."
This is a planned attack. Otherwise, how do you explain the fact that the Japanese named the city after one of the key libraries in Rust? They want to make it difficult to find, they want you to never know the truth.
Those silly Julia compiler devs could take a hint from Go! What with all their types like Vector, StridedArray, BitArray, SubArray, CartesianIndices, etc etc etc. Don't they realize it's all just arrays and slices?
They're still working on figuring out Array over a decade on while the good people working on Go only took a year!
What you're given is a set of powerful but easy to understand, easy to use building blocks from which you can assemble—compose—a solution to your problem. It might not end up quite as fast or as sophisticated or as ideologically motivated as the solution you'd write in some of those other languages, but it'll almost certainly be easier to write, easier to read, easier to understand, easier to maintain, and maybe safer.
Wow. That sounds great. I'm sold. There should be some kind of academic discipline which works on trying to find powerful, easy to understand, easy to use building blocks of programming languages from which you can compose a solution to your problem. One might call this "programming language theory". If there were such a thing, it might have profound ramifications for the effective design of software, and perhaps even inform the design of languages like Go.
What you're given is a set of powerful but easy to understand, easy to use building blocks from which you can assemble—compose—a solution to your problem.
Boy it's a real shame that the first language to hit the ideal Pareto optimal performance-ergonomics tradeoff of AOT compiled plus garbage collected had to be this one
Strictly not worse than anything else when looking at all dimensions, e.g. Lua has arrays that start with the best number but Solidity lets you spend your entire net worth in one API call, so the set of two of them has two Pareto optimal elements if you like both off-by-one errors and being poor
Pareto optimal is when you've reached the point where it is impossible to make something/someone else better other than by making something/someone else worse.
Or, perhaps a bit more formally, all potential improvements that benefit at least one person/aspect without harming at least one person/aspect have already been made.
This is a "built-in" generic in the language. First, it directly contradicts what he claims in this post (which was written after the release of version 1.0):
What it says is that he finds writing containers like lists of ints and maps of strings an unbearable burden. I find that an odd claim. I spend very little of my programming time struggling with those issues, even in languages without generic types.
Second, they obviously had no experience with other programming languages and didn't know how to write generics correctly, so they chose this stupid syntax: map[string]int vs OtherType[string, int]. Now in a language where everything is supposedly done only in one way, there are two options for declaring local variables and two options for declaring generic type arguments.
Cniles inventing a language be like: OK, first order of business, how do we represent UB mystery-typed values?
At least they didn't simplify the language further by making this the only type.
Explanation: go has been missing generics for a long time. Finally we understand why: Rob Pike, one of the main authors of the language, believed that OOP inheritance was worse than composition. After 10 years, they finally learned that generics and OOP inheritance are different things and added them to the language. I had to shorten the quotes a bit for brevity. But the point is that he really believed that generics and inheritance are the same thing.
The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly old, long out of school, probably learned Basic, maybe learned C or Cobol, probably learned Algol68. They’re not capable of understanding a brilliant language but we want to use them to create a programming language. So the language we create should be easy to understand and easy to create.
If anyone actually learned Algol68 we wouldn't be in this mess
Bruh, that's a sick, slow burn. Bravo!
In 10 more years, we'll learn that OOP inheritance is actually fine, and all the complaining about it boils down to skill issues
/uj is this actually serious?
/uj You can read the original post yourself, link at the very top of the page. It seems that all his knowledge of types is limited to the fact that there are languages like Java and C++ (which he says "Plus C++ just made it all seem too cumbersome, although I admit I was never truly facile in the language") and there is OOP inheritance, which is bad.
You might want to check out its implementation of basic functions like
mapandfilterby Rob Pike for go:https://github.com/robpike/filter
Notice how the author says "with as nice an API as I could manage". This "nice" API accepts any type, does type checks at runtime via slow reflection, and throws a panic if the types don't match. This is a programming best practice, like in JavaScript with
undefined is not a function.Staggering insight! Surely this statement isn't true for all 2-letter (and perhaps even 3- or 4-letter) strings, only this one specific 2-letter string, which also happens to be one of the most commonly used words in the English language.
Surely this won't mean everyone comes up with a longer name that is actually google-able
They are fans of short names.
The name Rust is also a bit of a misnomer: someone made a game with the same name, which leads to confusion. But sometimes it's fun, for example when someone asks why their FPS is low, you can clarify whether they added the
--releaseflag and whether they use.clone()on heavy objects.Fun fact, the game was named after the programming language primarily for the search engine confusion. The developers stated in an IGN interview in 2019, "knowing our game would be a hit, we chose the name to destabilize their search results, because if we couldn't be blazingly fast with zero cost abstractions and memory safety, nobody else should either."
This is a planned attack. Otherwise, how do you explain the fact that the Japanese named the city after one of the key libraries in Rust? They want to make it difficult to find, they want you to never know the truth.
TIL the Japanese named a city std
Let's be honest and admit that this is twice as good as 'C'.
It's just like how no problems could possibly occur from naming your Python package,
monty.go-oglable
and figure out they did! There is absolutely positivity no fundamental flaw in making these the same thing instead of different things!
Those silly Julia compiler devs could take a hint from Go! What with all their types like Vector, StridedArray, BitArray, SubArray, CartesianIndices, etc etc etc. Don't they realize it's all just arrays and slices?
They're still working on figuring out Array over a decade on while the good people working on Go only took a year!
Wow. That sounds great. I'm sold. There should be some kind of academic discipline which works on trying to find powerful, easy to understand, easy to use building blocks of programming languages from which you can compose a solution to your problem. One might call this "programming language theory". If there were such a thing, it might have profound ramifications for the effective design of software, and perhaps even inform the design of languages like Go.
Nice marketing slogan for Assembler.
You've misspelled Lisp
no but type systems are like a sortable list bro how haven't we figured this out yet
Can someone go back in time and invent this "programming language theory" before Rob Pike was forced to invent golang from scratch?
Boy it's a real shame that the first language to hit the ideal Pareto optimal performance-ergonomics tradeoff of AOT compiled plus garbage collected had to be this one
Delphi was a thing long ago.
What is Pareto optimal?
Strictly not worse than anything else when looking at all dimensions, e.g. Lua has arrays that start with the best number but Solidity lets you spend your entire net worth in one API call, so the set of two of them has two Pareto optimal elements if you like both off-by-one errors and being poor
Pareto optimal is when you've reached the point where it is impossible to make something/someone else better other than by making something/someone else worse.
Or, perhaps a bit more formally, all potential improvements that benefit at least one person/aspect without harming at least one person/aspect have already been made.
its ok we can put it to rest and use c# instead
Types? Hierarchies?? Formal Definitions??? Generics????
Preposterous! You WILL write
map[KeyType]struct{}and You WILL like it!It's really good that you mentioned
map.This is a "built-in" generic in the language. First, it directly contradicts what he claims in this post (which was written after the release of version 1.0):
Second, they obviously had no experience with other programming languages and didn't know how to write generics correctly, so they chose this stupid syntax:
map[string]intvsOtherType[string, int]. Now in a language where everything is supposedly done only in one way, there are two options for declaring local variables and two options for declaring generic type arguments.