(1) Google spent lots of developer resources on Unladen Swallow, which ended up not giving the speed increases they expected, but that's another story.

(2) Last thing I heard, Google's trying to minimize their Python usage in favor of Java.

Re #2, I heard ~November that Python was deprecated in production at Google. No idea what the details/caveats on that are (I presume it applies mainly to new code?).

Thanks for mentioning that--I'd never heard of that before. (Although it's not like I'm in danger of getting a job there. :)

This is something that I see at many places these days. Scripting has become synonymous with Perl. And for anything else People are really going in for Java.

But Django and Rails seem to be the major reasons why people continue to use Python.

Having said that no company that is making billions in profits is going to bet their very survival on a framework written and maintained by volunteers. Frameworks come and go, Every 5 years there is something new.

"Scripting has become synonymous with Perl."

This is a remarkable claim. Well beyond what the most dedicated perl enthusiast could make with a straight face.

Do you have any supporting data or evidence to back it up?

I have hardly seen any shop so far, at least in the most big/medium corporates who use Python or Ruby heavily in scripting. Its either bash or Perl. The problem is as I said, Neither Ruby or Python were every marketed, designed or even took off as a Scripting languages. Most start ups pick up Python/Ruby basically because they don't need a new language with their existing Django/Rails code base.

Even in such cases one you infrastructure begins to expand, one you are a reasonably sized team. Perl usage becomes inevitable.

Even among the heavy Python using companies like Google, its becoming clear why anybody would not use Python or even deprecate it in production. Because it doesn't quite really have a strong dedicated niche. Php has the web, Perl has the scripting/glue part on the Unix environment. Java has the static large app part.

Python/Ruby have great web development frameworks.But when it comes to scripting, there are no real alternatives to Perl. And besides if you wish to develop large applications, Static languages serve well. There is no point in using Python when you don't want to cook things quickly.

You will be shocked how many places apart from web communities and forums like these people haven't even heard of Ruby and Python. Most of my friends in big companies some of who also lead big teams over the years 'have just had a look at Python'.

I realize that I have posted this in a community that likes Python a lot and I'm likely to be downvoted. But I'm writing just what I've seen over time.

I never trust anyone who uses the designation "scripting language" let alone those who use it with a capital 'S '. There is absolutely no formal definition of this and it's been repeatedly picked apart such that I don't even have to do it here.

Regarding your other comments they seem to be way off base and just using your personal bubble/ "what I've seen over time". Ruby and Python have crushed Perl in modern web development (Twitter and Reddit come to mind among many others). Python has vast user communities in research and science (including computer science teaching now, MIT, Stanford). Perl might be before Ruby in the pack behind R/Matlab/Mathmatica/Python in some research settings, but that's not saying much. Python additionally is the chosen admin utility language of Red Hat and Ubuntu for their Linux distributions, so it seems there are real alternatives to Perl.

I'm not saying Perl is bad, I am just saying objectively it's been in decline since the 1990s against its rising competitors in all areas: universities, other research, Linux systems administration, application development and web development.

AFAIK, Unladen was a 20% project for a couple (less than 5) Googlers, running without any corporate support beyond the 20% system.

I'd guess that C++, Java and NIH are all powerful forces at Google.

Given that Google hired Guido Van Rossum and that python is one of the three (and up until very recently two) supported languages for GAE, I think we can safely assume the Google isn't entirely anti python.

> I think we can safely assume the Google isn't entirely anti python.

I don't suggest otherwise. It's known that Python is one of Google's three languages approved for internal use (or apparently four now that JS has got a foothold). But I'm sure I've seen reports that people are nonetheless being pushed towards Google's other two officially blessed languages, at least on production code - and in fairness, Google is a place where developer time is often cheaper than the machine time you have to spend to save developer time. But moveover it seems that, even when people in Google do want to fix their Python performance issues by making Python perform better rather than by reducing its use, they tend to want to do it in-house rather than by adopting or supporting other people's work: look at Unladen Swallow. That would be in line with the rather hubristic, command-economy approach - "let's hire all the world's smartest people, then order them to build the future" - that seems to determine Google's actions in general. Hiring GvR fits that pattern too (as well as making plenty of sense).

But I'm sure other people here are much better informed about this than I am.

The problem is python never took off as a scripting language. In spirit it was a great language to develop applications in.

This creates a dilemma for a lot of people while choosing a technology. If you have to choose a language where you don't want to develop stuff quickly. Then you now have sufficient time to choose a static language and then develop stuff at the speed desired.

For other quick stuff there is Perl anyway.And it doesn't make sense to use Python, which is slow(compared to java), which doesn't give quick development cycle(compared to perl).

If you wish to relevant for a long time, then you have to do at least one thing properly.

Historically, Sun hired John Ousterhout and that didn't turn out terribly well for TCL backing by Sun.

Fair point. Or for a more recent example, Microsoft hiring Simon Peyton-Jones and yet showing no interest in actually using Haskell for anything.

Well IIRC, he's employed by Microsoft Research, which is not really the same as Microsoft proper. And they have used some concepts that are core to Haskell, such as LINQ being a monad, and F# is definitely related (though I don't know if that's an official Microsoft language).

* (though I don't know if that's an official Microsoft language)*

It is. When you launch Visual Studio >= 2010 it's there alongside C# in the Project Creation wizard.

I think F# is largely based on OCaml. I'm not sure what'd make a language official; MS does the development work on it, so I guess that'd be a yes on officialdom?

To be more precise, F# is based on the non-OO parts of Caml, with a completely different object system so it would be be compatible with .Net objects from other languages such as C#.

IIRC, the original research was going to be into making Haskell for .Net, but there were enough issues (in particular, being purely functional makes interop with C# and the existing .Net libraries radically more difficult) that ML seemed like a better fit.

Ah, thanks. I was going on a vague memory of something read a while back. I wasn't entirely wrong - 40% maybe - so that's nice.

Sure it is, it is even listed on the official Visual Studio page:

http://msdn.microsoft.com/en-us/vstudio/hh388569

Microsoft also sponsors Haskell and OCaml research via Microsoft Research centers.

Companies spend money on things that bring them profits or enable making profits.

Java and C# helped their companies do that.

But with Python,Tcl and Haskell its a little different. Its good for the companies if they off, but if they don't they don't loose anything.

PyPy's memory usage up until now has been quite a bit higher, which makes it unsuitable for some server workloads.

Still, I assume this is fixable, and it's getting more and more competitive in terms of the megabyte-second cost of computation (i.e. if you use twice as much memory but run four times as fast, that can be OK depending on the circumstances).