4 ms·
Now that I get to use Go, I have no desire to go back to python. I think I'm not alone, and that python will soon enough become the new perl.
by pstuart 13y ago
Now that I get to use Go, I have no desire to go back to python. I think I'm not alone, and that python will soon enough become the new perl.
- lmm 13y agoPython was never the right answer for the cases Go solves (OCaml was a better choice 5-10 years ago, and nowadays there are plenty of options). But it's still the best language around for where you just need to write a one-off script as quickly as possible (in that sense it's always been the new perl).
- _delirium 13y agoFor a one-off script I still prefer Perl. But where I run into Python more is scientific computing. It seems to be making inroads into areas that previously would've only used Matlab. Haven't seen any Go in that area yet. Of the new entrants, Julia seems to be building buzz.
- clebio 13y agoe.g. Sage: http://sagemath.org/ http://sagemath.org/
- axaxs 13y agoPython should not directly compete with go. A sure sign of an inexperienced dev is "why I moved from Lang x to Lang y". You should use and know multiple languages, and know where they fit in. That said, for a lot of cases I think Go steps in where python comes up short, which is definitely performance and concurrency. But if I'm doing something that's too complicated to fit easily in a shell script, but doesn't warrant a lot of time, the brevity of python wins every time.
- ghshephard 13y agoSuggesting that python will soon enough become the new perl is high praise indeed. Perl runs a good portion of the internet, and is (and will likely for the next half century) be a very, very popular language. It's definitely the case that python was shoehorned into some places where it probably wasn't the best fit, but, at the time (1999-2001) was really the high-level dynamic language that had a lot of mindshare. A lot (almost all?) of companies that tried to use Zope as their application server back then would probably be looking at Java as their deployment platform today. Python sits in that nice "batteries included, easy to read, reasonably fast to write" space. I tend to write most of my scripts in Python, because a week later, I could never understand the perl code I wrote, but, for some reason, python code never had that problem for me. I don't expect too many people are writing quick "one-off" scripts in Go (I'd be interested to be proven wrong though), so perl/python/awk/bash all still have a place in people's toolkit.
- spamizbad 13y agoThe Python ecosystem is far too diversified to get knocked down by one language. Python has a wealth of production-quality libraries across a ton of domains (Web, scientific computing, data science, NLP, parsing, scripting/automating, etc). Go is a non-entity in most of these domains and isn't even a top-20 programming language on Github (source: http://sogrady-media.redmonk.com/sogrady/files/2013/07/programming-lang-rankings-june13.png http://sogrady-media.redmonk.com/sogrady/files/2013/07/progr...) Python went everywhere Perl did and then expanded the map for "scripting languages". This didn't happen by accident: Python is, by design, very easy comprehend and learn. The Python community also one of the most newbie-friendly around, with mountains of freely available resources for beginners. A programming language cannot be sustained by uber hackers, PLT nerds, and hipsters alone. You gotta make it reach the world (Like JavaScript, Java) or it'll never be"Tier 1" programming language. I have yet to see the Go's developer or community put forth a strategy to make this happen -- which is completely understandable given how new the language is.
- steveklabnik 13y agoThe scientific Python community will never leave 2.5 -> 2.7, though...
- takluyver 13y agoI'm hearing more rumblings about using 3.x now. Certainly people in this community aren't racing to switch, but I wouldn't say it will never happen.
- ajford 13y agoThe science community will get there. The problem is that for a long time, NumPy/SciPy/etc. didn't support 3.x. And when you're more interested in end results, why would you rewrite your code (or spend days/weeks/months relearning) when you could use a still perfectly acceptable and supported version? There's also a lot of reuse and expansion on existing code bases, which would involve a lot of work to migrate to 3.x. There's also the matter that on top of moving to 3.x, you also have the task of making sure there's no hidden bugs that may alter your results in ways you may not notice. A lot of scientific code has been repeatedly vetted to make sure that there's no bias or glitches that may skew your results. Hell, I know astronomers who are still using Fortran code that was written in the 80's. It still works (though now it requires a long build process, as it is no longer compatible with the latest Fortran compilers), so no reason to try to rewrite it just because the language is dated.