Live data from Hacker News

How we rolled out one of the largest Python 3 migrations

blogs.dropbox.com

41–50 of 141 posts

Re: How we rolled out one of the largest Python 3 migrations

#41

Interesting write-up, though it leaves me terrified how a relatively small, more or less single purpose application like the Dropbox client has over 1 million lines of code in Python alone.

You might only use a small part of Dropbox, but I bet there is a lot of functionality that you don't care about but which is critcial to Dropbox as a business/product for others.

The fact that you think it's small means they're probably doing something right!

Relevant: https://danluu.com/sounds-easy/

(FWIW I don't use Dropbox myself, but I definitely had people ask me why Google needed 3,000 employees back in the day. Apparently it now has nearly 90K employees.)

Re: How we rolled out one of the largest Python 3 migrations

#42
post #18

Earlier quoted context omitted.

The size of a codebase is less about its function and more about the number of people adding code to it.

What would you consider the main cause(s) of that?

The job of a programmer is to write code, so that’s what they do. I doubt there are very many people at Dropbox whose job it is to remove code!

Re: How we rolled out one of the largest Python 3 migrations

#43

Earlier quoted context omitted.

We can simply start by asking what does “syncing files” include? Watching files. Keeping backup of files. Keeping conflicts resolved. Watching Selective Sync files and folders. Watching Smart Sync files and folders. Notifications for synced files. Etc. etc. There’s way more the client does than what I mention.

I agree that syncing is far from trivial, but that doesn't change it's a single purpose.

A rocket ship is also "single purpose."

Re: How we rolled out one of the largest Python 3 migrations

#44
post #42

Earlier quoted context omitted.

What would you consider the main cause(s) of that?

The job of a programmer is to write code, so that’s what they do. I doubt there are very many people at Dropbox whose job it is to remove code!

That’s an extremely narrow definition of a programmer’s job.

I think that in terms of lines if code, my contribution to many projects was net negative.

Re: How we rolled out one of the largest Python 3 migrations

#45

I would have thought that Go would be perfect for this sort of system-level-like programming ?

Dropbox uses Go (https://github.com/dropbox/godropbox), Rust (e.g. https://github.com/dropbox/rust-brotli) and Python on the server-side, and both Rust (https://github.com/dropbox/finderinfo-rust) and Python on the client-side.

As other commenters have noted, a lot of their Python use for large scale systems was an artifact of history and available choices at the time, but from my experience during my time there and following as an outside observer since leaving, they seem to make reasonable infrastructure and language decisions for their core product.

Re: How we rolled out one of the largest Python 3 migrations

#46

Interesting write-up, though it leaves me terrified how a relatively small, more or less single purpose application like the Dropbox client has over 1 million lines of code in Python alone.

Especially when you could build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem!

Re: How we rolled out one of the largest Python 3 migrations

#47
post #42

Earlier quoted context omitted.

The job of a programmer is to write code, so that’s what they do. I doubt there are very many people at Dropbox whose job it is to remove code!

That’s an extremely narrow definition of a programmer’s job. I think that in terms of lines if code, my contribution to many projects was net negative.

[deleted]

Re: How we rolled out one of the largest Python 3 migrations

#48
> However, rather than use the native toolchains directly, such as Xcode for macOS, we delegated the creation of platform-compliant binaries to py2exe for Windows, py2app for macOS, and bbfreeze for Linux.

I wish the authors of more Python tools would deploy standalone applications. I do not like having to maintain various sets of Python installers/package managers (because every Python tool seems to use a different installer). Especially on cloud servers that often lack a whole set of dependencies that Python developers just seem to take for granted.

I’m not a Python developer. I don’t have the time or the inclination to repackage various tools and untangle dependencies.

Given the choice between trying to figure out how to get multiple Python tools to behave together, or using another tool, I’ll almost always choose an alternative.

Re: How we rolled out one of the largest Python 3 migrations

#49
post #17

Earlier quoted context omitted.

Probably because it was 2.7 only, and only 10% faster on Dropbox's code. https://blog.pyston.org/2017/01/31/pyston-0-6-1-released-and...

I'm surprised 10% wasn't enough - 10% bottom-line improvement in programming language implementation is normally massive. Twitter is singing from the roof-tops about 10% improvement in Java performance from the new Graal JIT compiler.

Maybe because 10% on a server is much more valuable than 10% on a client.

On a server, you’re paying for that 10%. On a client, you’re not. If it was 10% for nearly free then sure - but maintaining a separate implementation of a language is costly.

Post reply on HN