7 ms·

Here’s a quote from Rob Pike (in 2015) about what Go was trying to avoid: "Java, JavaScript (ECMAScript), Typescript, C#, C++, Hack (PHP), and more [...] activ

by pansa2 6y ago

Here’s a quote from Rob Pike (in 2015) about what Go was trying to avoid: "Java, JavaScript (ECMAScript), Typescript, C#, C++, Hack (PHP), and more [...] actively borrow features from one another. They are converging into a single huge language." https://www.dotconferences.com/2015/11/rob-pike-simplicity-is-complicated https://www.dotconferences.com/2015/11/rob-pike-simplicity-i...

nerdponx 6y ago
It's 2021, the convergence still hasn't happened yet. It's never going to happen. I know Rob Pike is probably smarter than me, but this a bad hot take in 2015, and it's outright stinky in 2021.
- ozkatz 6y ago
  6 years is not a lot of time if you examine the progress of modern programming languages. These languages are more similar to one another than they were 6 years ago. I don't know if it was meant to be taken literally, but I definitely don't think it's "outright stinky" to claim convergence.
- Thaxll 6y ago
  Well look at patern matching for example, they're all adding that. Isn't that convergence? https://www.php.net/manual/en/control-structures.match.php https://www.php.net/manual/en/control-structures.match.php https://www.python.org/dev/peps/pep-0622/ https://www.python.org/dev/peps/pep-0622/ https://www.infoq.com/articles/java-pattern-matching/ https://www.infoq.com/articles/java-pattern-matching/ https://docs.microsoft.com/en-us/archive/msdn-magazine/2019/may/csharp-8-0-pattern-matching-in-csharp-8-0 https://docs.microsoft.com/en-us/archive/msdn-magazine/2019/... I could go on with various topics, immutability etc ... It's pretty clear that in the past 10 years language evolved more quickly and borrow concepts from other languages.
  - nerdponx 6y ago
    Languages evolving and borrowing good ideas from each other* is not the same thing as hyperbolically sneering at some of the most popular programming languages in the world because they're supposedly all converging into one single language, which they never were doing and never will do. *Note that the new Python pattern matching has a somewhat controversial design, and it probably won't see significant adoption in the wild for several years, if ever.
    - avaldeso 6y ago
      > Languages evolving and borrowing good ideas from each other* is not the same thing as hyperbolically sneering at some of the most popular programming languages in the world because they're supposedly all converging into one single language, which they never were doing and never will do. And yet PHP, Java and C# MVC web apps looks all the same in both syntax and structure. Same syntax for interfaces, classes, namespaces, entity models, query builders, controllers, views and so on. A modern Symfony application looks almost the same as a Spring one.
- cratermoon 6y ago
  They are all similar enough that a programmer fluent in one can start writing code in the style they are familiar with in another. Remember the old saying, "You can write FORTRAN in any language[1]"? Well, with the aforementioned set of languages, you can write one of them in another and it doesn't even look wrong. [1] https://blog.codinghorror.com/you-can-write-fortran-in-any-language/ https://blog.codinghorror.com/you-can-write-fortran-in-any-l...
  - nerdponx 6y ago
    They are all similar enough that a programmer fluent in one can start writing code in the style they are familiar with in another ... with the aforementioned set of languages, you can write one of them in another and it doesn't even look wrong. 1. Only superficially, because they all share the same basic flow-control constructs and (except for Python) the same C-inspired syntax. They all have totally different standard libraries, package ecosystems, etc. 2. I don't see what makes Go exempt, other than "wow great they didn't add generics bless the Go core team."
    - cratermoon 6y ago
      Go was built as a language to make communicating sequential processes[1] first-class citizens. Thus the ubiquity of channels and goroutines. No locks, no condition variables, no callbacks[2]. Writing a bunch of code using locks and callbacks in Go goes against the grain of the language. [1]https://www.cs.cmu.edu/~crary/819-f09/Hoare78.pdf https://www.cs.cmu.edu/~crary/819-f09/Hoare78.pdf [2]https://www.youtube.com/watch?v=f6kdp27TYZs https://www.youtube.com/watch?v=f6kdp27TYZs
