nimony

OrderedTable in Nim appears to be the same and still have O(n) performance. On a delete, an entirely new table is constructed. https://github.com/nim-lang/Nim/blob/devel/lib/pure/collecti... I didn't know about Nimony and just took a look. https://github.com/nim-lang/nimony/blob/master/lib/std/table... OrderedTable is now a synonym for Table, ie, both are ordered. To delete a key, the key is looked up to get an index position x in a Seq, the Seq entries after x are shifted left, the Seq is trimmed of the last element, and then the entire table is rehashed because shifting the Seq invalidates the previous hash codes. The performance is better than Nim OrderedTables because at least an entirely new table isn't created, and it probably works fine for small tables, but it still isn't O(1). The performance would be similar to removing an i

The tree-like syntax interested me but unless this new layer enforces it, there's no guaranteed evaluation order among its backends[1], which IMO kind of defeat it's usability as general purpose IR. [1] https://github.com/nim-lang/nimony/issues/792

The main designer is Andreas Rumpf, but investigating the git commits of the new Nim reveals more people being involved. [1] Whether Andreas is a genius, I have no idea, but he has been doing compiler and language development for over 20 years [2] so he's probably extremely knowledgeable regardless. [1] https://github.com/nim-lang/nimony/commits/master/ [2] https://en.wikipedia.org/wiki/Nim_(programming_language)

Also of interest, but not yet finished is Nimony (Nim 3.0): https://nim-lang.org/araq/nimony.html https://github.com/nim-lang/nimony

If I remember correctly, main reason for forking was that Nim BDFL was writing lazy commit messages and old codebase was hard to navigate around. Some small part of community forked the language and trying to rewrite the compiler. According to readme they're not trying to replace Nim, but to create new language with Nim as base. Not sure how usable it's right now or will it ever be. I also want to point out that Araq quickly took the criticism and his commits look a lot better now. Also, core Nim team is currently working on their own rewrite of Nim compiler, called Nimony, that should evolve into Nim 3. Refs: fork - https://github.com/nim-works/nimskull commit 'drama' - https://news.ycombinator.com/item?id=32021299#32023998 nimony - https://github.com/nim-lang/nimony

Relevant links: Roadmap for 2025 and beyond - https://github.com/nim-lang/RFCs/issues/556 Nimony Architecture - https://github.com/nim-lang/nimony/blob/master/doc/design.md Planned design - https://github.com/nim-lang/nimony/discussions/529 Nimony progress - https://forum.nim-lang.org/t/12693

Definitely agree that there are rough edges, but Nim is in a better state than ever. The LSP isn't great yet, I'll agree with that. There are great optional type libraries for working around exceptions if you don't want them, and the new memory management system (ARC/ORC) is very efficient compared to the old refc implementation (now much more like the C++/Rust approach). For parallel programming, there are also handy libraries. The best of which is Weave[1], but Malebolgia[2] is authored by the creator of Nim and works well in its own way too. There is also active work being done on a new implementation of Nim which intends to clean up the some of the long-term spaghetti that the current implementation has turned into (like most long-term projects do), called Nimony[3], and is also led by the original creator of Nim. It is years away fro