Is the idea if you have a desktop app executable wrapper and you could include this engine to start building desktop apps in JavaScript?
I don't think I have a clear understanding of this type of use case or how this will be used, please share.
The only thing I can think of is you could use this JS engine allow folks to code in JS, instead of C/C++, that actually interface with C/C++ APIs? Examples anyone?
- In a game, write quest logic in the scriptable language so that game devs can tinker with quest design without recompiling the game binary.
- "plugins" (usually UI plugins of some kind). Games like Elder Scrolls Online and World of Warcraft allow for 3rd parties to write UI extensions in Lua.
- Any other logic that you want to run and frequently modify without modifying the binary.
There are other great uses-cases that I can't think of right now, hopefully others can help.
- You already have working JS code that you don't want to rewrite for a new platform
It also greatly simplifies logic because you can do pattern matching and filtering (similar to Erlang) more concisely than in C.
I think that coroutines are on the verge of replacing callback hell so we'll start to see patterns from Go begin to show up in other languages, perhaps embedded in this way. The browsers dragged their feet for years by not implementing generators and yield (in ECMAScript 6) and set javascript back immeasurably, so being able to go around them with embedded libraries will be huge.
In a more generic sense, since 10% of a program causes 90% of the slowdown, there is little speedup to be gained by using C in the real world, especially if it's mostly using system calls that are already optimized. Some examples of this are how a high level language like php has succeeded in the server world even though it's not particular fast or elegant, and how Objective-C is often still slow even though it's low level (because programmers sometimes do too much with their "bare hands" rather than building upon heavily optimized libraries like C++'s Boost). I think this explains the rapid adoption of Swift, which is basically another high level language in place of a more painful low level one but providing similar performance.
For embedding, you need some small language with small runtime. Something like Scheme/Lisp/Lua would work. Something like Python is not suitable. Lua is popular in the gaming scene because of its small size and its well designed architecture for embedding. Looks like Javascript is getting there.
This is a wild overgeneralization. Civ4 used Python as its embedded scripting layer to great success.
(Me, I just use C# as a scripting layer inside of a C# application. On desktops, the content C# is compiled or read from cache at runtime, but on other platforms I can include the scripting libraries as project references and have them incorporated into stuff like Mono's AOT linker. http://github.com/eropple/exor )
Low-level (like, just about assembly, maybe slightly higher) workloads that require high performance or are annoying to do any other language.
What is C++ good at?
All of the stuff C can do, but also bolting on a weirder type system, generics, metaprogramming, and a whole bunch of other stuff. It's fast, but rapidly becomes a festering tumor of functionality.
It's a katamari of design features, and even though it exposes a lot of awesome high-level abstractions the fact that it still allows working at the C level prevents it from being compelling.
What about JS?
Javascript is dynamically typed, which is terrible in many ways but bloody useful for quickly getting shit done. It is a functional language with prototypical inheritance, and so naturally lends itself to high-level programming...with regexes and functions as first-class objects, and a really pretty simple type system.
It sucks at high-performance stuff, but it allows for a lot of clever and very brief code.
So, if you want high-performance and the power of high-level abstractions, it makes sense to use C and JS--each a fairly small language well-suited to its problem domain. C++ would require too much annoying work on both sides of the problem.
A good workload for this would be: in-game scripting, network message transforms, simple command-line utilities, game engine writing, numerical library writing, asynchronous IO processing..basically, any application where you can easily separate out the low-level primitives from a flexible high-level solution description.
~
Then again, for all of what I'd said, I think you might as well just be using Erlang or Elxiir. :)
Did you coin this phrase? It's a fascinating, evocative, and quite possibly accurate description of many of the systems I find most frustrating. In any case, thank you for bringing a smile to my face today :)
It seemed like it fit.
There are three concerns that make an embedded language good:
1) Lockstep multiplayer. Each player has a full copy of the gamestate on their client. Every action performed against the gamestate is done in sync on every machine in a deterministic fashion and order. This means that any custom code must be written with preserving sync in mind - something as simple as rand call on the clients would break sync. So Lua allows the engine developers to properly restrict the users to only use libraries and language constructs that will respect the sync (it fails at this, but it's a goal and Lua helps with that).
2) Code from peers. Users develop code for other users - widgets that help on the user-interface and games for each other to play. A sandboxed environment is a must.
3) Graceful failure. If a widget fails it doesn't bring down the whole engine with a segfault.
Embeddable, small-footprint JS allowing the masses to script things with sounds pretty useful!