8 ms·

Revolutionary technology right here lads. This is what happens when you ignore the entire history of programming languages and all the lessons learned along the

Revolutionary technology right here lads. This is what happens when you ignore the entire history of programming languages and all the lessons learned along the way. You end up with a proposal to add type parameters, 8 or so years after its release.

ghthor 6y ago
Thanks for you contribution.
valenterry 6y ago
True
Cthulhu_ 6y ago
Java took 8 or so years to add generics to its language, what's your point? They explicitly did NOT ignore the history of programming languages, and resisted the urge of adding generics without fully understanding the problem that it was trying to solve (in the context of Go). See also: https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics There's a trend going on in the past decade or so where every language goes to adopt features from other languages, adding complexity without actually solving a problem other than "I use this feature in language X, why doesn't YOUR language have it?" Which lead to pretty shitty decisions, like half implementations of OOP in PHP and Javascript (have some classes, but not access modifiers), functional programming in Java, or every paradigm ever invented all at the same time in Scala.
- hajile 6y ago
  > They explicitly did NOT ignore the history of programming languages, and resisted the urge of adding generics without fully understanding the problem that it was trying to solve (in the context of Go). See also: https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics That's simply not true. Languages like StandardML, Ocaml, or Haskell have already solved the major issues 40 years ago with types vastly superior to what go offers. Since then, nothing has come even close to that level of utility and usability. Like so many other things in go, it seems a combination of Hubris and NIH syndrome.
  - amscanne 6y ago
    Just to get your argument straight: nothing comes close to the level of utility and usability of StandardML, Ocaml and Haskell? So why haven’t aren’t those languages commonly used? The simple answer is that there’s a lot more to a language than its type system. Go is popular because it’s simple. Throwing generics on the language without a lot of deep thought and time risks adding marginal utility while destroying a large amount of the core simplicity. While I too want generics, I understand that the caution and skepticism of the core team is not “Hubris and NIH”.
    - tome 6y ago
      > Just to get your argument straight: nothing comes close to the level of utility and usability of StandardML, Ocaml and Haskell? I suspect hajile meant that no type system comes close to the utility of that of StandardML, Ocaml and Haskell, not language in general.
    - hajile 6y ago
      I was specifically talking about types. Java or C# decide null is bad and try very hard to add Option and non-nullables, but go's creators just decide they must not have a good reason, so nulls everywhere. The potential problem of things like empty interface escaping the type system are well known, but go's creators decided that everyone else's experience here didn't really matter, so you get not only empty interface, but it becomes the only way to do certain things because of the lack of generics. Speaking of generics, every popular multi-use language winds up building in generics or tacking them on later. Go's creators denounce all other solutions as lacking. What makes them think they are so incredibly special that they don't need to learn from the experience of others? It seems to me that the only reasons are basically ignorance or arrogance and I don't think they are ignorant. > So why haven’t aren’t those languages commonly used? Languages don't generally survive without a big corporation paying the bills. If Google had chosen to put their hundreds of millions into SML instead of golang, the world would be a very different place. The first company to give such a language a chance was Mozilla with Rust and we can see how popular it has become. You could view Rust as SML with c-like syntax, lifetimes, unsafe options, no GC, extra pointer complexity, macros, etc. A bit more potential power at the cost of orders of magnitude more complexity due to being targeted at a different, lower-level problem set. > Just to get your argument straight: nothing comes close to the level of utility and usability of StandardML, Ocaml and Haskell? I would argue that SML is the best of those three languages and the most comparable to go as well. It's designed to be pragmatic, easy for first-year students to learn, and easy for later students to implement in compiler classes. Go's headline feature (goroutines aka channels) have been implemented in PolyML or CML a decade or two before go existed and they did it in a type safe manner. Go has multi-value returns, but all that means is that it has partial tuple support unlike SML which has both tuples and pattern matching. Despite what you might think you know from Haskell, SML allows mutation complete with safe (and type safe) pointers. Rather than interfaces, SML has structural typing which allows most of the same features, but with type safety and generics. There's also sum types (basically union types) which are easy to use with pattern matching and guarantee that all union types are handled safely. Unlike go with nulls everywhere that must be checked at your own peril, SML uses option types and nothing is ever null. All of that said, I don't hate go. I believe the language could keep its existing syntax while adding most if not all of these features and retaining a decent amount of backward compatibility and making code both more terse and more readable. It could solve its generics issue while also solving its other type problems and potentially picking up extra performance on the way.
- valenterry 6y ago
  The problem is that languages are difficult to change later. Once your language is designed, it becomes hard to change it. You can see that with Java that has half baked generics, horrible primitive types, strange collections, null and so on. I believe, that for new languages there are only two choices: 1. Build a simple language and don't implement generics _forever_. That is fine! Just stick with it. 2. Build generics into the language from the beginning and do it right. If that's too hard for you, then don't create a language in the beginning. Creating programming languages is damn hard. Amateurs will just fail.

