Dropbox Announces Their Own Open-Source Python

[quasipedia]

The Dropbox desktop client is also written in Python.

Yes and no. Yes from a literal point of view (the glue code written by Dropbox programmers that puts together the widget toolkit and the syncronisation is indeed in python), no from a substantial point of view: file synchronisation (which is the only functionality provided by the service, and the only "computational heavy" part of it, relying on delta uploads, i.e. hashing functions) is written in C [I believe is the standard rsync library]. So the point of python forcing end users to upgrade their machines is still moot (as a proof, Dropbox is running just fine on a Raspberry Pi).

The bottom line is that - bar specific problem domains such as the need to process real-time large quantities of data, or the need to run on limited resources such as an embedded system - choosing a language on the basis of its performance advantages is akin to premature optimisation.

[shaurz]

Which is not the case of Dropbox, that is using python on their servers. Anything else?

The Dropbox desktop client is also written in Python.

[quasipedia]

If you are developing an app for end users then you have to count the machine cost for all users.

Which is not the case of Dropbox, that is using python on their servers. Anything else?

[TheBlackCat]

The problem is that this false statement has become a culture. It's false because machine cost is higher than human cost. This statement is true if you are building an app to run on a few machines only, but if you are developing an app for end users then you have to count the machine cost for all users. If an app is to be used by a million users, and only 0.1% of those need to upgrade their machines because of this app then you are looking at a total cost close to half a million dollars.

What makes you think the problem is with the python front-end code? They don't say that anywhere in the blog post.

[profoundWHALE]

No, they target completely different stuff.

This. Python is often used for front ends, while Go is more often used as the backend.

[sarmad]

machine cost = low. Human cost = high

The problem is that this false statement has become a culture. It's false because machine cost is higher than human cost. This statement is true if you are building an app to run on a few machines only, but if you are developing an app for end users then you have to count the machine cost for all users. If an app is to be used by a million users, and only 0.1% of those need to upgrade their machines because of this app then you are looking at a total cost close to half a million dollars.

[quasipedia]

Those are the successful examples, what about the other hundreds of projects that never got the financial success needed to write a new compiler? What about the other example where the company got more successful than Facebook and have their own language and compiler team already and still couldn't improve the situation because it has gone beyond fixable (Microsoft)? But hey, let's pick a language that trades performance for quick delivery and leave it up to the users to replace their machines for faster machines.

First, machine cost = low. Human cost = high. If a company did not achieve financial success through a language that shifted costs towards the machine end of the spectrum, they would only have failed more rapidly if they picked a highly efficient, error-prone, difficult to debug language. There's a reason why organisations like Google, Gnome or Mozilla all developed new languages (Go, Vala, Rust respectively) for moving costs onto machines.

Second. To the best of my knowledge none of Dropbox clients is in Python (they are compiled binaries, not PYC files, at least on my machine), so your remark on requiring users to upgrade their machines is just irrelevant.

Third. I hate Microsoft, yet... what's wrong with their .NET platform? What are you referring to with "beyond fixable"? If it weren't for the proprietary licences, I would swap C# for PHP any day...

[sarmad]

Once again, a team picks up a language that allows them to deliver quickly and well, and being able to do so they outperform their competition and establish them as the market leader, to the point they actually can dedicate time and money to contribute back to the language community with a new interpreter... I think this story is pretty similar to that of that other little site you may have come across time to time... what was called? Ah, yes.... Facebook!

Those are the successful examples, what about the other hundreds of projects that never got the financial success needed to write a new compiler? What about the other example where the company got more successful than Facebook and have their own language and compiler team already and still couldn't improve the situation because it has gone beyond fixable (Microsoft)? But hey, let's pick a language that trades performance for quick delivery and leave it up to the users to replace their machines for faster machines.

[gilboa]

To be honest, the OP to me seemed more genuinely clueless about what he was talking about, than trolling. But yeah... I was surprised too by the amount of replies he got!

Let me try too: C is dead, C is dead!!! Whoever uses C nowadays is stupid, PHP is sooooo much better!!!

I may have missed some "<sarcasm>" tag somewhere, but the huge amount of actively maintained C code seems to suggest other wise.

... and good luck writing high performance user/kernel code in PHP...

- Gilboa

[shaurz]

I use python for a lot of small tools and batch scripts at work. We are a c++ shop, but use python for "scripty things" and build/content management. Neither go or js are hardly alternatives there. Not that I do any heavy lifting in python, but it is excellent in orchestrating the tools that do. Python is king at string management and "batteries included".

There is software development being done outside of the web.

Indeed... at my day job we developed a cross-platform native GUI for our main product in Python (which was originally written in C++/MFC for Windows only). We also use Python for lots of other things such as our build system (using SConstruct and our own custom code to interact with CVS and Samba), generating C++ code (with Cog), parsing and converting HDL (hardware description language) code to various different file formats, and more.