Separately, I’m surprised Apple didn’t do this with Swift. I thought one of the goals of Swift was to be a good language for low level code up to high level scripting.
This should be dynamic, but it shouldn't be LUA. It should be something like JSON. Although Lua is sandboxed, so it's safer that way, it is still an easier and bigger attack vector for hackers than JSON would be.
For any given programming task, there is a fixed (minimum) amount of work to do to solve it correctly, and the programmer's design choices merely decide the distribution of that work among the environment, the compiler, the standard library, the third-party libraries, and the programmer herself.
Meaning, that in order to use the programmer's time most effectively per unit of task difficulty, the language itself should be such that the compiler does as much work as it possibly can. Such a compiler simply won't be small, and probably won't be fast either. (imho the best it can or should do in the face of a syntactically-valid non-program, is to give as many errors at once as are applicable, so that the programmer can fix them all in one go)
Rust, of course, in the grandly oversimplified view, takes this tradeoff in the same direction as Swift, and I'm sure you're familiar with all the ways that Rust is better for it ... and even a few ways that Rust is worse for doing the opposite. :)
(Though, then again, there's miri, for those that value correctness over performance. Unless it too has changed names.)
Behavior changes of the os should not be quiet and magical, they should be intentional and the user should be notified (if they care).
Presumably both of these have more overhead than Apple wanted in this case, but it does seem odd.
I'm a bit surprised at the use of Lua, given that JavaScriptCore is already there. But I wouldn't be surprised if Lua was just something that the team was already familiar with. Lua is tiny, so it's not like it adds a significant dependency.
https://news.ycombinator.com/item?id=17186842
JavaScriptCore has a huge surface area. It is measured in tens of megabytes, whereas Lua is measured in hundreds of kilobytes. Wikipedia chose Lua because it was small enough that they were able to audit every line of code for security. Verisign approached Lua the same way for their high-reliability servers.
Consider the complexity of JavaScriptCore. Their new-ish "FTL" optimization engine stands for "Fourth Tier LLVM", which means there are at least 4 levels of runtime optimizations JSCore performs on code, which is a lot of non-trivial complexity. And JIT means they cannot utilize no-execute bits in hardware.
Then there is the memory and power-consumption. Lua's footprint for a VM instance is tiny. It is also a very efficient language, even in interpreted form. JavaScriptCore is comparatively heavy in both regards.
Remember that Apple Watch still does not have Safari and JavaScriptCore is not available for watchOS developers. Presumably this decision is partly influenced by memory and performance constraints. Lua is trivial to get working well on watchOS.
For a core feature, it makes sense to have minimal dependencies with a minimal footprint so plenty of room is left for user applications. Remember that Apple probably has a bunch of skunkworks devices in their labs they hope to productize someday. And many of these might be tiny portable devices with minimal hardware capabilities, like Apple Watch (or remember all the different iPods?).
Lua's tiny implementation and extreme portability (written in pure ANSI C) make it well suited for this role. Apple won't have to port Lua to every new experimental CPU architecture they try, whereas JavaScriptCore has a lot of platform specific #ifdefs which have to be dealt with for every new platform.
I've worked with SpiderMonkey and have known the team for about a decade now. I'm aware of the complexity :)
> Consider the complexity of JavaScriptCore. Their new-ish "FTL" optimization engine stands for "Fourth Tier LLVM", which means there are at least 4 levels of runtime optimizations JSCore performs on code, which is a lot of non-trivial complexity. And JIT means they cannot utilize no-execute bits in hardware.
FTL is gone, I believe. But anyway, JSC is not just a JIT. If you're worried about the JIT, just use an interpreter.
> Then there is the memory and power-consumption. Lua's footprint for a VM instance is tiny. It is also a very efficient language, even in interpreted form. JavaScriptCore is comparatively heavy in both regards.
JSC uses a hand-written assembly interpreter. I would be shocked if it beat Lua in performance.
> For a core feature, it makes sense to have minimal dependencies with a minimal footprint so plenty of room is left for user applications.
JSC has been shipping since the first version of iOS in 2007. Tons of apps use embedded WebKit already.
> Remember that Apple Watch still does not have Safari and JavaScriptCore is not available for watchOS developers.
This may well be the reason.