5 ms·

Show HN: I rewrote the 1990's LambdaMOO server

174 points by cmrdporcupine 3y ago

I got my start on the Internet in the very early 90s playing with, authoring in, and programming on LambdaMOO (https://en.wikipedia.org/wiki/LambdaMOO https://en.wikipedia.org/wiki/LambdaMOO) and similar systems. Shared virtual social spaces, with a persistent object oriented authoring / scripting language. They can be classified as MUDs (depending on who you talk to) but the focus is social, creative / authoring, and shared programming not RPG gaming. I've always wanted to see this kind of thing modernized and further developed. Over the last 25 years or so I've worked on similar but novel & improved things, but never finished. So I decided to just re-implement LambdaMOO and use that as a base, instead and keep compatibility as a goal, but build it out on a more modern foundation that takes advantage of multiple core machines, newer network protocols, newer connectivity methods, uses MVCC transactions for the shared database etc. LambdaMOO is a somewhat extensive system in that it is composed of compiler, a virtual machine, an object database, user permissions system, network runtime. In some ways it's kind of like a shared, text-based Smalltalk image/runtime... So quite a bit to implement and get right before it all works together. The big challenge throughout has been slavishly maintaining backwards compatibility so existing "cores" (databases) work. It's not done, but it's darn close. Would like for people who are into this kind of thing to check it out, and maybe even help. Many of the technical aspects here are still provisional, but this is the start. Constructive assistance welcome. (Yes, it's a rewrite in Rust, but that's not really the point, even though that's a cliche that's fun.)

fleeno 3y ago
Is there anything else new or interesting going on in the Moo/Mu* space right now? A while back I wrote a MU*-style system in Ruby, using js as the scripting language. It has a web based tool that gives object owners a URL for each object, which lets them edit the attributes and code in a better way than just line oriented editing. It also lets external services call back to that object to trigger actions. I never did anything much with it though.
skulk 3y ago
I love seeing projects like this! I have one too, but it completely throws away compatibility and is very simplistic. I opted for a lisp-like language instead of a lua-like language (https://github.com/sid-code/nmoo https://github.com/sid-code/nmoo but don't look at the code, it's embarrassing). I have some questions: - Does each verb call create a whole new world state that it mutates, and later commits to the database? That's the impression I get from reading the code. Does this come with a lot of overhead? - What is that emacs mode you're using to edit verb code?
- cmrdporcupine 3y ago
  I've done the "whole new thing" before, too. 20ish years ago, tho I only have a few fragments of what I worked on back then: https://github.com/rdaum/mica https://github.com/rdaum/mica being one of them I found on an old drive. Not complete. But sticking with compatibility has allowed me to enforce development discipline, basically. And then I'll move it onwards from there. I have many ideas. And a product concept (if I could find an investor...). But I felt it important to start with a thing with existing foundation and use cases before doing the exciting stuff/changes. Re: world state / transactions -- yeah, basically all I/O and mutations happen in a transactional context, and then at commit time conflicts are resolved; if they're not resolve-able, the transaction is retried in a new state. As for overhead, yes potentially maybe a lot, but it's also a solvable problem; this is how an MVCC SQL database (like, even Postgres) works. TLDR it's likely inefficient now, but I believe I can make it efficient. And I think it's the best way to solve the shared world state problem and still meet user's expectations of consistency. Original LambdaMOO had a global interpreter lock and only one user was mutating the world at a time, in their given tick slice. Not gonna scale. Re: the MOO client, it's `rmoo.el`: https://github.com/lisdude/rmoo https://github.com/lisdude/rmoo -- it's been around for a long time (25, 30 years?) and it and/or MOO.el (another emacs one) are how/why I learned emacs in the first place. I had to minor patch my local copy to make it work with emacs 29.1, though I don't know elisp well enough to say whether my patch is the right thing to do or not, so... EDIT: I just re-read and saw you asked whether each new verb call creates a new state, and actually it's not that. It's each new command or network transaction, which can in fact lead to a chain of verb (method) calls. Recall a MUD has a command loop, so basically a transaction begins at command entry, and commits when all the invoked methods/verbs provoked from that complete.
  - derefr 3y ago
    > Original LambdaMOO had a global interpreter lock and only one user was mutating the world at a time, in their given tick slice. Not gonna scale. I’ve previously seen (abandoned) attempts to convert the Erlang runtime directly into a MOO runtime. Each command being a concurrent actor-process would make a lot of sense to me. (Though a semantics where all commands are MVCC against the at-inception world-state and will rollback or retry on conflict, kind of moots having any kind the advantage of a runtime based on message-passing, since you’re not going to be passing messages between separate concurrent “sessions.”)
clouddrover 3y ago
To see the original LambdaMOO in action: telnet lambda.moo.mud.org 8888
- tromp 3y ago
  Is there still a connect-4 game somewhere in a games room?
  - clouddrover 3y ago
    Yes, in the dining room: @go #28 There's Connect 4, Scrabble, Monopoly, backgammon, etc. Even Twister.
    - tromp 3y ago
      Decades ago I played LambdaMOO as Snap and programmed that game : examine Snap's connect-4 board Snap's connect-4 board (aka #36086, connect-4, and c4) Owned by Ger. White (O) to play. . . . . . . . . . . O . . . . . X O X . . . . O O O . . . O X X X O . . X X O X X . 1 2 3 4 5 6 7 How can O win here:-?
- deleted 3y ago
  [deleted]
NelsonMinar 3y ago
Wow neat! LambdaMOO was such an influential thing for. MUDs in general had a lot of influence, both in social media and gaming. And then LambdaMOO had the specific brief of being a social media experiment. Neat to see the tech reborn! Pavel Curtis is still out there, LinkedIn says he recently left his job at Microsoft after 20 years. He also runs a puzzle shop: http://www.pavelspuzzles.com/site/ http://www.pavelspuzzles.com/site/
- sshumaker 3y ago
  I talked to Pavel about taking a role in my team earlier this year (I ended up leaving Microsoft myself since). He was passionate about making the developer experience excellent - code quality, clean APIs, etc. Thats a tall order for some parts of Microsoft with 30+-year old codebases. He mentioned he was interested in rockets so I hope he found a gig doing that.
trollied 3y ago
Hands up if you know what tinyfugue is :)
- VadimPR 3y ago
  Mudlet represent :)
- cmrdporcupine 3y ago
  I almost used it in the screenshot, but the live editing of code with emacs is way hotter :-) Check out blightmud. It's kind of tinyfuge-the-next-generation.
  - smirya0 3y ago
    Nice. I still use VMOO (anyone remember VMOO)! Is that rmoo/emacs on Fedora? There's a nice collection of MOO resources: https://lisdude.com/moo/ https://lisdude.com/moo/ It is too bad some of the old MOO dbs like ScrabbleMOO and NYC MOO are lost to history...
    - cmrdporcupine 3y ago
      Is VMOO still available for download? I never used it ever but I was looking to show my 13 year old son LambdaMOO yesterday and I couldn't find a user friendly GUI client for him to run on Windows. I wasn't going to unleash emacs on him, and tkMOO isn't ideal, either.
      - clouddrover 3y ago
        You can try MUSHclient. You'll have to fiddle with it to make it go under Windows 7 and later. There are linked install instructions on the page: http://mushclient.com/downloads/dlmushclient.htm http://mushclient.com/downloads/dlmushclient.htm
      - filchermcurr 3y ago
        https://web.archive.org/web/20201203080354/http://www.vmoo.com/.dwl/pro/vmoo0920.exe https://web.archive.org/web/20201203080354/http://www.vmoo.c... Looks like the VMoo website is still there but is having... issues. But this is the last release. If you have a high DPI display you may find it slightly lacking, even with Windows compatibility settings applied. Which is a shame because VMoo was always the best client. Most GUI-users use Mudlet (https://www.mudlet.org/ https://www.mudlet.org/) these days. Unfortunately, as far as I know, it lacks proper local editing support. If you're feeling adventurous you can work around that with something like MUDMixer (https://github.com/tms88/mudmixer https://github.com/tms88/mudmixer) to proxy local editing.
