[kijin]

I don't think Perl will ever recover from the Perl 6 fiasco, and I'm worried for Python for the same reason.

PHP, on the other hand, handled the PHP 6 "failure" relatively gracefully. There was a bit of stagnation in the days of PHP 5.2 when the devs devoted too much energy to PHP 6 and not enough on improving the current version. But soon, PHP 6 was put on hold and some of its better parts began to be ported to PHP 5. Thanks to this decision, PHP has improved by leaps and bounds since 5.3. Also thanks to the lessons learned, nobody is particularly worried about any breaking changes in PHP for the foreseeable future. Everyone knows that any script that works in PHP 5.6 will probably work just fine in 7.0, so new projects continue to be written in PHP. This peace of mind is very important for languages that carry a lot of legacy baggage.

If there's anything for other languages to learn from PHP, it would be their graceful handling of PHP 6 -> 5.3~5.6. The syntax is still terrible, and the default behavior remains borderline insane, but PHP since 2009 has been an exemplar of how a widely used scripting language should handle new versions.

[McGlockenshire]

> Everyone knows that any script that works in PHP 5.6 will probably work just fine in 7.0

This is no longer strictly true. On Friday, the "let's remove all the deprecated stuff" RFC was passed. Anything that causes an E_DEPRECATED in 5.6 will now be a fatal in 7. For example, ext/ereg and ext/mysql are no longer included, and have been shipped off to PECL. Shouldn't be a problem for anyone that doesn't compile their own, really. A few php.ini settings are also now removed, which will fatal on startup.

It'll be safe to say that if your code runs fine under 5.6 with error_reporting set to -1, then you'll probably run under 7 without too much trouble.

[kijin]

You're right, any code that runs without errors in 5.6 will probably run fine in 7.0.

And that's exactly how deprecation is supposed to work! No massive changes, only incremental changes, and even those incremental changes come with at least a couple of years of grace period.

[ars]

> It'll be safe to say that if your code runs fine under 5.6 with error_reporting set to -1, then you'll probably run under 7 without too much trouble.

Not completely, ext/mysql does not output E_DEPRECATED. Although I guess installing a compatibility library is probably not all that much trouble.

[McGlockenshire]

Calling mysql_connect will cause an E_DEPRECATED. Same with mysql_pconnect.

Source: the manual page. http://php.net/mysql_connect

None of the other ext/mysql functions do so.

[pjmlp]

Python will be beaten by those caring about performance for writting applications instead of plain server scripts.

Those will migrate to Julia, Go, or something else.

I used Python a lot in the last decade (2000 - 2004) for automatation and little applications.

Nowadays my choice would be OCaml for the same type of tasks.

EDIT: typo, automatic => automatation

[andreasvc]

Those caring about performance are already using Python, in combination with extension modules written in C/Cython. You would have to complete your argument by explaining why they would rather switch to a completely new language without a huge (scientific) ecosystem of libraries, instead of writing more extension modules in the places where it really matters.

The appeal of a scripting language is that "automatation and little applications" do not take a lot of friction to write, I'd say OCaml is less suited in this regard.

[pjmlp]

As someone that cares about performance I don't use Python any longer, except on cases where customers require me to do so.

I don't need to convince others to join any kind of cause.

[andreasvc]

I don't follow. I am not talking about any kind of cause. However, you made a specific prediction, that "Python will be beaten", and I'm saying you haven't made a proper argument why that is so.

As someone who cares about performance I still use Python for the non-performance critical parts of code, which is the vast majority.

I'm pretty sure that in the end this is just a matter of personal preference, but you make it sound as if there are objective arguments without actually presenting them.

[pjmlp]

My line of thought while replying to the parent is that if a rewrite is needed, those that are more performance minded, are likely to use a language that doesn't suffer from GIL or a pure interpreter as canonical implementation.

Somehow you can already see it on the interwebs. The majority of Go and Julia users come from Python and Ruby, not from languages that have AOT/JIT compilers on their toolchains.[0]

This is just my gut feeling from almost 30 years watching similar technology transitions.

I have no data to back it up and may be completly wrong.

[0] There is PyPy, but I never saw it being deployed in production systems.

[jghf]

Numba + Blaze boosts numerical python to speeds on par with or greater than julia, with additional out of core, delayed expression and multiple backend capabilities that Julia currently does not have.

This might stem the tide for a while... Then we have pyston which maintains C api compatibility.

[pjmlp]

Are they written in Python?

[jghf]

Blaze is, Numba is a JIT compiler to LLVM. You can write numpy functions and JIT/Multithread them with just a decorator and zero to few code changes. Blaze makes this transparent to the user, chunks backends, provide out of core array object, abstract expressions etc.