Wren: a small, fast, class-based concurrent scripting language(munificent.github.io)
munificent.github.io
Wren: a small, fast, class-based concurrent scripting language
http://munificent.github.io/wren/
13 comments
Probably a homage to IO:
"features: BSD license , small vm (~10K semicolons), ..."
https://web.archive.org/web/20150101035218/http://iolanguage...
"features: BSD license , small vm (~10K semicolons), ..."
https://web.archive.org/web/20150101035218/http://iolanguage...
I've looked through the wren.io website, including the module documentation. As a scripting language, I would expect Wren to have decent regex support, but I find nothing there. Did I overlook it?
I use perl and python for building little utilities. I like the regularity of python over perl, but if I could get a clean syntax and it ran 4x faster with Wren, that would be great. But if there isn't a regex facility, it is a non-starter.
I use perl and python for building little utilities. I like the regularity of python over perl, but if I could get a clean syntax and it ran 4x faster with Wren, that would be great. But if there isn't a regex facility, it is a non-starter.
Are Wren fibers automatically distributed across available CPU cores or is it all single-threaded?
Single-threaded. The Wren VM itself is completely self-contained and has no global state. So, if you wanted to, you could host multiple VMs simultaneously, one for each thread, to get actual concurrency. You'd have to do the marshalling to move values from one to the other to get sharing or communication working, though.
If the VMs are self-contained, what mechanism would they use to communicate? id be ok to use marshaling if the marshaling itself is the dominating cost of communication.
> what mechanism would they use to communicate?
That's up to the program embedding them -- the idea is that you're the one implementing the communication and synchronization in the embedding program, rather than in Wren itself.
That's up to the program embedding them -- the idea is that you're the one implementing the communication and synchronization in the embedding program, rather than in Wren itself.
I would imagine some base shared memory copy on write queue system would help here immensely.
Exactly right.
I wish languages in this space would make it easier to create statically linked executables. With Lua you can do it yourself using squishy and a small main.c program, but it would be nice of the compiler just did it all for you.
For small cli apps, being able to write them in a pleasant to use language like Wren would be a big win.
For small cli apps, being able to write them in a pleasant to use language like Wren would be a big win.
Hmm – I'm working on some Windows API manipulations to provide a framework to make `macro scripts` (similar to AutHotKey or AutoIt), and in a few weeks I'll be looking to implement a scripting language. I've checked out LuaJIT, Lua 5.3, Lua w/Terra, AngelCode, Python, et al. and they all seem to have their faults. I actually need a language that supports both proper threading and co-routines, to respond to user-based key hooking (and good stuff like timers). This seems like it may be a good candidate, I don't mind contributing either. Bookmarked.
Bob: so no workstealing with native threads anymore, just tiny fibers?
looking forward to your jit. have a look at potion, it's really simple and fast.
looking forward to your jit. have a look at potion, it's really simple and fast.
A cute little language, but without the support of existing libraries, it can't gain mass adoption. It will take years to catch up with LuaJIT, and its vibrant ecosystem.
Isn't that true of every language ever? Surely Lua was in that position when it was young. That just doesn't sound like a reasonable objection to anything that's young
Of course, but how many years did it take for Lua to get there? Without piggybacking off existing libraries, prepare for a very long journey!
In general, the language does not matter much - the ecosystem does and it includes libraries, integrations, etc.
Duktape [0] in a similar position.
[0]: http://duktape.org/
In general, the language does not matter much - the ecosystem does and it includes libraries, integrations, etc.
Duktape [0] in a similar position.
[0]: http://duktape.org/
[deleted]
What is the performance like? Comparable to V8 javascript? Or maybe even comparable to LuaJIT?
Only comparable to LuaJIT with the jit off, because "Mike Pall is a robot from the future.": http://munificent.github.io/wren/performance.html
Wren's performance is pretty impressive!
fibers?
sounds like a duck named quacky.
I assume they mean this: https://en.wikipedia.org/wiki/Fiber_(computer_science)
The term is being used pretty accurately here. It's a cooperatively scheduled thread of execution (as opposed to preemptive scheduling, used in many operating systems and the Erlang VM).
Please don't post unsubstantive comments to HN.
So much anger.
The point is that developers should express themselves for a general audience. There is already sufficient macho separation between developers and the real world that we've just stepped into The Matrix.
The point here is we should aim for clarity and explanations instead of reappropriating words and meanings, often for truly random reasons.
Yes, I know what _fibers_ allude to in this context. I didn't like it when it was first used when I was younger either.
Too many exclusive high horses here, I think.
The point is that developers should express themselves for a general audience. There is already sufficient macho separation between developers and the real world that we've just stepped into The Matrix.
The point here is we should aim for clarity and explanations instead of reappropriating words and meanings, often for truly random reasons.
Yes, I know what _fibers_ allude to in this context. I didn't like it when it was first used when I was younger either.
Too many exclusive high horses here, I think.
Wren is great, I participated in the community for a while but then got on to different things. Glad to see it is still going strong.
Looks interesting, but I can't figure out where/for what it would be used. Am I missing something obvious?
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.
---
[1]: http://wren.io/qa.html#why-did-you-create-wren
---
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.
---
[1]: http://wren.io/qa.html#why-did-you-create-wren
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.
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.
For Thimbleweed Park, Ron Gilbert considered Lua but found it too "goofy" syntactically, and ended up using Squirrel.
https://blog.thimbleweedpark.com/engine
https://blog.thimbleweedpark.com/engine
> 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.
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.
An option that might be worth looking at is AngelScript, which I think minimizes the context switch between C++ and the scripting layer really nicely.
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.
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.
You'd be pretty constrained by what concepts of "object" to support, though.
Another thing I forgot to mention was tooling. With Lua you can already get debuggers, libraries and IDEs that other languages still lack.
What language bindings are available? Golang by chance?
No Go yet, but a couple:
https://github.com/munificent/wren/wiki/Language-Bindings
https://github.com/munificent/wren/wiki/Language-Bindings
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.)
• 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."
http://munificent.github.io/wren/
"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."
http://munificent.github.io/wren/
The fibers remind me of Elixir's processes. Elixir fascinated me at first, but I really didn't get into the groove of it after trying it out on a project.
Wren looks equally fascinating; perhaps it could warrant a trail project of its own.
Wren looks equally fascinating; perhaps it could warrant a trail project of its own.
I've never seen that used as a way to measure code size, but it's perfect for Cish code. That alone made this worth the click. And the language itself looks like something I wish I could have designed. Good show.