moor
rmoo
Our great sponsors
moor | rmoo | |
---|---|---|
7 | 2 | |
149 | 8 | |
- | - | |
9.7 | 1.8 | |
about 1 month ago | 9 months ago | |
Rust | Emacs Lisp | |
GNU General Public License v3.0 only | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
moor
-
Gleam
I think Haskell or OCaml would do a better job on the ADTs for a parse tree. When doing this, I found Rust's enums... anemic... and got very annoyed by the awkwardness of having to Box recursive types. I was reaching for the ability to continue to be able to pattern match on nodes while attaching common attributes (line numbers, etc.) and ended up having to bury everything 1 level deep in a struct which ended up feeling awkward.
That and Rust's iterators are terrible at introducing ownership agony.
In any case, I've ... done it (https://github.com/rdaum/moor/blob/main/crates/compiler/src/...) but can't say I liked it.
I do really like "pest" as a parser generator though.
- Show HN: I rewrote the 1990's LambdaMOO server from scratch
-
I rewrote 1990's LambdaMOO from scratch on a new foundation.. with the intent of a new system for tomorrow...
See: https://github.com/rdaum/moor
- Evennia a MUD/Mu* Creation System
-
LambdaMOO Takes a New Direction (1992)
I've been working on a rewrite of the server into Rust, for kicks: https://github.com/rdaum/moor
Unfortunately still lots of work there to be done, and I have no time.
rmoo
-
Show HN: I rewrote the 1990's LambdaMOO server from scratch
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 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.
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 to solve the shared world state problem and still meet user's expectations of consistency.
Re: the MOO client, it's `rmoo.el`: 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 patch my local copy to make it work with emacs 29.1.
-
1980: MUD
A friend of mine maintains a fork of RMOO, an Emacs MOO/MUD client. You might find it interesting: https://github.com/lisdude/rmoo
What are some alternatives?
floor - The typesafe, reactive, and lightweight SQLite abstraction for your Flutter applications
toaststunt - A network accessible, multi-user, programmable, interactive system for the creation of MOOs / MUDs.
Hive - Lightweight and blazing fast key-value database written in pure Dart.
tinyfugue - TinyFugue - Rebirth
nmoo - An enhanced LambdaMOO-like MOO
mudmixer - MUDMixer is an add-on for MUD clients that enriches the gaming experience with connection mixing functionality and a variety of other features.
mica
gleam-otp-design-principals - Gleam OTP Design Principles User's Guide
mobx.dart - MobX for the Dart language. Hassle-free, reactive state-management for your Dart and Flutter apps.
EtaMOO - A new implementation of the LambdaMOO server