[jwr]

Seconded. I can't put too many files in Dropbox, and additionally it burns power even if files are changed outside.

In general, it is a CPU catastrophe, a penalty I have to pay in order to use file synchronization. I really hope that a better competitor appears.

Additionally, the software pesters me with annoying popups pushing me to upgrade.

[bluedino]

At what piont do you see issues? I'm on the free tier and only have about 3GB of files and have never noticed any CPU usages issues with Dropbox on my Mac

[jwr]

Perhaps you haven't looked? Try cloning a git repo, or unpacking a tarball with many files (doesn't matter if it's inside Dropbox or not) and observe the CPU usage of the Dropbox process.

I checked right now and the Dropbox process on my machine has consumed a total of 39 minutes CPU time. That's 39 minutes of full-scale CPU usage. Even their "web helper" process (whatever that is) consumed two minutes and 41 seconds.

[vonseel]

(Google) Backup & Sync currently shows 2:04.46 in CPU time on my Mac. I'm guessing that means 2 hours and 4 minutes. The machine was shutdown overnight and booted this morning. Is this something that resets with each boot?

[bluedino]

I don’t have a use case for cloning a git repo to Dropbox

[vishvananda]

the parent mentions in parentheses that the dir doesn't have to be in dropbox because it appears to monitor all files.

[TeMPOraL]

Sounds broken on user end. Never seen anything like this when using Dropbox on several versions of Windows and Ubuntu, on both low-end and high-end machines.

[zapzupnz]

> on several versions of Windows and Ubuntu

This discussion is about performance of the macOS client. Saying that clients for other OS work well doesn't really contribute to it.

[agumonkey]

dropbox, considering their size, is really in a position for a solid rewrite.

ocaml ? http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-ret...

nim ? rust ? go ?

[c256]

DropBox is the Electron client of file sharing. They could make native apps that use native apis and get vastly better performance in time, power, cpu, and probably memory — but then they’d have to create and maintain a bunch of native apps. I know it’s common to hear HN comments like “they have the money/skill/opportunity to trade up to a better platform for more effort”, but everything I’ve seen says that it’s much harder to make that choice than to stick with the tech-debt you already have.

Note: I’m not saying it’s literally an electron client. It’s an analogy. :)

[tonyedgecombe]

It does bundle Chromium so it isn’t far off.

[agumonkey]

I get it don't worry. Maybe they'll do it later when it will be an obvious advantage for the company.

[aldanor]

It's particularly funny because they hired Guido (GVR) who is supposedly helping them migrate a million(s) lines of code py2->py3. Whereas a better solution in the long run would have probably been just rewriting the whole damn thing in Rust for all platforms.

[hobofan]

Rust doesn't sound too unrealistic, given that they were one of its first big commercial users.

[agumonkey]

they do rust ? fun

[eridius]

They use Rust in the datacenter. The layer that actually writes bits to disk is written in Rust. I don't know why they haven't yet deployed a native desktop client that's a Rust core with a thin platform-native GUI wrapper.

[jhurwitz]

Jamie Turner from Dropbox gave a talk at a Rust meetup in 2017: https://air.mozilla.org/rust-meetup-may-2017/

Edit: at 30:05 in that video, he briefly talks about a forthcoming (as of 2017) "full redesign + rewrite of Dropbox's 'sync engine' in Rust." He claims it will use 10x less memory, and be 50x faster on key operations.

[zerd]

The also mention it here https://news.ycombinator.com/item?id=14926851

strings /Applications/Dropbox.app/Contents/Frameworks/libdropbox_watchdog.dylib | grep -i rust shows some hits:

  __ZN14rustc_demangle8demangle17h2ad719809986c0fcE
  _rust_begin_unwind
  /Users/vagrant/client-dropbox-python/dropbox-virtual-env-3985da1e510f-mac-x86_64-10.14/rust/lib/rustlib/x86_64-apple-darwin/lib/libcompiler_builtins-f10e664516557f83.rlib(compiler_builtins-f10e664516557f83.compiler_builtins.7wkmozn8-cgu.0.rcgu.o)
  ___rust_probestack
  /Users/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.5/src/probestack.rs
  ___rust_alloc
  ___rust_dealloc
  ___rust_realloc
  ___rust_alloc_zeroed
  /Users/vagrant/src/client/rust_vendor/hyper-0.10.13/src/buffer.rs
  /Users/vagrant/src/client/rust_vendor/serde_json-1.0.33/src/read.rs
  ...

Looks like they use it fairly lightly though.

[agumonkey]

Thanks for the link, missed it