dang 3y ago
Related: LambdaMOO Takes a New Direction (1992) - https://news.ycombinator.com/item?id=35856654 https://news.ycombinator.com/item?id=35856654 - May 2023 (15 comments) LambdaMOO takes a new direction (1992) - https://news.ycombinator.com/item?id=22680965 https://news.ycombinator.com/item?id=22680965 - March 2020 (29 comments) Lambda MOO Programming - https://news.ycombinator.com/item?id=20405167 https://news.ycombinator.com/item?id=20405167 - July 2019 (1 comment) Lambda MOO Programming Resources - https://news.ycombinator.com/item?id=16327975 https://news.ycombinator.com/item?id=16327975 - Feb 2018 (1 comment) Exploring 3-Move – A LambdaMOO inspired environment - https://news.ycombinator.com/item?id=14075439 https://news.ycombinator.com/item?id=14075439 - April 2017 (15 comments) --- The "new direction" article was made famous by Clay Shirky in "A group is its own worst enemy". I won't list those here since it's a generic tangent but there are past threads at https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=comments%3E0%20%22a%20group%20is%20its%20own%20worst%20enemy%22&sort=byDate&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que....
- Alex3917 3y ago
  Also, the article A Rape in Cyberspace is about something that happened in LambdaMoo, and is one of the most famous articles ever written about the Internet: https://www.villagevoice.com/a-rape-in-cyberspace/ https://www.villagevoice.com/a-rape-in-cyberspace/ It looks like it's been submitted to HN several times, but has never gotten many upvotes.
  - DicIfTEx 3y ago
    “A Rape in Cyberspace” was later collected into a book called My Tiny Life: Crime and Passion in a Virtual World, all about the author's relationships and experiences in LamdaMOO. Highly recommend.
    - grimgrin 3y ago
      In case you missed it, OP was _there_ cmrdporcupine 18 hours ago: > "I was there, Gandalf, 3000 years ago" > From "A Rape In Cyberspace: "no hate, no anger, no interest at all. Just…watching. Others were more actively unfriendly. “Asshole,” spat Karl Porcupine, “creep.” But the harshest of the MOO’.. " > I was Karl Porcupine. Quite young then, though.