thomascgalvin 6y ago
That's not entirely a bad thing. We've learned a lot about language ergonomics in the past forty-nine years. Generics are super useful. Lambdas and streams can cut down on a lot of boilerplate. Immutables make code easier to reason about. And I'm glad that I have access to all of those things in Java. I'm not upset that my workday language is being polluted by outside influences, because I'm not a purist, I'm a programmer. I don't care that records were lifted from Scala and Kotlin ... I care about how they can make my code better. The idea that we should deprive ourselves of useful features because it makes languages too similar makes no sense to me.
- heyparkerj 6y ago
  You should watch the talk - I actually happened to do so yesterday so it's still in my mind. The point is not that they're withholding features because it makes the language too similar to others, and I'm sure that's not what you were really thinking the argument is either. The thing they're trying to focus on is that with ever increasing amount of features, you have an ever increasing amount of complexity added, which has implications on the amount of conversations, decisions, readability and difficulty your team is going to have when tackling any given problem. It can really just be boiled down to increasing features past what is needed can be considered bloat, which does not come free to a developer or team's collective consciousness. To quote/paraphrase from the 5:10 mark of his talk... "If a language has too many features, or even more than you might need, you spend time programming thinking about which features to use... you might even spend half an hour messing with a few lines of code to [see how a given feature fits into the solution]... [and even more, when you revisit that code, you have to get back into the thought process you initially went through when determining which features to use]."
  - thomascgalvin 6y ago
    That's certainly fair. I was just talking to someone about how it used to be possible to hold the entire Java ecosystem in your head at once, but that was probably 15 years ago. On the other hand, adding language complexity can decrease program complexity a great deal. Generics are the prime example of this. If you see List<Foo> and List<Bar>, you know exactly how both work. But if you see FooList and BarList, you might have to stop and worry about how each is individually implemented. Or the whole "while is spelled for in Go" thing. Sure, they managed to strike out one whole keyword from their language, but anyone coming from another language is going to have a momentary brain skip while they try to figure out why that is, and how they need to re-write their while loop as a for-loop-but-not.
jayd16 6y ago
Or you could see that languages have use cases, use cases overlap, languages should adopt useful tools for their use cases, therefore languages will often adopt the same tools as other languages with overlapping use cases.

by pansa2 6y ago

nerdponx 6y ago

It's 2021, the convergence still hasn't happened yet. It's never going to happen. I know Rob Pike is probably smarter than me, but this a bad hot take in 2015, and it's outright stinky in 2021.

ozkatz 6y ago
6 years is not a lot of time if you examine the progress of modern programming languages. These languages are more similar to one another than they were 6 years ago. I don't know if it was meant to be taken literally, but I definitely don't think it's "outright stinky" to claim convergence.
Thaxll 6y ago
Well look at patern matching for example, they're all adding that. Isn't that convergence? https://www.php.net/manual/en/control-structures.match.php https://www.php.net/manual/en/control-structures.match.php https://www.python.org/dev/peps/pep-0622/ https://www.python.org/dev/peps/pep-0622/ https://www.infoq.com/articles/java-pattern-matching/ https://www.infoq.com/articles/java-pattern-matching/ https://docs.microsoft.com/en-us/archive/msdn-magazine/2019/may/csharp-8-0-pattern-matching-in-csharp-8-0 https://docs.microsoft.com/en-us/archive/msdn-magazine/2019/... I could go on with various topics, immutability etc ... It's pretty clear that in the past 10 years language evolved more quickly and borrow concepts from other languages.
- nerdponx 6y ago
  Languages evolving and borrowing good ideas from each other* is not the same thing as hyperbolically sneering at some of the most popular programming languages in the world because they're supposedly all converging into one single language, which they never were doing and never will do. *Note that the new Python pattern matching has a somewhat controversial design, and it probably won't see significant adoption in the wild for several years, if ever.
  - avaldeso 6y ago
    > Languages evolving and borrowing good ideas from each other* is not the same thing as hyperbolically sneering at some of the most popular programming languages in the world because they're supposedly all converging into one single language, which they never were doing and never will do. And yet PHP, Java and C# MVC web apps looks all the same in both syntax and structure. Same syntax for interfaces, classes, namespaces, entity models, query builders, controllers, views and so on. A modern Symfony application looks almost the same as a Spring one.
