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:
MOO was a good time.
Contributions and opinions and musings are welcome.
How are you apportioning time with multiple threads? How do the ticks work?
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.
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.
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!
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. :)
There's also the old classic here: https://www.sciencedirect.com/science/article/pii/S074310669...
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).
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.
https://www.semanticscholar.org/paper/High-latency%2C-low-ba...
https://dl.acm.org/doi/fullHtml/10.1145/217279.215128
https://www.adass.org/adass/proceedings/adass94/vanburend1.h...
As far as I am aware, that work pretty heavily influenced SubEthaEdit and Google Wave.
And Pavel Curtis's team eventually ended up providing the backbone of the MS Office live meeting stuff.
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 :)
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.
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.
And there were rooms that functioned like mass transit -- a monorail I think?