libpeer

re ways around all of these: * a. Static vs dynamic linkage: in an embedded system, it'd be reasonable to just produce a single userspace binary that does everything. It can change its behavior based on argv[0]. I think this is not too unusual for constrained systems even with C binaries. Eg busybox does it. If you only have one binary, you don't need dynamic linking. Also, I think it's not strictly true that Rust doesn't support dynamic linking. I think you can dynamically link everything if you ensure the whole system is built with the same compiler version. * b. Standard library. You don't have to use it at all, or you can use it sparingly, paying only for what you use. * c. Monomorphization. You could write (for example) a Go-like map [2] rather than relying so heavily on monomorphization. I'd love to see someone take this idea as far as possible; it might be a good idea for a lot of non-inner-loop code in general, not just on tight embedded systems. * d. Using full-featured libraries. Obviously no one is making you do this; the same cheats available in C are available in Rust. but in fairness, the further you go down this path, the further you are from just being able to just take advantage of the whole Rust ecosystem. Personally, I'd still rather develop or use a #![no_std] Rust codebase than a C one. Memory safety is important to me. IOT devices are no exception to that. Their security history is horrible, and I'd like their security future to be better... [1] https://github.com/sepfy/pear/blob/b984c8dccaafdcdd1b181786a... [2] https://dave.cheney.net/2018/05/29/how-the-go-runtime-implem...