cratermoon 6y ago
They are all similar enough that a programmer fluent in one can start writing code in the style they are familiar with in another. Remember the old saying, "You can write FORTRAN in any language[1]"? Well, with the aforementioned set of languages, you can write one of them in another and it doesn't even look wrong. [1] https://blog.codinghorror.com/you-can-write-fortran-in-any-language/ https://blog.codinghorror.com/you-can-write-fortran-in-any-l...
- nerdponx 6y ago
  They are all similar enough that a programmer fluent in one can start writing code in the style they are familiar with in another ... with the aforementioned set of languages, you can write one of them in another and it doesn't even look wrong. 1. Only superficially, because they all share the same basic flow-control constructs and (except for Python) the same C-inspired syntax. They all have totally different standard libraries, package ecosystems, etc. 2. I don't see what makes Go exempt, other than "wow great they didn't add generics bless the Go core team."
  - cratermoon 6y ago
    Go was built as a language to make communicating sequential processes[1] first-class citizens. Thus the ubiquity of channels and goroutines. No locks, no condition variables, no callbacks[2]. Writing a bunch of code using locks and callbacks in Go goes against the grain of the language. [1]https://www.cs.cmu.edu/~crary/819-f09/Hoare78.pdf https://www.cs.cmu.edu/~crary/819-f09/Hoare78.pdf [2]https://www.youtube.com/watch?v=f6kdp27TYZs https://www.youtube.com/watch?v=f6kdp27TYZs

thomascgalvin 6y ago

That's not entirely a bad thing. We've learned a lot about language ergonomics in the past forty-nine years. Generics are super useful. Lambdas and streams can cut down on a lot of boilerplate. Immutables make code easier to reason about. And I'm glad that I have access to all of those things in Java. I'm not upset that my workday language is being polluted by outside influences, because I'm not a purist, I'm a programmer. I don't care that records were lifted from Scala and Kotlin ... I care about how they can make my code better. The idea that we should deprive ourselves of useful features because it makes languages too similar makes no sense to me.

heyparkerj 6y ago
You should watch the talk - I actually happened to do so yesterday so it's still in my mind. The point is not that they're withholding features because it makes the language too similar to others, and I'm sure that's not what you were really thinking the argument is either. The thing they're trying to focus on is that with ever increasing amount of features, you have an ever increasing amount of complexity added, which has implications on the amount of conversations, decisions, readability and difficulty your team is going to have when tackling any given problem. It can really just be boiled down to increasing features past what is needed can be considered bloat, which does not come free to a developer or team's collective consciousness. To quote/paraphrase from the 5:10 mark of his talk... "If a language has too many features, or even more than you might need, you spend time programming thinking about which features to use... you might even spend half an hour messing with a few lines of code to [see how a given feature fits into the solution]... [and even more, when you revisit that code, you have to get back into the thought process you initially went through when determining which features to use]."
- thomascgalvin 6y ago
  That's certainly fair. I was just talking to someone about how it used to be possible to hold the entire Java ecosystem in your head at once, but that was probably 15 years ago. On the other hand, adding language complexity can decrease program complexity a great deal. Generics are the prime example of this. If you see List<Foo> and List<Bar>, you know exactly how both work. But if you see FooList and BarList, you might have to stop and worry about how each is individually implemented. Or the whole "while is spelled for in Go" thing. Sure, they managed to strike out one whole keyword from their language, but anyone coming from another language is going to have a momentary brain skip while they try to figure out why that is, and how they need to re-write their while loop as a for-loop-but-not.

jayd16 6y ago

Or you could see that languages have use cases, use cases overlap, languages should adopt useful tools for their use cases, therefore languages will often adopt the same tools as other languages with overlapping use cases.