Shekelphile 3y ago
Good luck. As someone who used to work on a lambda-derived MUD it's great to see a little life left in that community. The original server was horribly outdated even 20 years ago. I also found this project randomly on github at one point, not sure how far along it got to being usable: https://github.com/verement/etamoo https://github.com/verement/etamoo
- cmrdporcupine 3y ago
  Yes it's funny I came across that one only a couple weeks ago -- I may have had wind of it before but it didn't sink in -- and it's basically what I'm doing (well at least the first part of what I'm doing)... but in Haskell. It looks like the author got pretty far along, too. But no new commits in some time. If I'd seen that a year ago, I'm not sure I would have started. Hard to say. I admire Haskell, but I could never really grok it.
deleted 3y ago
[deleted]
deleted 3y ago
[deleted]
smirya0 3y ago
Very cool! Is it still using cooperative multitasking? My understanding was MOO verbs/tasks run until the verb does suspend/fork or an input() call happens or something like that, or until the verb runs out of "ticks" and is killed by the VM. How do you do it? Does it use async I/O / is it one thread still? You might find this conversation interesting about multi-threading in LambdaMOO: https://groups.google.com/g/moo-talk/c/omF68ZM9rZc/m/B3f-jj4SBwAJ https://groups.google.com/g/moo-talk/c/omF68ZM9rZc/m/B3f-jj4...
- cmrdporcupine 3y ago
  It's multithreaded with multiversion concurrency control over shared state. Each command invocation is a new thread, in a new transaction, and the database attempts to resolve any shared state conflicts at commit time. There's still ticks and time limits, but they're there to impose time / resource limits, not used to control access to shared state. Tick-based time-slicing to the database is one reason why LambdaMOO (and its offshoots like toaststunt, etc.) has intrinsic scalability limits. (In the 90s, LambdaMOO-the-actual-MOO used to lag like a son of a bitch under load...) (This is not to say the actual impl of MVCC I have right now is ideal. It's a work in progress. I just defer to RocksDB's conflict resolution, and it is built on assumptions of "single writer, multiple readers" at its foundation, which isn't ideal for what I'm doing... )
  - miki123211 3y ago
    Can this transactional model be made to handle in-transaction I/O? I've seen MOOs that had verbs for performing HTTP requests, through shelling out to curl IIRC. If you have a verb that reads a value, sends it out and updates it based on the response, what do you do if the value changes in the meantime? When is the transaction committed exactly?
    - cmrdporcupine 3y ago
      I won't be providing outbound HTTP (or inbound) requests via MOO code. The only I/O is what is provided through the Session interface which is, yes, transactional; all I/O "effects" are buffered and committed or reverted after the same at the DB level. Inbound HTTP is provided at the Rust layer in front of a standardized RPC interface over 0MQ and goes through the same set of transactional semantics as all other commands: The transaction gets committed at the end of command execution, and then all the I/O that "occurred" in the narrative log gets output to its destinations. If a serialization conflict occurred, the output buffers (and all other mutations) are discarded, and everything retried, again. (In theory. Right now it just rolls back and barfs, because I have not finished this layer yet :-) ) Where this falls over is with MOO's synchronous "read" builtin, which is used in places for e.g. password changes or prompts. This is something I have not tackled yet, but will probably just have to deprecate, and will be one of the only things breaking compatibility with existing cores. Alternatively I could or might provide a transaction mode which is "softer" for tasks that need that kind of dependent input. It will require some thought. But on the whole MOO's model is similar to a database: In a DB it's query in, commit, see results; in my system in it's command parse, execute verb, commit, flush I/O results out.
gilmore606 3y ago
How are you handling concurrency/multithreading? I wrote a lot of MOOcode back in the day and often explicitly relied on the fact that property values couldn't change out from under me during a verb's runtime.
- cmrdporcupine 3y ago
  Like a database (because it is one). MVCC. Full transactional isolation. Nobody sees your changes until successful commit. This is what MOO was effectively mostly doing already, through a big ol' single threaded interpreter we all took turns on. Only one task was running at a time (sort of, you could suspend() and return later, and then all bets were off on consistency). It's just... that doesn't really scale too well.
nrr 3y ago
This makes me smile a lot. Whenever I pick up a new programming language, one of the first projects I tackle is writing a port of a similar MU* server because of the same breadth of concerns, so it's very nice seeing someone else recognize the complexity and take it on as a worthy challenge. (Though, this goes the extra mile and modernizes things; I've seldom accomplished that.) I hadn't looked at doing this in Rust yet, so it'll definitely be interesting to give the code a read, particularly with the focus toward modernization.
mindcrime 3y ago
I've always wanted to see this kind of thing modernized and further developed. I've had similar thoughts, so let me say "Congrats, this is awesome"! It definitely warms the cockles of my heart to see work like this. I just wish I had the free cycles to work on something similar (or even contribute to your project). But there are too many demands on my time right now. :-(
branon 3y ago
There's a great book about the original instance of this software, https://www.amazon.com/My-Tiny-Life-Passion-Virtual/dp/0805036261 https://www.amazon.com/My-Tiny-Life-Passion-Virtual/dp/08050... fun old internet flamewars and a lot of discussion about the gender spectrum and how it's expressed by individuals online.
- cmrdporcupine 3y ago
  "I was there, Gandalf, 3000 years ago" From "A Rape In Cyberspace: "no hate, no anger, no interest at all. Just…watching. Others were more actively unfriendly. “Asshole,” spat Karl Porcupine, “creep.” But the harshest of the MOO’.. " I was Karl Porcupine. Quite young then, though.
  - grimgrin 3y ago
    Remarkable, Just the other day a friend went to a concert, Mr. Bungle, and so ended up on wrong wiki: https://en.wikipedia.org/wiki/A_Rape_in_Cyberspace https://en.wikipedia.org/wiki/A_Rape_in_Cyberspace So I went down that rabbit hole, read the essay, bought the book, and days later here appears Karl Porcupine
    - cmrdporcupine 3y ago
      Hopefully that's the only documentation of my awkward teenage LambdaMOO days still in existence...
deleted 3y ago
[deleted]
fzzzy 3y ago
There's a fork called stunt / improvise that implements hashmaps. I'd love it if the list syntax was changed to use square brackets, and then if the hashmap syntax could be curly braces. I've also wanted to give each object an isolated environment (make each one an actor), but I haven't thought too deeply about how exactly that would work and look. I've been planning in the back of my head to do this at some point in the next year, and was planning on implementing on top of the original codebase, but if there's a rust version, I'll use that. I know it wouldn't be compatible with existing cores, but I'd be using it as the backend for a graphical ui anyway. How did you go about converting the code? Did you just read through it, or did you start with a c to rust tool? I always thought the programmers manual and codebase were quite concise and readable. One last thing, there were patches in the 90s to add journaling on top of the checkpoint system... Did those ever get merged into the main codebase? Thanks for doing this! I'm excited!
- fzzzy 3y ago
  I see after reading more that it has a modern concurrency and object database implementation. Really cool! Websockets and utf8 as well. Lovely.
- cmrdporcupine 3y ago
  "How did you go about converting the code?" Mixture of approaches. No automatic translation. After bringing over the AST and opcodes, etc most of it I wrote without reference to the original code, with the functionality in mind. Where MOO was doing something a bit funky, I often wrote code with a second window open to look at how they were doing it. But in general it came down to running a core over and over again and finding how it broke. MOO has some unexpected behaviours in spots that grew over time. If I were to start over with this, I'd invest the energy in ripping out parts of MOO and turning them into a library and then write tests that run them side by side through the same opcode sequence and compare output. But MOO was built quite monolithic, so that's hard. Re: maps, MOO's value types are immutable/copy-on-write. So while I want a map type, a typical HashMap may not make a lot of sense, as it would be doing a deep copy on each addition. Some kind of functional persistent map would probably be appropriate. Syntactical sugar for maps would be nice, and I will probably add it later. But I'm also not as concerned with the MOO language itself, as I see it as only one language among potentially many to run on the system. "I've also wanted to give each object an isolated environment (make each one an actor)" Maybe related; I intend on reworking the object reference system such that object numbers and $sysobj-references are a form of published capabilities. That is, I will be introducing "private" objects with some sort of signing & publishing & capability style references, and slowly deprecating object numbers. But that's all post 1.0 stuff.
jonmarkgo 3y ago
This is very cool! I have a MUD (that still has a fairly active playerbase) written in straight-up C. Been working on it 20+ years now, and always had some curiosity about rewriting it.
zellyn 3y ago
I'm so happy someone did this. Rewriting LambdaMOO was on my long-term (mostly not going to do before I die) TODO list of project ideas! https://zellyn.com/page/projects/todo/ https://zellyn.com/page/projects/todo/ Very fun. I expect the parallelism will also be strikingly better with a modern design and implementation! Very nice!
thelibrarian 3y ago
For a name, how about LambdaROOM? Adds an 'R' for Rust, and is also a reference to the concepts of rooms in these games.
- worthless443 3y ago
  Personally I wouldn't make one part of the name linked to the underlying development language, we make software for the users, and the source is often not part of something users have to deal with. Just as is sounds good in my opinion.
  - cmrdporcupine 3y ago
    Yeah I agree with this, I don't care to emphasize the Rust thing. I actually had a previous incantation of this project I called 'room' -- but that's too generic. Also don't care to have 'lambda' in the name, since the point here is this is really a net-new impl of the MOO runtime not derived/forked from the LambdaMOO sources (though compatible, at least to start.) In fact MOO itself is also not necessarily something to emphasize because because the idea (after 1.0) is to support other language runtimes to run in the same shared persistent authoring environment. MOO support is just the initial 'hook'. And I wouldn't emphasize the OO thing either. My intent is to explore a more logic/relational oriented model going forward. And "OO" kinda means something different now than it did back then when MOO started before things ossifying into the class-based dispatch model of Java/C++ etc. It might just be I need something entirely arbitrary and brand-ish. Naming things is hard.
cpeterso 3y ago
Suggested alternative names: “rooms” or “rumor”.
rhinoceraptor 3y ago
I do some maintenance for a pretty old LambdaMOO instance that runs enCore, which gives it a (very 90s) web UI, along with a browser-based telnet client. Of course, that telnet client was a Java applet, so I replaced it with a websocket console, and a websocket server that proxies telnet to LambdaMOO. One of the bigger challenges with the web UI is that HTTPS isn't really optional anymore, and the enCore database has a ton of `http:// http://` links. So it requires a reverse proxy in front that can rewrite those, luckily in Nginx it's possible to use a small Javascript program to do it.

174 points by cmrdporcupine 3y ago

fleeno 3y ago

Is there anything else new or interesting going on in the Moo/Mu* space right now? A while back I wrote a MU*-style system in Ruby, using js as the scripting language. It has a web based tool that gives object owners a URL for each object, which lets them edit the attributes and code in a better way than just line oriented editing. It also lets external services call back to that object to trigger actions. I never did anything much with it though.

skulk 3y ago

I love seeing projects like this! I have one too, but it completely throws away compatibility and is very simplistic. I opted for a lisp-like language instead of a lua-like language (https://github.com/sid-code/nmoo https://github.com/sid-code/nmoo but don't look at the code, it's embarrassing). I have some questions: - Does each verb call create a whole new world state that it mutates, and later commits to the database? That's the impression I get from reading the code. Does this come with a lot of overhead? - What is that emacs mode you're using to edit verb code?

cmrdporcupine 3y ago
I've done the "whole new thing" before, too. 20ish years ago, tho I only have a few fragments of what I worked on back then: https://github.com/rdaum/mica https://github.com/rdaum/mica being one of them I found on an old drive. Not complete. But sticking with compatibility has allowed me to enforce development discipline, basically. And then I'll move it onwards from there. I have many ideas. And a product concept (if I could find an investor...). But I felt it important to start with a thing with existing foundation and use cases before doing the exciting stuff/changes. Re: world state / transactions -- yeah, basically all I/O and mutations happen in a transactional context, and then at commit time conflicts are resolved; if they're not resolve-able, the transaction is retried in a new state. As for overhead, yes potentially maybe a lot, but it's also a solvable problem; this is how an MVCC SQL database (like, even Postgres) works. TLDR it's likely inefficient now, but I believe I can make it efficient. And I think it's the best way to solve the shared world state problem and still meet user's expectations of consistency. Original LambdaMOO had a global interpreter lock and only one user was mutating the world at a time, in their given tick slice. Not gonna scale. Re: the MOO client, it's `rmoo.el`: https://github.com/lisdude/rmoo https://github.com/lisdude/rmoo -- it's been around for a long time (25, 30 years?) and it and/or MOO.el (another emacs one) are how/why I learned emacs in the first place. I had to minor patch my local copy to make it work with emacs 29.1, though I don't know elisp well enough to say whether my patch is the right thing to do or not, so... EDIT: I just re-read and saw you asked whether each new verb call creates a new state, and actually it's not that. It's each new command or network transaction, which can in fact lead to a chain of verb (method) calls. Recall a MUD has a command loop, so basically a transaction begins at command entry, and commits when all the invoked methods/verbs provoked from that complete.
- derefr 3y ago
  > Original LambdaMOO had a global interpreter lock and only one user was mutating the world at a time, in their given tick slice. Not gonna scale. I’ve previously seen (abandoned) attempts to convert the Erlang runtime directly into a MOO runtime. Each command being a concurrent actor-process would make a lot of sense to me. (Though a semantics where all commands are MVCC against the at-inception world-state and will rollback or retry on conflict, kind of moots having any kind the advantage of a runtime based on message-passing, since you’re not going to be passing messages between separate concurrent “sessions.”)

clouddrover 3y ago

To see the original LambdaMOO in action: telnet lambda.moo.mud.org 8888

tromp 3y ago
Is there still a connect-4 game somewhere in a games room?
- clouddrover 3y ago
  Yes, in the dining room: @go #28 There's Connect 4, Scrabble, Monopoly, backgammon, etc. Even Twister.
  - tromp 3y ago
    Decades ago I played LambdaMOO as Snap and programmed that game : examine Snap's connect-4 board Snap's connect-4 board (aka #36086, connect-4, and c4) Owned by Ger. White (O) to play. . . . . . . . . . . O . . . . . X O X . . . . O O O . . . O X X X O . . X X O X X . 1 2 3 4 5 6 7 How can O win here:-?
deleted 3y ago
[deleted]

NelsonMinar 3y ago

Wow neat! LambdaMOO was such an influential thing for. MUDs in general had a lot of influence, both in social media and gaming. And then LambdaMOO had the specific brief of being a social media experiment. Neat to see the tech reborn! Pavel Curtis is still out there, LinkedIn says he recently left his job at Microsoft after 20 years. He also runs a puzzle shop: http://www.pavelspuzzles.com/site/ http://www.pavelspuzzles.com/site/

sshumaker 3y ago
I talked to Pavel about taking a role in my team earlier this year (I ended up leaving Microsoft myself since). He was passionate about making the developer experience excellent - code quality, clean APIs, etc. Thats a tall order for some parts of Microsoft with 30+-year old codebases. He mentioned he was interested in rockets so I hope he found a gig doing that.

trollied 3y ago

Hands up if you know what tinyfugue is :)

VadimPR 3y ago
Mudlet represent :)
cmrdporcupine 3y ago
I almost used it in the screenshot, but the live editing of code with emacs is way hotter :-) Check out blightmud. It's kind of tinyfuge-the-next-generation.
- smirya0 3y ago
  Nice. I still use VMOO (anyone remember VMOO)! Is that rmoo/emacs on Fedora? There's a nice collection of MOO resources: https://lisdude.com/moo/ https://lisdude.com/moo/ It is too bad some of the old MOO dbs like ScrabbleMOO and NYC MOO are lost to history...
  - cmrdporcupine 3y ago
    Is VMOO still available for download? I never used it ever but I was looking to show my 13 year old son LambdaMOO yesterday and I couldn't find a user friendly GUI client for him to run on Windows. I wasn't going to unleash emacs on him, and tkMOO isn't ideal, either.
    - clouddrover 3y ago
      You can try MUSHclient. You'll have to fiddle with it to make it go under Windows 7 and later. There are linked install instructions on the page: http://mushclient.com/downloads/dlmushclient.htm http://mushclient.com/downloads/dlmushclient.htm
    - filchermcurr 3y ago
      https://web.archive.org/web/20201203080354/http://www.vmoo.com/.dwl/pro/vmoo0920.exe https://web.archive.org/web/20201203080354/http://www.vmoo.c... Looks like the VMoo website is still there but is having... issues. But this is the last release. If you have a high DPI display you may find it slightly lacking, even with Windows compatibility settings applied. Which is a shame because VMoo was always the best client. Most GUI-users use Mudlet (https://www.mudlet.org/ https://www.mudlet.org/) these days. Unfortunately, as far as I know, it lacks proper local editing support. If you're feeling adventurous you can work around that with something like MUDMixer (https://github.com/tms88/mudmixer https://github.com/tms88/mudmixer) to proxy local editing.

