That is a great strategy. It gets easier over time though. My tipp is to still join smoking friends, but just don't smoke. Makes you robust against the temptation longer term.
Any language can be sandboxed on the VM level. It's a property of it's implementation. So you can say that Lua has no sandbox friendly implementation right now.
For example, termination you can solve by unwinding the stack in efficiently polled safepoints. You need to take down the entire sandbox-capable Lua VM instance but you can.
I work on Truffle for more than 10 years and I recently wrote a comment on hackernews using Futurama instead of Futamura. That comment had it wrong twice.
Truffle has no opinion on how you parse the sources. It cares about how you execute them from an intermediate Truffle guided representation produced by the parser.
In other words antlr and truffle are a great fit. We even use this pairing for our example language simplelanguage.
Very few people have heard of them. That is exactly the reason why I mention them as often as I can. They are a great entry into the world of meta compilers.
The truffle compiler extensions in Graal will be part of Galahad. For example the partial evaluator. The truffle framework and all the languages are consumed from a maven repo as a regular java library these days.
Pkl was built using the GraalVM Truffle framework. So it supports runtime compilation using Futamura Projections. We have been working with Apple on this for a while, and I am quite happy that we can finally read the sources!
I can't see how you can avoid the centralization problem and also have decent monetization for the videos. But I want to certainly become convinced that it can work. Crypto made me a decentralization skeptic.
Alternative to working with a big silicon valley giant. If you want to integrate/use YouTube you need to deal with whatever that company puts you up with. And as the article states, you don't want them to become grumpy at you; otherwise, they will turn you off even quicker. The only alternative I see is to develop a new YouTube, which seems unreasonable given how dominant Google is.
We do not do process isolation yet, although we have plans to implement that as well as a fallback strategy.
The advantage of the native-image-isolate-based isolation is that it is much more lightweight. For example, calls from and to the host application are much faster. There is no copying or expensive synchronization necessary. The disadvantage is that we need to do our own protections against attacks, as the OS protections between processes don't apply to such isolates. By default, we deploy software/compiler-based protections but are also very close to supporting hardware like Intel MPK.
I did some digging on past discussions, and yes, it seems the stars are not aligned for extension methods in standard Java.
But tbh, there are some very good arguments against extension methods. Also, some tricky questions about overloading handling and compatibility are lurking in the shadow. But if you have good suggestions on how to fix them, I'd take the time to propose something on an OpenJDK mailing list, maybe you get some support.