Hmmm. If I chose a chip with the resources to run this Toit thing, I can reduce costs by switching to a cheaper, less powerful chip and writing native code. If I'm shipping several million of these, it's a no-brainer; it saves real money. In some products I've worked on, saving ten cents per board would be a big deal. Also note that you're paying more than money; fancier and more capable chips usually consume more power, so imagine some lively conversations with the industrial design folks about battery lifetime and size, too.
If you're using off-the-shelf consumer-y ESP things, you're likely insensitive to cost and you're probably paying for performance you don't need.
I last saw this technique (maybe 15 years ago) used by a super tiny .NET runtime environment intended for devices like smart watches; you wrote to "tiny" APIs, a tool did a bunch of reprocessing of your binary into smaller tables and whatnot, and poof, it would run on a watch. With all the GC and so forth going on, it's not something I'd want to write a whole embedded system in, though it was okay for applets.
I'm not oblivious to the security advantages of using a bytecode interpreter, but on a high-volume product you'd have to make a case for how important this kind of thing is.
ESP32 is extremely price competitive in its space. The use case is internet connected applications, which are going to need the kinds of resources Toit requires anyway.
What gets me is the implicit promotion of javascript as the gold standard of available tooling. That gives me hives, even though it's probably true.
If you're using off-the-shelf consumer-y ESP things, you're likely insensitive to cost and you're probably paying for performance you don't need.
I last saw this technique (maybe 15 years ago) used by a super tiny .NET runtime environment intended for devices like smart watches; you wrote to "tiny" APIs, a tool did a bunch of reprocessing of your binary into smaller tables and whatnot, and poof, it would run on a watch. With all the GC and so forth going on, it's not something I'd want to write a whole embedded system in, though it was okay for applets.
I'm not oblivious to the security advantages of using a bytecode interpreter, but on a high-volume product you'd have to make a case for how important this kind of thing is.