dang 3y ago

Related: LambdaMOO Takes a New Direction (1992) - https://news.ycombinator.com/item?id=35856654 https://news.ycombinator.com/item?id=35856654 - May 2023 (15 comments) LambdaMOO takes a new direction (1992) - https://news.ycombinator.com/item?id=22680965 https://news.ycombinator.com/item?id=22680965 - March 2020 (29 comments) Lambda MOO Programming - https://news.ycombinator.com/item?id=20405167 https://news.ycombinator.com/item?id=20405167 - July 2019 (1 comment) Lambda MOO Programming Resources - https://news.ycombinator.com/item?id=16327975 https://news.ycombinator.com/item?id=16327975 - Feb 2018 (1 comment) Exploring 3-Move – A LambdaMOO inspired environment - https://news.ycombinator.com/item?id=14075439 https://news.ycombinator.com/item?id=14075439 - April 2017 (15 comments) --- The "new direction" article was made famous by Clay Shirky in "A group is its own worst enemy". I won't list those here since it's a generic tangent but there are past threads at https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=comments%3E0%20%22a%20group%20is%20its%20own%20worst%20enemy%22&sort=byDate&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que....

Alex3917 3y ago
Also, the article A Rape in Cyberspace is about something that happened in LambdaMoo, and is one of the most famous articles ever written about the Internet: https://www.villagevoice.com/a-rape-in-cyberspace/ https://www.villagevoice.com/a-rape-in-cyberspace/ It looks like it's been submitted to HN several times, but has never gotten many upvotes.
- DicIfTEx 3y ago
  “A Rape in Cyberspace” was later collected into a book called My Tiny Life: Crime and Passion in a Virtual World, all about the author's relationships and experiences in LamdaMOO. Highly recommend.
  - grimgrin 3y ago
    In case you missed it, OP was _there_ cmrdporcupine 18 hours ago: > "I was there, Gandalf, 3000 years ago" > From "A Rape In Cyberspace: "no hate, no anger, no interest at all. Just…watching. Others were more actively unfriendly. “Asshole,” spat Karl Porcupine, “creep.” But the harshest of the MOO’.. " > I was Karl Porcupine. Quite young then, though.

