4 ms·
It seems relatively well established that C requires a trusted environment. You need to have faith in your collaborators and in your toolchain, and in your depe
by JonChesterfield 3y ago
It seems relatively well established that C requires a trusted environment. You need to have faith in your collaborators and in your toolchain, and in your dependencies, to get something that works reliably. This trusted environment is looking increasingly optimistic as time goes on.
The sandbox approach works relatively well where it's applied. If you're given a lua interpreter that doesn't know how to talk to the network, you're going to have a tough time compromising the underlying kernel to gain that capability. But your performance will be grim. Web assembly is roughly what you get if you run far enough down that path trying to engineer out the inherent limitations.
I wonder if the microservices people are onto something here. Some boundary around a unit marked "database" or "hashtable" that can't talk to the internet, something RPC themed to tie the pieces together, possibly all fed into a single address space to bring the performance overheads down to something reasonable. The problem is it's a huge pain to work with and makes the dev process slower, i.e. you get outcompeted by something broken-by-design that shipped faster.
It's an interesting problem space. Agreed with the OP that it seems underserved.
- hackable_sand 3y agoMy experience is that C requires strong developers and attention to detail. That requires time, and complexity increases non-linearly per LoC. If we're talking supply chain, it's great for embedded and edge devices, otherwise I look to the old wizards to provide the foundational libraries for interpreted services. Supply chain safety is more a function of economics in my uninformed opinion. How can we reduce middlemen while preventing monopolies or bottleneck moats?