4 ms·

> Let me warn you. If you persist with your propaganda on Python3, then GOLANG will be the future of Python. Does that register with you guys? This abstract fu

> Let me warn you. If you persist with your propaganda on Python3, then GOLANG will be the future of Python. Does that register with you guys? This abstract future of Python has already been ceded to something that is not Python, just as once the abstract future of Perl was Python. Ruby once tried to take the mantle but failed. Go is now taking a lot of mindshare (from 2 or 3 more I wonder?) and I agree the Python 3 crowd just makes Go more likely to succeed, which is terrifying since it's probably the worst possible choice. My message is simply despair and accept the inevitable: Python will fade -- by all means keep using it, people still use Perl, scientist will be using it for a long time -- but the rest of the software world will pass you by. If you care about what the rest of the world is doing at all, you can help make sure the future passes to better general purpose high level languages like Nim or Clojure or OCaml, and for specific niches like scientific computing goes to the likes of Julia eventually. Anything but Go.

vegabook 11y ago
I'm currently registered on the Ocaml mooc ;-) Very intrigued by Nim too. Yes I find Golang to be dry and uninspiring, but as per one of my other comments, I get 20x the performance, and the concurrency model beats Asyncio hands down. Honestly I needed to get 360 gigabytes of JSON into Cassandra and Python was going to take 6 days (there is some light conditionality on each datapoint preventing a raw dump). I took 1.5 of those days to learn how to do it in Golang, started it at midday today, and estimate it'll be done when I get into work tomorrow morning. Sometimes I just need to get stuff done. EDIT: Just re-read your post and cannot help but agree that Python's demise is already telegraphed. History. Perl->Python->(?) is a nice analogy. Python won't die for sure, but it will not flourish like it did in the past decade. And yes I think it's good advice to look to more ambitious languages than Go, even if Go solves many "today" problems quite well. Personally wish Clojure would come off the JVM but am looking into Ocaml, Elixir, and when I need imperative, good ol' C wrapped up in Nim. All good candidates, though I really wish something would come up and go "fully vectorized" for the brave new world of GPUs. Personally need a REPL which is why Ocaml wins for now though Spark looks to me to be the "new R" for data science so I shouldn't exclude Scala (JVM notwithstanding). Decisions decisions...
- brachi 11y ago
  I wonder how much faster pypy would be in parsing 360 GB of data.
- oberstein 11y ago
  It will be interesting to see what the final winner of GPU programming looks like. There's also the possibility of FPGAs making their way into consumer hardware, and right now the pure-Python library MyHDL is a great choice for those. There are a few attempts at abstracting over OpenCL like https://github.com/eholk/harlan https://github.com/eholk/harlan, and some intriguing domain specific attempts like http://halide-lang.org/ http://halide-lang.org/ but I think it will be a while yet before something takes over. I also don't think whatever it is can succeed without corporate backing.
  - Nrpf 11y ago
    Python Numba compiler (fast as julia) has a fair amount of Cuda and AMD HSA capability.
- CuriouslyC 11y ago
  You're looking at this from the SV startup echo-chamber perspective. People use Python because the language gets out of the way fairly quickly to let you get things done fairly quickly. Sure, it isn't a rigorous engineering language, but the ratio of small projects that just need something good enough and easy to work with to large/complex projects requiring careful engineering is staggeringly large. While Python is definitely cooling off; people have been working with it for long enough to want something better - unfortunately there just isn't anything on the radar that is significantly enough better to overcome Python's third party library momentum at the moment. Believe me, I'd love a language with a really flexible/optional functional type system, better metaprogramming facilities, a better concurrency design, slightly more consistent syntax, etc - just as long as it is still easy to think in and convenient to use like Python.
  - dragonwriter 11y ago
    > Believe me, I'd love a language with a really flexible/optional functional type system, better metaprogramming facilities, a better concurrency design, slightly more consistent syntax, etc - just as long as it is still easy to think in and convenient to use like Python. As someone who, among dynamic languages, dismissed Perl quite a while back as not as useful as Python and Ruby, I'm starting to think Perl 6 may be the language that hits that spot.

vegabook 11y ago

I'm currently registered on the Ocaml mooc ;-) Very intrigued by Nim too. Yes I find Golang to be dry and uninspiring, but as per one of my other comments, I get 20x the performance, and the concurrency model beats Asyncio hands down. Honestly I needed to get 360 gigabytes of JSON into Cassandra and Python was going to take 6 days (there is some light conditionality on each datapoint preventing a raw dump). I took 1.5 of those days to learn how to do it in Golang, started it at midday today, and estimate it'll be done when I get into work tomorrow morning. Sometimes I just need to get stuff done. EDIT: Just re-read your post and cannot help but agree that Python's demise is already telegraphed. History. Perl->Python->(?) is a nice analogy. Python won't die for sure, but it will not flourish like it did in the past decade. And yes I think it's good advice to look to more ambitious languages than Go, even if Go solves many "today" problems quite well. Personally wish Clojure would come off the JVM but am looking into Ocaml, Elixir, and when I need imperative, good ol' C wrapped up in Nim. All good candidates, though I really wish something would come up and go "fully vectorized" for the brave new world of GPUs. Personally need a REPL which is why Ocaml wins for now though Spark looks to me to be the "new R" for data science so I shouldn't exclude Scala (JVM notwithstanding). Decisions decisions...

brachi 11y ago
I wonder how much faster pypy would be in parsing 360 GB of data.
oberstein 11y ago
It will be interesting to see what the final winner of GPU programming looks like. There's also the possibility of FPGAs making their way into consumer hardware, and right now the pure-Python library MyHDL is a great choice for those. There are a few attempts at abstracting over OpenCL like https://github.com/eholk/harlan https://github.com/eholk/harlan, and some intriguing domain specific attempts like http://halide-lang.org/ http://halide-lang.org/ but I think it will be a while yet before something takes over. I also don't think whatever it is can succeed without corporate backing.
- Nrpf 11y ago
  Python Numba compiler (fast as julia) has a fair amount of Cuda and AMD HSA capability.
CuriouslyC 11y ago
You're looking at this from the SV startup echo-chamber perspective. People use Python because the language gets out of the way fairly quickly to let you get things done fairly quickly. Sure, it isn't a rigorous engineering language, but the ratio of small projects that just need something good enough and easy to work with to large/complex projects requiring careful engineering is staggeringly large. While Python is definitely cooling off; people have been working with it for long enough to want something better - unfortunately there just isn't anything on the radar that is significantly enough better to overcome Python's third party library momentum at the moment. Believe me, I'd love a language with a really flexible/optional functional type system, better metaprogramming facilities, a better concurrency design, slightly more consistent syntax, etc - just as long as it is still easy to think in and convenient to use like Python.
- dragonwriter 11y ago
  > Believe me, I'd love a language with a really flexible/optional functional type system, better metaprogramming facilities, a better concurrency design, slightly more consistent syntax, etc - just as long as it is still easy to think in and convenient to use like Python. As someone who, among dynamic languages, dismissed Perl quite a while back as not as useful as Python and Ruby, I'm starting to think Perl 6 may be the language that hits that spot.