Shekelphile 3y ago

Good luck. As someone who used to work on a lambda-derived MUD it's great to see a little life left in that community. The original server was horribly outdated even 20 years ago. I also found this project randomly on github at one point, not sure how far along it got to being usable: https://github.com/verement/etamoo https://github.com/verement/etamoo

cmrdporcupine 3y ago
Yes it's funny I came across that one only a couple weeks ago -- I may have had wind of it before but it didn't sink in -- and it's basically what I'm doing (well at least the first part of what I'm doing)... but in Haskell. It looks like the author got pretty far along, too. But no new commits in some time. If I'd seen that a year ago, I'm not sure I would have started. Hard to say. I admire Haskell, but I could never really grok it.

deleted 3y ago

[deleted]

deleted 3y ago

[deleted]

smirya0 3y ago

Very cool! Is it still using cooperative multitasking? My understanding was MOO verbs/tasks run until the verb does suspend/fork or an input() call happens or something like that, or until the verb runs out of "ticks" and is killed by the VM. How do you do it? Does it use async I/O / is it one thread still? You might find this conversation interesting about multi-threading in LambdaMOO: https://groups.google.com/g/moo-talk/c/omF68ZM9rZc/m/B3f-jj4SBwAJ https://groups.google.com/g/moo-talk/c/omF68ZM9rZc/m/B3f-jj4...

cmrdporcupine 3y ago
It's multithreaded with multiversion concurrency control over shared state. Each command invocation is a new thread, in a new transaction, and the database attempts to resolve any shared state conflicts at commit time. There's still ticks and time limits, but they're there to impose time / resource limits, not used to control access to shared state. Tick-based time-slicing to the database is one reason why LambdaMOO (and its offshoots like toaststunt, etc.) has intrinsic scalability limits. (In the 90s, LambdaMOO-the-actual-MOO used to lag like a son of a bitch under load...) (This is not to say the actual impl of MVCC I have right now is ideal. It's a work in progress. I just defer to RocksDB's conflict resolution, and it is built on assumptions of "single writer, multiple readers" at its foundation, which isn't ideal for what I'm doing... )
- miki123211 3y ago
  Can this transactional model be made to handle in-transaction I/O? I've seen MOOs that had verbs for performing HTTP requests, through shelling out to curl IIRC. If you have a verb that reads a value, sends it out and updates it based on the response, what do you do if the value changes in the meantime? When is the transaction committed exactly?
  - cmrdporcupine 3y ago
    I won't be providing outbound HTTP (or inbound) requests via MOO code. The only I/O is what is provided through the Session interface which is, yes, transactional; all I/O "effects" are buffered and committed or reverted after the same at the DB level. Inbound HTTP is provided at the Rust layer in front of a standardized RPC interface over 0MQ and goes through the same set of transactional semantics as all other commands: The transaction gets committed at the end of command execution, and then all the I/O that "occurred" in the narrative log gets output to its destinations. If a serialization conflict occurred, the output buffers (and all other mutations) are discarded, and everything retried, again. (In theory. Right now it just rolls back and barfs, because I have not finished this layer yet :-) ) Where this falls over is with MOO's synchronous "read" builtin, which is used in places for e.g. password changes or prompts. This is something I have not tackled yet, but will probably just have to deprecate, and will be one of the only things breaking compatibility with existing cores. Alternatively I could or might provide a transaction mode which is "softer" for tasks that need that kind of dependent input. It will require some thought. But on the whole MOO's model is similar to a database: In a DB it's query in, commit, see results; in my system in it's command parse, execute verb, commit, flush I/O results out.

gilmore606 3y ago

How are you handling concurrency/multithreading? I wrote a lot of MOOcode back in the day and often explicitly relied on the fact that property values couldn't change out from under me during a verb's runtime.

cmrdporcupine 3y ago
Like a database (because it is one). MVCC. Full transactional isolation. Nobody sees your changes until successful commit. This is what MOO was effectively mostly doing already, through a big ol' single threaded interpreter we all took turns on. Only one task was running at a time (sort of, you could suspend() and return later, and then all bets were off on consistency). It's just... that doesn't really scale too well.

nrr 3y ago

This makes me smile a lot. Whenever I pick up a new programming language, one of the first projects I tackle is writing a port of a similar MU* server because of the same breadth of concerns, so it's very nice seeing someone else recognize the complexity and take it on as a worthy challenge. (Though, this goes the extra mile and modernizes things; I've seldom accomplished that.) I hadn't looked at doing this in Rust yet, so it'll definitely be interesting to give the code a read, particularly with the focus toward modernization.

