Update to 26.1.1?

[kKrosss]

Just curious if there will be an update to 26.1.1 :)

[clo4]

Hey! Sorry for dropping off the face of the Earth. Things got really busy with work, and the last thing I wanted to do when I got home was think about updating anything. Storytime:

For a while I was actually working on a compiler that would compile a readable language to mcfunction files, specifically to make data pack development less hellish. And it got pretty far along too. I was able to port a few of my data packs to it, and the generated code was in most cases equal to what I'd written by hand, and in one case slightly better.

However, at around 20,000 LOC it started to buckle under its own weight due to some foundational decisions I'd made early on. The original sin was writing it in Go. Some cool stuff came out of it though, like a declarative parsing framework I'll probably never find a good time to release, and I also discovered that every language that compiles to mcfunction files is subtly unsound in a pretty core way. Mainly, you can have recursion or you can have if/else -- though I did find a solution that I don't think anyone else has implemented and results in better codegen :^)

Anyway, progress got harder, the project slid further into development hell, and my time became more limited. That was the pinch of death. I got so demotivated that I basically hadn't done any recreational programming since December.

But things are looking up, thanks to a combination of:

• My energy levels coming back
• Some realizations about the language design after stepping away for a while
• Trying out the latest agentic programming tools to lighten the load
• Deciding the compiler will be public but not open source (WASM core with an open source harness)
• Deciding to rewrite it in Rust instead of Go (holy mother of god did that make a difference)

All of that to say, I do plan on updating this eventually. I think the compiler is probably a few weeks away from being usable for a port, maybe? Not committing to anything, but I have hope :)
For the features that are currently implemented (not many but setting up a much more solid foundation), the output is already either equal to or in some cases much better than the Go version thanks to the extremely aggressive optimizer.

[clo4]

Compiler progress tracking well. Haven't done any major codegen work for a few days, instead focusing on getting the editor experience working nicely. Now it has a full language server, editor extensions for VSCode and Zed with syntax highlighting, CLI completions and is built on a custom CLI framework based on a really old project of mine (allowing me to say it is, objectively, the fastest feature-complete CLI framework for JavaScript engines).

When I wrote that comment above, function macros were still my blocker. That's resolved now, and architecturally pretty decent. Opened the door for a standard library, and a "grand unified theory of execute" (except for three features which the compiler has to know about...)

The "weirdness budget" of the syntax is being used to enforce some constraints. For the most part, it's Python's syntax with Minecraft's terminology.

[clo4]

I've spent a lot of time on codegen in the last few days. The code it outputs - when it can see the patterns - is often significantly more optimal than what a human would write. Primarily because of bounded recursion expansion, compile-time evaluation, partial or total function specialization, effect tracking, function call inlining, the way it outputs conditionals. This feels like what I imagine someone making the jump from assembly to C feels like.

The compiler, debugging tooling, and editor extensions are now at the point I can begin porting my data packs to this language as a dogfooding/UAT exercise, but not with the intention of releasing just yet. The goal is to use this experience to make changes to the compiler, and I want to avoid churn and burnout (and boy, releasing this many datapacks can sure burn you out).
Still probably a couple more weeks, but huge progress!

Showing no signs of buckling under its weight yet. Writing it in Rust continues to have been a great choice.

Rounded down totals, just counting lines of code (not comments or empty), currently:

• Rust is ~16,600 LOC
• TypeScript is at about 8,900 LOC

[clo4]

Detect AFK is now mostly ported. Dogfooding is going well, the language is better as a result.
It's still in progress, there are still really basic features it needs that the language doesn't natively support yet (though you can always drop down to writing commands, so you're never blocked on language support).

I wouldn't call the port done until the basic stuff (declaring scoreboard objectives, for instance) is supported with syntax. Designing a programming language is more design than programming, it's hard to come up with something that fits the ethos of this language.

Really looking forward to sharing more about this project, it's been so interesting to steer.

[clo4]

More correctness and safety tweaks. Better output. More inlining and compile time evaluation. The optimizer is now able to prove more facts about values, like when you check if a value is undefined, we now know that until the next analysis boundary, and can emit slightly more efficient code because of it.

Still don't have a great unifying theory of how to actually define scoreboards yet.

Pause Day Cycle was really easy to port and is very elegant in this language.

[clo4]

LOC (not counting comments or blanks):

• Rust: 22553
• TypeScript: 10014
• JavaScript (for tree-sitter): 1063

There's more but some of it's generated and some of it is incidental, not core to the project.

This would never have been possible in this timeframe without LLMs.

Things are starting to show more signs of LLMs having difficulty navigating the codebase. Probably in need of a refactor soon.

[clo4]

Massive upgrades to the editor experience today. Building works, can emit a folder + zip + mod. Packages up resource packs too. Works with files defined outside of the language. Maps from game version to pack format version, so now you don't need to keep track of that.

[clo4]

Since last week I've improved codegen a fair bit, massively improved the editor experience (the extension and language server now integrate Spyglass for completion inside commands), redesigned the build system, implemented compile-time loops over ranges and values, variadic macro function parameters, constants, built out a suuuper basic converter to speed up the process of porting data packs, set up the framework for localization, and now have a minimal docs site with a compiler playground (no content yet)

[clo4]

It took a long time but I finally landed on a design for scoreboard objective declaration & definition, and this comes hand in hand with both NBT storage and language-native stacks.

The port will take a little longer, but the language is better for it.

I didn't really do much work on it during the week, so the current stats are:

• Rust: 26472
• TypeScript: 19620 (grew a lot because of the editor experience improvements & docs site)

[clo4]

I fully intended on landing scoreboard objective definition this weekend but stack variables ended up proving difficult to get right. Almost there... with a ~7,000 line diff.

[clo4]

Didn't make any progress last week, was too busy with work to justify spending even more time on my computer after work.
Didn't make much progress this weekend while I was recovering from that week!
Have landed stack locals now, which is such an incredibly powerful feature that I'm so excited to have in the language, and it builds the foundation for full NBT support.

An idea I've had in my head for ages is a testing framework that actually runs your data pack in the game, so I'm building that out too to see how that goes. Means you can build a test script, run it with the test runner, and have it automatically download+launch+run+test in every version of the game you declare support for.

• Rust: 29031
• TypeScript: 19980