I'd say it's just a hard problem.
After all, the fs routines in python are all written in c, file watching uses the os api such as inotify, so python speed has little impact on those operations. Same for the gui. Same for the network since you only have a few connections to one server.
Dropbox doesn't even index the file content, so basically not many stri g or numerical operations. I've got 15 years of python behind me, and i'm pretty good at guessing what workload it's going to be slow at. This is not one of those.
Many people tried to compete with dropbox. None of them won, because eventually, their software either can't match the features, the perfs, the availability, the price, or the ease of use.
I should know, i tried to escape dropbox, as i don't like the company ethic stance, and tried many alterntive.
Dropbox is just very, very good.
iCloud Drive works pretty well for me.
> After all, the fs routines in python are all written in c, file watching uses the os api such as inotify, so python speed has little impact on those operations. Same for the gui. Same for the network since you only have a few connections to one server.
You'll notice that these aren't the things I mentioned as things you shouldn't be doing in Python, aside from the GUI, which I will maintain should not be done in Python. Writing parts of Dropbox in Python is fine, but there are places where they really shouldn't.
Which is why Dropbox uses 100% of the CPU while syncing? It's pretty clear that trying to handle thousands of files is not a trivial operation. Sure, Python can do the job, but something native will probably do the job faster.
> in such an heterogenous software is what you want
No, not really. I'd rather the software work well, and I'd rate Dropbox as "passable" rather than "great".