mindcrime 3y ago

I've always wanted to see this kind of thing modernized and further developed. I've had similar thoughts, so let me say "Congrats, this is awesome"! It definitely warms the cockles of my heart to see work like this. I just wish I had the free cycles to work on something similar (or even contribute to your project). But there are too many demands on my time right now. :-(

branon 3y ago

There's a great book about the original instance of this software, https://www.amazon.com/My-Tiny-Life-Passion-Virtual/dp/0805036261 https://www.amazon.com/My-Tiny-Life-Passion-Virtual/dp/08050... fun old internet flamewars and a lot of discussion about the gender spectrum and how it's expressed by individuals online.

cmrdporcupine 3y ago
"I was there, Gandalf, 3000 years ago" From "A Rape In Cyberspace: "no hate, no anger, no interest at all. Just…watching. Others were more actively unfriendly. “Asshole,” spat Karl Porcupine, “creep.” But the harshest of the MOO’.. " I was Karl Porcupine. Quite young then, though.
- grimgrin 3y ago
  Remarkable, Just the other day a friend went to a concert, Mr. Bungle, and so ended up on wrong wiki: https://en.wikipedia.org/wiki/A_Rape_in_Cyberspace https://en.wikipedia.org/wiki/A_Rape_in_Cyberspace So I went down that rabbit hole, read the essay, bought the book, and days later here appears Karl Porcupine
  - cmrdporcupine 3y ago
    Hopefully that's the only documentation of my awkward teenage LambdaMOO days still in existence...

deleted 3y ago

[deleted]

fzzzy 3y ago

There's a fork called stunt / improvise that implements hashmaps. I'd love it if the list syntax was changed to use square brackets, and then if the hashmap syntax could be curly braces. I've also wanted to give each object an isolated environment (make each one an actor), but I haven't thought too deeply about how exactly that would work and look. I've been planning in the back of my head to do this at some point in the next year, and was planning on implementing on top of the original codebase, but if there's a rust version, I'll use that. I know it wouldn't be compatible with existing cores, but I'd be using it as the backend for a graphical ui anyway. How did you go about converting the code? Did you just read through it, or did you start with a c to rust tool? I always thought the programmers manual and codebase were quite concise and readable. One last thing, there were patches in the 90s to add journaling on top of the checkpoint system... Did those ever get merged into the main codebase? Thanks for doing this! I'm excited!

fzzzy 3y ago
I see after reading more that it has a modern concurrency and object database implementation. Really cool! Websockets and utf8 as well. Lovely.
cmrdporcupine 3y ago
"How did you go about converting the code?" Mixture of approaches. No automatic translation. After bringing over the AST and opcodes, etc most of it I wrote without reference to the original code, with the functionality in mind. Where MOO was doing something a bit funky, I often wrote code with a second window open to look at how they were doing it. But in general it came down to running a core over and over again and finding how it broke. MOO has some unexpected behaviours in spots that grew over time. If I were to start over with this, I'd invest the energy in ripping out parts of MOO and turning them into a library and then write tests that run them side by side through the same opcode sequence and compare output. But MOO was built quite monolithic, so that's hard. Re: maps, MOO's value types are immutable/copy-on-write. So while I want a map type, a typical HashMap may not make a lot of sense, as it would be doing a deep copy on each addition. Some kind of functional persistent map would probably be appropriate. Syntactical sugar for maps would be nice, and I will probably add it later. But I'm also not as concerned with the MOO language itself, as I see it as only one language among potentially many to run on the system. "I've also wanted to give each object an isolated environment (make each one an actor)" Maybe related; I intend on reworking the object reference system such that object numbers and $sysobj-references are a form of published capabilities. That is, I will be introducing "private" objects with some sort of signing & publishing & capability style references, and slowly deprecating object numbers. But that's all post 1.0 stuff.

jonmarkgo 3y ago

This is very cool! I have a MUD (that still has a fairly active playerbase) written in straight-up C. Been working on it 20+ years now, and always had some curiosity about rewriting it.

zellyn 3y ago

I'm so happy someone did this. Rewriting LambdaMOO was on my long-term (mostly not going to do before I die) TODO list of project ideas! https://zellyn.com/page/projects/todo/ https://zellyn.com/page/projects/todo/ Very fun. I expect the parallelism will also be strikingly better with a modern design and implementation! Very nice!

thelibrarian 3y ago

For a name, how about LambdaROOM? Adds an 'R' for Rust, and is also a reference to the concepts of rooms in these games.

worthless443 3y ago
Personally I wouldn't make one part of the name linked to the underlying development language, we make software for the users, and the source is often not part of something users have to deal with. Just as is sounds good in my opinion.
- cmrdporcupine 3y ago
  Yeah I agree with this, I don't care to emphasize the Rust thing. I actually had a previous incantation of this project I called 'room' -- but that's too generic. Also don't care to have 'lambda' in the name, since the point here is this is really a net-new impl of the MOO runtime not derived/forked from the LambdaMOO sources (though compatible, at least to start.) In fact MOO itself is also not necessarily something to emphasize because because the idea (after 1.0) is to support other language runtimes to run in the same shared persistent authoring environment. MOO support is just the initial 'hook'. And I wouldn't emphasize the OO thing either. My intent is to explore a more logic/relational oriented model going forward. And "OO" kinda means something different now than it did back then when MOO started before things ossifying into the class-based dispatch model of Java/C++ etc. It might just be I need something entirely arbitrary and brand-ish. Naming things is hard.

cpeterso 3y ago

Suggested alternative names: “rooms” or “rumor”.

rhinoceraptor 3y ago

I do some maintenance for a pretty old LambdaMOO instance that runs enCore, which gives it a (very 90s) web UI, along with a browser-based telnet client. Of course, that telnet client was a Java applet, so I replaced it with a websocket console, and a websocket server that proxies telnet to LambdaMOO. One of the bigger challenges with the web UI is that HTTPS isn't really optional anymore, and the enCore database has a ton of `http:// http://` links. So it requires a reverse proxy in front that can rewrite those, luckily in Nginx it's possible to use a small Javascript program to do it.