ghthor 6y ago

Thanks for you contribution.

valenterry 6y ago

True

Cthulhu_ 6y ago

Java took 8 or so years to add generics to its language, what's your point? They explicitly did NOT ignore the history of programming languages, and resisted the urge of adding generics without fully understanding the problem that it was trying to solve (in the context of Go). See also: https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics There's a trend going on in the past decade or so where every language goes to adopt features from other languages, adding complexity without actually solving a problem other than "I use this feature in language X, why doesn't YOUR language have it?" Which lead to pretty shitty decisions, like half implementations of OOP in PHP and Javascript (have some classes, but not access modifiers), functional programming in Java, or every paradigm ever invented all at the same time in Scala.

hajile 6y ago
> They explicitly did NOT ignore the history of programming languages, and resisted the urge of adding generics without fully understanding the problem that it was trying to solve (in the context of Go). See also: https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics That's simply not true. Languages like StandardML, Ocaml, or Haskell have already solved the major issues 40 years ago with types vastly superior to what go offers. Since then, nothing has come even close to that level of utility and usability. Like so many other things in go, it seems a combination of Hubris and NIH syndrome.
- amscanne 6y ago
  Just to get your argument straight: nothing comes close to the level of utility and usability of StandardML, Ocaml and Haskell? So why haven’t aren’t those languages commonly used? The simple answer is that there’s a lot more to a language than its type system. Go is popular because it’s simple. Throwing generics on the language without a lot of deep thought and time risks adding marginal utility while destroying a large amount of the core simplicity. While I too want generics, I understand that the caution and skepticism of the core team is not “Hubris and NIH”.
  - tome 6y ago
    > Just to get your argument straight: nothing comes close to the level of utility and usability of StandardML, Ocaml and Haskell? I suspect hajile meant that no type system comes close to the utility of that of StandardML, Ocaml and Haskell, not language in general.
  - hajile 6y ago
    I was specifically talking about types. Java or C# decide null is bad and try very hard to add Option and non-nullables, but go's creators just decide they must not have a good reason, so nulls everywhere. The potential problem of things like empty interface escaping the type system are well known, but go's creators decided that everyone else's experience here didn't really matter, so you get not only empty interface, but it becomes the only way to do certain things because of the lack of generics. Speaking of generics, every popular multi-use language winds up building in generics or tacking them on later. Go's creators denounce all other solutions as lacking. What makes them think they are so incredibly special that they don't need to learn from the experience of others? It seems to me that the only reasons are basically ignorance or arrogance and I don't think they are ignorant. > So why haven’t aren’t those languages commonly used? Languages don't generally survive without a big corporation paying the bills. If Google had chosen to put their hundreds of millions into SML instead of golang, the world would be a very different place. The first company to give such a language a chance was Mozilla with Rust and we can see how popular it has become. You could view Rust as SML with c-like syntax, lifetimes, unsafe options, no GC, extra pointer complexity, macros, etc. A bit more potential power at the cost of orders of magnitude more complexity due to being targeted at a different, lower-level problem set. > Just to get your argument straight: nothing comes close to the level of utility and usability of StandardML, Ocaml and Haskell? I would argue that SML is the best of those three languages and the most comparable to go as well. It's designed to be pragmatic, easy for first-year students to learn, and easy for later students to implement in compiler classes. Go's headline feature (goroutines aka channels) have been implemented in PolyML or CML a decade or two before go existed and they did it in a type safe manner. Go has multi-value returns, but all that means is that it has partial tuple support unlike SML which has both tuples and pattern matching. Despite what you might think you know from Haskell, SML allows mutation complete with safe (and type safe) pointers. Rather than interfaces, SML has structural typing which allows most of the same features, but with type safety and generics. There's also sum types (basically union types) which are easy to use with pattern matching and guarantee that all union types are handled safely. Unlike go with nulls everywhere that must be checked at your own peril, SML uses option types and nothing is ever null. All of that said, I don't hate go. I believe the language could keep its existing syntax while adding most if not all of these features and retaining a decent amount of backward compatibility and making code both more terse and more readable. It could solve its generics issue while also solving its other type problems and potentially picking up extra performance on the way.
valenterry 6y ago
The problem is that languages are difficult to change later. Once your language is designed, it becomes hard to change it. You can see that with Java that has half baked generics, horrible primitive types, strange collections, null and so on. I believe, that for new languages there are only two choices: 1. Build a simple language and don't implement generics _forever_. That is fine! Just stick with it. 2. Build generics into the language from the beginning and do it right. If that's too hard for you, then don't create a language in the beginning. Creating programming languages is damn hard. Amateurs will just fail.