4 ms·

> For one, Python remains immensely more popular than Golang. And it's worth looking at the reasons for that. Firstly, age is a factor - Python is much older.

> For one, Python remains immensely more popular than Golang. And it's worth looking at the reasons for that. Firstly, age is a factor - Python is much older. However, most Python growth has come from data science and machine learning fields. There is no reason Go can not grow the pie and make such fields more accessible to those with an interest in computing concurrently. And surely, if there is one field where concurrency might be a boom it might be data science and machine learning. Now, Go has some problems in that area: principally it does not have data structures as "friendly" as Python lists or NumPy arrays, and therefore people will have to jump through hoops. Could it get them? Yes. Would that be more powerful than generics? Absolutely. Will it get them? It's not obvious to me it will, other than through a third-party library which is fine. In fact Python's successes might not be Python's. They might be NumPy's and Pandas' successes. Go can have the same thing, and do it better.

coldtea 9y ago
>And it's worth looking at the reasons for that. Firstly, age is a factor - Python is much older. Those things are not very good indicators. Cobol and Lisp are even older, but not as popular. Perl is the same age, but has fallen sharply. Smalltalk is a decade plus older, but fell from grace in the mid-nineties. And so on...
- PaulRobinson 9y ago
  COBOL and Lisp are not _trendy_ but they are _hugely_ popular in certain fields. Interestingly the reason they have not blossomed into old age is because they have exactly the opposite reputations: Lisp is hard to create but elegant when you have it right, COBOL is hard to replace, and inelegant wherever it lives on. Perl was trendy but unmaintainable and often replaceable, so it was replaced. Smalltalk lives on mostly through its ideas manifesting themselves in Ruby. It is still popular in certain fields, particularly those where "minicomputers" once reigned: business critical 9-figure turnover manufacturing sort of businesses. Python has had longer to build traction, and so far has kept it - I'm arguing it might be about to pass.
Daishiman 9y ago
I think you underestimate just how important is Python's support for various numeric data types is for NumPy's, success. There is no possible equivalent in Go that would not look like a horrendous mishmash of various different functions to declare all the different numeric types and various forms of matrix slicing and traversal operators.
- PaulRobinson 9y ago
  Go does not support multi-dimensional slices, and that is a problem. I am not sure the numeric data types thing is such an issue. Python supports int, float, long and complex types. So does Go, with the slight annoyance you have to care a little more about the size of your number, and so you don't just label something 'long' and walk away safe in the knowledge it's kinda big. Numpy just makes Go's numeric data types available. The clever thing it does that Go does not is around arrays and operations on them - something we need to consider in Go land, carefully. The other stuff Numpy and Pandas makes available could be made available in Go, too and could abstract away the horrible stuff under the hood where you're resizing slices and creating multidimensional versions. I think the moment multi-dimensional slices are available, you can do everything you want, and with concurrency and therefore able to trivially exploit multi-core systems - that could be the killer feature. Maybe.
deleted 9y ago
[deleted]

coldtea 9y ago

>And it's worth looking at the reasons for that. Firstly, age is a factor - Python is much older. Those things are not very good indicators. Cobol and Lisp are even older, but not as popular. Perl is the same age, but has fallen sharply. Smalltalk is a decade plus older, but fell from grace in the mid-nineties. And so on...

PaulRobinson 9y ago
COBOL and Lisp are not _trendy_ but they are _hugely_ popular in certain fields. Interestingly the reason they have not blossomed into old age is because they have exactly the opposite reputations: Lisp is hard to create but elegant when you have it right, COBOL is hard to replace, and inelegant wherever it lives on. Perl was trendy but unmaintainable and often replaceable, so it was replaced. Smalltalk lives on mostly through its ideas manifesting themselves in Ruby. It is still popular in certain fields, particularly those where "minicomputers" once reigned: business critical 9-figure turnover manufacturing sort of businesses. Python has had longer to build traction, and so far has kept it - I'm arguing it might be about to pass.

Daishiman 9y ago

I think you underestimate just how important is Python's support for various numeric data types is for NumPy's, success. There is no possible equivalent in Go that would not look like a horrendous mishmash of various different functions to declare all the different numeric types and various forms of matrix slicing and traversal operators.

PaulRobinson 9y ago
Go does not support multi-dimensional slices, and that is a problem. I am not sure the numeric data types thing is such an issue. Python supports int, float, long and complex types. So does Go, with the slight annoyance you have to care a little more about the size of your number, and so you don't just label something 'long' and walk away safe in the knowledge it's kinda big. Numpy just makes Go's numeric data types available. The clever thing it does that Go does not is around arrays and operations on them - something we need to consider in Go land, carefully. The other stuff Numpy and Pandas makes available could be made available in Go, too and could abstract away the horrible stuff under the hood where you're resizing slices and creating multidimensional versions. I think the moment multi-dimensional slices are available, you can do everything you want, and with concurrency and therefore able to trivially exploit multi-core systems - that could be the killer feature. Maybe.

deleted 9y ago

[deleted]