Engagement is better seen as an approximation of how many ads you are likely to be able to serve to that user.

With Goose, the core design favors speed over everything else. Though not only was I able to make that safe, it is fairly pleasant to use. But it remains a low level systems language that requires you to think hard about data organization.

Lobster is a waaay more high level language made to be pleasant to use first, fast second. Surprisingly though, it can get pretty close in speed to C++/Rust nowadays too, but still a lot slower than Goose.

How have you found AI at writing Goose or Lobster code, if you give them a skill or something, are they relatively competent at actually writing code in the language?

Both are really interesting projects, BTW - thank you! I've been meaning to try Lobster out but haven't found time, I think this might be the push I needed.

Self-hosting would be cool too, but for both Lobster and Goose I've tried to keep it simple for people to build the language in any environment, which is why its still all in C++.

I don't use any "skills". From what I can see, the #1 way an AI produces "good code" is to simply work in the context of existing good code. I don't need to hold it by a style guide, it seems to infer that from context just fine. At least Fable does, other models less so.

Even if you don't have such an example, pick a project that you think has "good code" (even if it is not your own), point the LLM at it, tell it to have a deep read of the code, and come up with a very in-depth coding guideline in a .md file with code patterns etc. Then put that .md in your new project and tell it to follow it.

"Just Git Gud First" - Wouter van Oortmerssen

LLMs are pattern matching machines. Your code is the base template that will determine all patterns moving forward. No amount of context engineering or prompting can save your code from itself.

Pragmatically, it suggests we need a much greater investment in code quality, and much less hand-wringing over AI tooling.

For context: I'm very active on the Goose discord (and have been following WvO's languages since Lobster was announced on Google Groups eons ago). I goof around there too, and forgot for a moment that outside of that chat it wouldn't be obvious that I'm being tongue-in-cheek.

In Pinthe coding agent, each transcript entry is parented to another entry. That was actually exceptionally dumb.

If you do /tree in pi, pi needs to flatten that tree into linear, nested conversations.

In Pi Durable, we corrected this mistake. A conversation is a chronological, immutable list of entries. A conversation can be parented to an entry in another conversation, and thus inherits that parent's older conversation entries starting from that entry.

So, exactly the same functionality, just less dumb.

Perhaps I'm myopic after working too long with Clojure's data structures, but isn't that exactly what you want? I don't understand the problem with this.

A conversation is a chronological, immutable list of entries. A conversation can be parented to an entry in another conversation, and thus inherits that parent's older conversation entries starting from that entry.

I realise this isn't implemented yet, but does this mean that if I use /tree to go back to a previous point in my conversation, I'll actually get a new conversation rooted at the junction point in the previous conversation? I'm struggling to understand why this is preferable, I use /tree to jump around a lot in my conversations, and it seems like I'd end up with a lot of parallel conversations. With something like /tree, would those conversations be grouped as part of the same conceptual session, or are they then completely independent forks?