4 ms·

It was a javascript-like language called UnityScript, that actually compiled to IL, and had a lot of C#/CLR features tacked on top. It was fairly unused, and ki

It was a javascript-like language called UnityScript, that actually compiled to IL, and had a lot of C#/CLR features tacked on top. It was fairly unused, and kinda cursed to boot. Unity also had another language called Boo, which was fake Python which also compiled to the CLR, and we're happy that's dead too. There's some packages like MoonSharp which will let you write Lua for Unity (modulo some bindings), and a few visual scripting tools too. There's also going to be a native visual scripting tool coming out in the next year or so.

DonHopkins 7y ago
One important distinction is that C# and UnityScript and Boo are build-time compiled languages, not interpreted (or JITted) at runtime like JavaScript typically is. You can't dynamically download and interpret UnityScript code at runtime, or include it in downloadable asset packages. If you make any changes to your app, you have to release a new version of it, and convince users to upgrade, and you can't just push an update out over the web, like you can with JavaScript. This comes into play on the Apple app store. Even if you implemented, say, a Scheme interpreter in C# that could interpret s-expressions at runtime, Apple would not let you publish an iOS app on their app store that downloaded Scheme code and interpreted it. It's not impossible or hard to do, but it's simply against their rules. On Apple's app store, the ONLY language you're allowed to do that with is JavaScript, running in Apple's own Safari web browser's JavaScript engine. That is a hard non-technical constraint that there is no way of programming or negotiating your way out of, and it's not going to change any time soon. The old version of the iOS Safari component, UIWebView, runs in-process, and allows you to call back and forth with native code (it has a nice native Objective C bridge), but it did not have a JIT so it was slow. (Sandboxed iOS apps developed outside of Apple aren't allowed to write to code memory, so JIT compilers are prohibited.) https://steamclock.com/blog/2013/05/apple-objective-c-javascript-bridge/ https://steamclock.com/blog/2013/05/apple-objective-c-javasc... But the new iOS Safari component, WKWebView, runs in a separate process that Apple trusts, and it has the JIT enabled, so its JavaScript engine is extremely fast and robust, and fully compatible with most modern JavaScript libraries. But you can't call native code, because it's running in another process, and doesn't support an Objective C bridge. But you can send messages back and forth (tell it to execute JavaScript code, receive JSON or text messages back from JavaScript, but no directly passing pointers or calling functions). So instead of using a platform specific Objective C <=> JavaScript bridge like the one Apple deprecated, UnityJS has a cross platform C# <=> JavaScript bridge with a JSON protocol, so it works fine with WKWebKit, without breaking Apple's app store rules.

DonHopkins 7y ago

One important distinction is that C# and UnityScript and Boo are build-time compiled languages, not interpreted (or JITted) at runtime like JavaScript typically is. You can't dynamically download and interpret UnityScript code at runtime, or include it in downloadable asset packages. If you make any changes to your app, you have to release a new version of it, and convince users to upgrade, and you can't just push an update out over the web, like you can with JavaScript. This comes into play on the Apple app store. Even if you implemented, say, a Scheme interpreter in C# that could interpret s-expressions at runtime, Apple would not let you publish an iOS app on their app store that downloaded Scheme code and interpreted it. It's not impossible or hard to do, but it's simply against their rules. On Apple's app store, the ONLY language you're allowed to do that with is JavaScript, running in Apple's own Safari web browser's JavaScript engine. That is a hard non-technical constraint that there is no way of programming or negotiating your way out of, and it's not going to change any time soon. The old version of the iOS Safari component, UIWebView, runs in-process, and allows you to call back and forth with native code (it has a nice native Objective C bridge), but it did not have a JIT so it was slow. (Sandboxed iOS apps developed outside of Apple aren't allowed to write to code memory, so JIT compilers are prohibited.) https://steamclock.com/blog/2013/05/apple-objective-c-javascript-bridge/ https://steamclock.com/blog/2013/05/apple-objective-c-javasc... But the new iOS Safari component, WKWebView, runs in a separate process that Apple trusts, and it has the JIT enabled, so its JavaScript engine is extremely fast and robust, and fully compatible with most modern JavaScript libraries. But you can't call native code, because it's running in another process, and doesn't support an Objective C bridge. But you can send messages back and forth (tell it to execute JavaScript code, receive JSON or text messages back from JavaScript, but no directly passing pointers or calling functions). So instead of using a platform specific Objective C <=> JavaScript bridge like the one Apple deprecated, UnityJS has a cross platform C# <=> JavaScript bridge with a JSON protocol, so it works fine with WKWebKit, without breaking Apple's app store rules.