I would much much rather see a reboot of the MOO concepts (persistent object-oriented world, global time).
I know the existing LambdaMOO core and server are still being maintained, and web-ified, but even though I am something of a dissenter from the whole Rust trend, I'm very interested in this, which is going about it IMO the right way:
ToastStunt is an actively developed fork of Stunt which is a fork of LambdaMOO. It's extended a lot of what LambdaMOO offered via patches, as well as adding a lot of new and much needed stuff. Active Discord community as well. And several large MOOs are running it instead of LambdaMOO these days.
It's different than LambdaMOO because it's transactional (or will be). MOO had a global interpreter lock, was single threaded, and each user got a tick based time slice, so there was not really the possibility for state conflict, and there was concurrency but no real parallelism.
At its peak under heavy load on the machines we had back in the 90s, there was some really bad lag as we all waited in turn to f'ck up the world together.
In my system each task (command) gets a separate thread (well, tokio async thread, so not always a physical OS thread), which is its own fully snapshot isolated DB transaction. State is isolated MVCC style (eventually including all I/O) until commit. If the commit is not successful because of conflict the transaction is rolled back and retried , and the user is none-the-wiser.
It's all experimental of course, but I've spent the last ... some time ... working in and studying database tech, so I'm confident I can eventually make it scale. Right now it's just hoisted over RocksDB as a shim but I'm ... building my own thing on the side which will eventually perform/scale much better for the heavily concurrent multiple-writers scenario.
There's still VM opcode based ticks, as in MOO, and limits on them, but that's more of a resource control / time management system to prevent infinite loops and resource abuse and so on.
Fascinating, thanks for the explanation! Makes me wonder if anyone’s tried building a MOO in Erlang/Elixir or another actor-based system. (Though I’ve probably misunderstood how they’d help with the problem.)
If there's a commonly used (or uncommonly) runtime or language out there, someone has attempted to write a MOO in it. At least I have.
Finishing it, and getting other people to use it... that's another story. I've started building probably a half dozen or more systems over the last 25 years. Some have gotten further along than others, but none ever completed. And yeah, I played with Erlang for it at one point :-)
That's why I just threw my hands up in the air and said "F* it! I'll just make it fully LambdaMOO compatible." Because believe it or not there's still people using the LambdaMOO server (and "Stunt" and things like that) and various cores on it. I can hopefully get their interest; but also it gives you a suite of (really weird, aged, and sometimes questionable...) code to test against, and something to compare to for compliance.
The other thing is it makes sense to build such a system in a "systems" PL like Rust or C++, because it is actually a virtual machine, language runtime, database, has a garbage collector, etc. If you end up caring about performance (might not need to, to start), getting closer to the metal makes sense.
Ooh, all very interesting. I tried a simple experiment about 25 years back with a really, really lightweight green-threads library that I thought might work but I never really understood the synchronisation elements well enough.
I really think the world is kind of ready for a LambdaMOO/JHM system again so I will try to come back to play with it and I wish you well in the meantime!
Thanks. The core problem with making something like LambdaMOO multi-threaded is that once you introduce real parallelism you just end up with the potential for race conditions and deadlock. So you need some kind of isolation to make it work. And given that MOO is basically a ... database... it makes sense to crib from those notes.
These days, I'm not as huge of fan of the OO model MOO embraced. At least not in its pure form. While I'm implementing LambdaMOO slavishly compatible, it's more just to keep myself disciplined. I hope to go beyond it.
The 'fantasy' system I'd construct would be look more like a shared Prolog system than a shared Smalltalk/Self system. It'd be constructed around relations & first order logic. Relational but not crappy like SQL. You can build LambdaMOO on top of such a system, but not really the other way around. I just haven't mentally figured out what a sensible multiuser permissions model looks like in that scenario.
Have you thought about using Logtalk to implement this? The idea (or the parts I think I understood) is very interesting and out of systems environments I saw I think only Logtalk and Mozart/Oz offer features that could help in implementing it. Looking at your other posts, though, it looks like you're more interested in coding the entire system yourself instead of re-purposing something that already exists. :)
LambdaMOO straddled(straddles?) a fine line between being a more "serious" system that looks more like a multiuser Smalltalk & Lisp -- with a persistent shared networked database, a live shared programming / authoring environment with a prototype OO scripting language ... and a "less serious" MUD.
You can (but don't have to) build a MUD in it -- that's what people did -- but in the TinyM* style not usually RPG type games, more social systems.
But it was sitting on some very cool concepts, especially for its time. Predating the web, kind of another "path" that the Internet could have taken. It took the web 15 years to catch up to the idea of synchronous live interaction, and it's still more ... document based... than the kind of object/thing/room/narrative aspect we had going on in MOO.
It's very clearly inspired by Lisp, Self, and Smalltalk. And LambdaMOO itself was, back then, a hub of some pretty nifty people. 'twas my (embarassing mostly) adolescence. And they handed out "programmer" bits easily, so it was full of people's self-programmed creations.
The implementation certainly didn't age well. But the foundational concept is very cool. There were later iterations on the idea (CoolMUD, then ColdMUD/Genesis, a few other things) that refined things somewhat.
Others have alluded to LPmud/LPC which had some similar-ish things going on, but that was less "persistent shared creation environment" styled and more "source code in files in a decent OO language for making MUDs" with transient objects/state between world resets. People built MUDs, games, in LPmud, but as said MOOs (apart from some exceptions) were less about games and more about what we'd these days might consider a form of social networking.
Both were very cool, but MOO encouraged a more participatory programming environment, since you could just log in and start creating (cloning prototypes) and authoring (writing MOO "verbs" etc).
Separate comment for a separate thread maybe: there are also a few interesting things that "fell out" of MOO research.
One thing was AstroVR, which was an environment for collaborative control over telescopes. That had an advanced client called Jupiter, which PARC researchers IIRC used to develop a protocol (also called Jupiter?) that supported distributed interfaces and provided correct ordering of event messages.
Now I really regret not encountering MOOs back in the day. It looks like it captures the fun parts even better than the LPMUD I knew. You're right that restarts of the server wiped out some objects (some were persisted, of course, but it wasn't a full-blown object database). You're also right about LP being more game-oriented - though I personally couldn't care less, there were normal players running around killing stuff, leveling, role-playing, and all that.
Unfortunately, I didn't know English back then, and the only choice I had was between Diku and LP. Well, it's not too late, this thread got me intrigued enough to take a closer look at MOOs (and MOOR), I think :)
This is a better explanation than I would have managed. MOO's language model was fascinating.
The best part of 30 years ago I started some research (that I dropped out of) that would have built training environments on top of MOO and similar.
I started out by using the facility to open up a port from MOO and serve a webserver from inside it, that a Java applet integrated with. Which you could do, but something about the way it closed connections interfered with POST requests as I recall.
I loved exploring MediaMOO in particular, and I remember wanting to ask Amy Bruckman a bunch of questions about Moose Crossing; I'm not sure if I ever did. That was fascinating work.
MOOs, like MUSHes, were much more social spaces than games, though some of them had games built on top of them (e.g. LambdaMOO’s RPG). Unlike other systems, MOO was built on a remarkably powerful, multi-user runtime with its own programming language and object database.
What really made it special was that it exposed that programming language to its users, encouraging them to build wild and amazing new objects and interactions in a text-based virtual world. To program MOO, you didn’t need wizard/admin powers, you just needed Programner permissions, which were much easier to come by. Just follow a tutorial to get started (such as yduJ’s ever popular Wind-Up Duck) https://lelandra.com/joan/moocode.htm
The object runtime had some basic permissions around both ownership and types of interactions. They weren’t great, and a determined attacker could usually take the system down if they wanted, but they were enough to prevent most basic (and more importantly, accidental) kinds of mischief.
When you give the users of a social space the tools to build and play and extend the world, amazing things happen. With enough users, six ridiculously imaginative things happen before breakfast. There were games, bulletin boards, puppets, creatures, vehicles, and those are just the basics. I remember an IRC client that appeared as a pair of headphones: don them, you’re in a channel.
The wonder of what I'd seen stuck with me for many years afterwards. I ended up working at Linden Lab, the home of Second Life, because of it. SL, while amazing in many ways, was nowhere near as simple and fun as MOO. If you want (say) a goldfish-powered helicopter to crash into your room and transport you away, Second Life demands hours of modeling, coding, and animation. In MOO, a text-based world, you just type an emote.
The MOO programming environment made it wonderfully easy to glue verbs (i.e. object methods) to existing objects. I didn’t do much with it myself, but I did take a “throw” verb from a snowball, which could be thrown at anyone across the MOO, and attach it to a Creature, resulting in Fluff the Throwable Sheep. Others did far more interesting things; I’ll never forget Tabitha the Living Room, who reacted to things being said and done by the players sitting in her.
In 1993, LambdaMOO showed me what the internet would bring. While the World Wide Web took the concept of a shared, user-programmable social system a billion times further than MOO could ever dream of, I've never seen anything else demonstrate the idea as simply, consistently, and playfully.
One of the things that always tickled me in MediaMOO was the way that you could hook up a computer in your room, then climb in it, navigate through DNS like tunnels, and climb out of someone else's computer.
And there were rooms that functioned like mass transit -- a monorail I think?
Loved the elevator on LambdaMOO. Push the button to go down to 'hell' floor or whatever. Watching my friend work on programming around that kind of stuff taught me the basics of state machines and so on that took me from "played with BASIC & Pascal & Modula-2 as a kid" to "Sure, I'll write your CGI scripts and JavaBeans or whatever" and got me working in the industry eventually...
I know the existing LambdaMOO core and server are still being maintained, and web-ified, but even though I am something of a dissenter from the whole Rust trend, I'm very interested in this, which is going about it IMO the right way:
https://github.com/rdaum/moor
MOO was a good time.