If Python devs/users had to actually use all pure Python libraries, no C bindings or Rust bindings, no RPC to binaries written in faster languages, it would get dropped for a ton of use cases, absolutely including its most prominent ones (machine learning, bioinformatics, numeric analysis, etc.).
Yeah, because people use python when it doesn't matter and c++ when it does (including implicitly by calling modules that are backed by c implementations).
That is not an option with FHE. You have to go all in.
Yes but with FHE it also depends on the use-case and how valuable the output is and who is processing it and decrypting the final output.
There are plenty of viable schemes like proxy re-encryption, where you operate on a symmetric key and not on a large blob of encrypted data.
Or financial applications where you are operating on a small set of integers, the speed is not an issue and the output is valuable enough to make it worth it.
It only becomes a problem when operating FHE on a large encrypted dataset to extract encrypted information.
The data extracted will need to offset the costs. As long as companies don't care about privacy, this use-case is non-existent so its not a problem that its slow.
For military operations on the other hand, it might be worth the wait to run a long running process
If Python devs/users had to actually use all pure Python libraries, no C bindings or Rust bindings, no RPC to binaries written in faster languages, it would get dropped for a ton of use cases, absolutely including its most prominent ones (machine learning, bioinformatics, numeric analysis, etc.).
It would probably especially include those before most others. The best thing about Python IMO is the FFI and the ecosystem built around it.
Yeah, because people use python when it doesn't matter and c++ when it does (including implicitly by calling modules that are backed by c implementations).
That is not an option with FHE. You have to go all in.
Yes but with FHE it also depends on the use-case and how valuable the output is and who is processing it and decrypting the final output.
There are plenty of viable schemes like proxy re-encryption, where you operate on a symmetric key and not on a large blob of encrypted data.
Or financial applications where you are operating on a small set of integers, the speed is not an issue and the output is valuable enough to make it worth it.
It only becomes a problem when operating FHE on a large encrypted dataset to extract encrypted information. The data extracted will need to offset the costs. As long as companies don't care about privacy, this use-case is non-existent so its not a problem that its slow.
For military operations on the other hand, it might be worth the wait to run a long running process
And people will use FHE where it matters and plaintext where it doesn’t…
For compute, which is a small part of things computers do. Many things are I/O and network bound.
I’m not at all a fan of Python, but perf is the least of my concerns with it.