Quoting myself from my own FAQ[1] feels a little weird, but here you go:
---
There are a few scripting languages used for embedding in applications. Lua is the main one. TCL used to be. There’s also Guile, increasingly JavaScript, and some applications embed Python. I’m an ex-game developer, so when I think “scripting”, I tend to think “game scripting”.
Lua is nice: it’s small, simple, and fast. But—and I don’t mean this as a criticism—it’s also weird if you’re used to languages like C++ and Java. The syntax is different. The semantics, especially the object model are unusual. Anyone can get used to 1-based indexing, but things like metatables really show that objects were bolted onto Lua after the fact.
I think there’s room for a language as simple as Lua, but that feels natural to someone with an OOP background. Wren is my attempt at that.
I used to have a program with an embedded Lua interpreter where I sometimes needed to switch back and forth between C++ and Lua. It's insane. Arrays don't start at zero, you create blocks with keywords and then there are some minor annoyances like != being ~= or the lack of a ternary operator. Where Lua really shines though is the binding api. It's really easy to use when you have to do something by hand. The documentation is great and you have a selection of binding tools. You can even create classes with overridable virtual methods.
Since Lua is rather tedious to use for me, I looked for alternatives with a C-like syntax. I found Squirrel and Wren but the last time I looked they lacked the tooling and mailing lists that Lua already has. It's a bit of a chicken-egg problem unfortunately.
> I found Squirrel and Wren but the last time I looked they lacked the tooling and mailing lists that Lua already has.
Yup, Wren still has a long ways to go in terms of being a mature ecosystem, but it's getting there slowly. It would be moving faster, honestly, if I put more time into it, but there are only so many hours in the day.
I totally forgot about AngelScript. It really has the lowest context switching overhead, but you get to keep the verbose C++ syntax in return, which is a trade-off.
Personally I don't mind if a language differs somewhat, but with Lua I constantly get errors because of basic things like braces, comments and comparisons.
I wonder of a language-agnostic computing platform could be developed based on a Lua-like securely-embedded system. That is, something like the JVM, but the client code can only access the things that are explicitly provided to it by the host environment.
You'd be pretty constrained by what concepts of "object" to support, though.
About a year ago I made Rust bindings, but they are out-of-date now, as I kind of stopped participating in the wren community (not their fault, I stopped participating in a lot of communities due to some happenings in my personal life). I will have some more time coming up here soon, and hope to get back into it.
I would use it as an extension language for a larger system. These commonly are used in games, databases, web servers, and text editors. You might:
• Link Wren (or Lua or a little scheme interpreter) into your larger system.
• Add some functions to Wren to access and manipulate the state of your larger system. (The sections on how to accomplish this are sadly marked as TODO in the Wren Reference manual.)
• Add a mechanism to your larger system to invoke Wren scripts.
Now instead of having to invent your own scripting system, or your own configuration system, or your own commands for every conceivable function a user wants, you can just expose the basics and let them build what they need.
Sometimes you might even use a scripting system where the main program is much smaller than the scripting system. For instance, I have a daemon which manages power allocation at a remote installation. It is written in go, and includes the functions to turn various systems on and off, measure current and voltage at different places, and the bare minimums of getting in and out of failsafe modes. All the rest of the decisions about what to turn on and off when and which system depends on which other system is all specified in a Lisp interpreter extension language and a config file. The end result is I wrote no lines of code to handle configuration, and extending the configuration involves no changes to the server. (Except if it needs a new function, like I had to add "time of sunrise" and "time of sunset" to the server since that was more Lisp than I was comfortable with.) Even in my simple configurations there is logic which would either be a nightmare or impossible in an Apache style config file but is simple in Lisp, even for a non-Lisp programmer like myself. (I chose the Lisp because it was a tiny implementation and written in Go so it was easy to build in. Not because I like it.)
It looks like the last bullet point on the page, so I'm not surprised that you missed it. They could definitely put this farther up the page:
"Wren is a scripting language. Wren is intended for embedding in applications. It has no dependencies, a small standard library, and an easy-to-use C API. It compiles cleanly as C99, C++98 or anything later."
