Author here. My article is not supposed to talk about a good idea. It's meant to bring a bad idea to the table and explain why it works. I designed the function in question with the understanding that it would fire once or twice per 10 minutes. This means that paying a cost like 3.1 megabytes per invocation is okay. If this was intended to run _constantly_ (such as if it was a core part of a run loop), that's different.

One thing I'm wondering about: what's the call overhead of wazero? Especially for function calls (rather than as a `system()` alternative)?

I understand that cgo has significant per-call overhead, aside from all the other curses it implies, does wasm/wazero have the same issue or not?

With the version of wazero I'm using right now, it's about 0.3 milliseconds to do a single call from Go to Rust and back in the best case on my hardware. I am told that a recent patch to wazero will increase this by a lot, so I'm going to try upgrading to that patch and see what differences it makes. I still think that it will be a bit slower than cgo, BUT the platform-independence and strict sandboxing makes up for it in my book.

I think the article is absolutely clear about it but also I think people will (are! in this very thread) ignore that part and make enormous messes that will hurt real users and someone else will have to clean up.

I’m not sure how to fix this but I’m also tired of pretending it’s not a chronic problem.

If you ship something featured in my blog into production that's your problem TBH. I can't be responsible for the sins of others.

I'm not going to blame you for anything, but I also think this is an odd viewpoint for a professional technical communicator to have.

I recommend putting this point up at the top and quite clearly explain that.