A special class of theorem provers could be developed, proving that a program runs below a certain level of spacetime complexity.
This would entail a great increase in energy efficiency.
I also endorse holy information warfare against inefficient proof of work cryptocurrencies and a transition to efficient proof of stake.
That would come at some kind of compile time or efficiency cost since you couldn’t anymore optimise for those but I’m sure that’s something one could opt for.
I don’t think binary size matters though. Storage is very cheap these days.
At least the prices are almost normal again, now that Chia's over.
You could also have self modifying code such that the size of the binary automatically changes as needed.
If you ship a lisp interpreter instead of rust, you can have the interpreter recode itself and any lisp files to a smaller size. You’d just implement a compression algorithm that preserves the functionality of the code compressed.
I think you could do that with rust too with a self compiling binary. It’ll require some real technical skill but if you hire a real hacker you can pull it off.
My cousin his solution for the competitive programming contest had something like that.
I do have a project a bit like that, but I'm not using Rust for it. I was trying to make my own language (like Rust, but more powerful and also smaller), but I'm probably just going to use a modified (safer) C.
If I were to write it in Rust, I'd have to compile it in the first place… and if I could do that easily, I would simply use Rust.
If you're building a docker image for example Rust is going to be smaller.
Sure, I could probably halve that by forking every dependency so they aren't duplicating versions, but that's a lot of work. (It's a shame Rust doesn't let you do conditional compilation based on dependency versions, or this would be a lot easier. As it is, we have to resort to the Semver trick: https://github.com/dtolnay/semver-trick/ — not that many people do that, so it's functionally useless.)
Take GanttProject as an example. It's 20.6MiB of files, plus the JVM. I challenge any of you to make a Rust version (with accessibility support in the GUI) that can open (something resembling) its XML files and draw some (vague graphical Proof of Concept) representation on the screen (with editable text fields), in less than 114+21=135 MiB of binary. And then tell me how, because I've been trying to do that kind of thing for over a year.
¹: I can get it down to around 8MiB with release mode, lto etc., but that significantly increases the build time and only about halves the weight of the intermediate build files.
How dare you claim a larger binary...
Let me guess; Go?
Are you building in "release" mode? The debug builds can be 10x bigger.
cargo build --release
But yes, I have tried my own custom debug profile that turns on the optimisations to try to get the size down. The final binary is smaller, but `cargo build` still regularly leaves me with just kilobytes of space remaining, and then fails outright until I `cargo clean` and try again (which I think is build script related).
I would personally prefer a language model designed to emit x86 assembly, akin to Github copilot, but I understand that to be a minority viewpoint.
Do not rewrite software in Rust, because Rust is not an efficient language. It's a memory, and RAM hog, and it's unstable, with major breakers every release. Switching to Rust is not a thing for a profit seeking enterprise.
In practice, it's an n-fold downgrade from good C on performance.
I know there exists a formally verified secure C compiler. Ideally you would have a similar compiler which guarantees low energy uses.
In my experience Rust already does a great job there but I’m happy to behold whatever evidence exists for C being more energy efficient.
Source? I was under the impression that Rust took an aggressive approach to back compat.
And I'm also not a proponent of rewriting in Rust for it's own sake, but the other commenter was suggesting it in place of Python, which would probably be a huge net gain in efficiency.