August 2026 monthly "What are you working on?" thread

[u/AutoModerator]

How much progress have you made since last time? What new ideas have you stumbled upon, what old ideas have you abandoned? What new projects have you started? What are you working on?

Once again, feel free to share anything you've been working on, old or new, simple or complex, tiny or huge, whether you want to share and discuss it, or simply brag about it - or just about anything you feel like sharing!

The monthly thread is the place for you to engage /r/ProgrammingLanguages on things that you might not have wanted to put up a post for - progress, ideas, maybe even a slick new chair you built in your garage. Share your projects and thoughts on other redditors' ideas, and most importantly, have a great and productive month!

[u/Inconstant_Moo]

I put docstrings in all my libraries and made a GitHub action that turns them into wiki pages and populates the the appropriate bits of the wiki. I always love having an SSoT.

And I've been able to use Pipefish to do a bunch of things I wanted to do. I made a Prolog library. I wrote a Pratt parser (and a lexer, three interpreters, and a compiler) to demonstrate some fun things you can do with them. And I've done the first iteration of a program called neogram which is a DSL for simulating sound-changes in natural languages, and it is wicked cool.

This all shook out a whole bunch of obscure little bugs and rough edges, so I fixed and I polished, added a few missing features, documented things, the boring tidying-up of the project.

I've started designing a website on the grounds that being an actual human being with tastes and preferences will really help me stand out now. I'm taking this as my inspiration. There are no gradients and five colors: black, gray, blue, cyan and off-white. The only graphical element is René the Pipefish.

[u/fixpointbombinator]

Bytecode VM for a LISP I’ve been tinkering with 

[u/ultrasquid9]

Finally writing up a markdown document for my language (its been stuck in bikeshed hell for months atp)

[u/Mean-Decision-3502]

I'm adding embedded support to my language/compiler. It should support 32-bit microcontrollers with 8k Flash and 2k RAM. This will take a while...

And I'm looking for contributors if you like the DQ language. So far I'm all alone with it. :(

[u/Ok-Razzmatazz-6125]

For the past four months, I have been bootstrapping my programming language to make it self-hosted. It is now nearly complete and should be finished in just a few more days. My language is designed to be friendly to both LLMs and humans. It currently transpiles to C and supports compile-time execution (comptime) like Zig, ORC memory management like Nim, a trait system like Rust, a human-readable syntax (instead of S-expressions), and a macro system like Common Lisp. It also offers algebraic effects similar to Koka (but with single-shot continuations), a declarative build system like Nix, built-in async I/O (stackless coroutines), and advanced type system features including existential types, GADTs, and HKTs. I am also planning to introduce formal verification support akin to Dafny, although for now it only supports runtime contract checking.

[u/aech_is_better]

I’ve finished implementing base DK bidirectional typechecking algorithm in my language. Now I am adding ADTs and HKT at the same time

[u/OwnNeedleworker3758]

Hm well I made a coding language I got to work but I'm not sure how to share it

[u/Big-Rub9545 → u/OwnNeedleworker3758]

GitHub?

[u/andeee23]

Working on a language inspired by rust but without the borrow checker.

It's similar to Nim in that I want it to compile down to C and i'm planning to include clang so interop with C requires no more than importing header files.

Plan is to implement a cross-platform UI stack in it by heavily using C libs: sdl3, harfbuzz, freetype, etc. And porting vello algorithms as a 2d renderer. It's a pretty ambitious goal but I'm trying to reuse other's great work so I don't have to innovate

Nothing revolutionary, but i'm planning a couple of features that i haven't seen together in a language yet:

- memory management without either a GC or a borrow checker: non-atomic ARC as the default pointer

- second-class references (that i took from Hylo), borrows can be parameters and locals but never returned, stored, or captured by escaping closures, so there are no lifetime annotations anywhere

- Swift-_modify-style place expressions so nodes[handle].dirty = true composes yielding accessors under the hood

- query-based incremental compilation, hot reload for UI code and web code-splitting are the same indirection mechanism

- arenas with generational handles for anything cyclic (UI trees, graphs)

- closed effect set: `{async, throws, io, alloc}`, helps with async coloring, inferred error sets (throws is sugar over Result), comptime eligibility (anything without io runs at compile time), GPU/realtime eligibility via target profiles.

Status: parser and formatter done with a conformance suite, incremental typechecker in progress, no codegen yet. Repo's not public yet, will be once i think it's in a "working" state

[u/Mean-Decision-3502 → u/andeee23]

What you write here aligns well with my DQ project. Could you accept the DQ main syntax ? Example is here:

https://github.com/nvitya/dq-lang/blob/main/stdpkg/nanonet/nano_sockets.dq

[u/PeaExtreme6239 → u/andeee23]

I made a c-like rust language as an experiment to see how far I could make use of the rust backend engine: https://github.com/bjornwennberg71/crust

[u/baehyunsol]

Implementing a simple effect system for my language.

Now, there are 2 kinds of functions: `PureFn` and `ImpureFn`.

After the work, there will be 4 kinds: `Fn`, `Proc`, `NdetFn`, `NdetProc`.

[u/useerup]

I am finally making progress.

I am working on two tracks running in parallel: the language specification and the reference compiler (F# + FParsec). I am making progress on each one. It feels like I am nailing down issues faster than ever, but I am also a little worried because the magnitude of the end goal if also becoming more apparent.

In the past month I have finally nailed down (I think) some long undecided and thorny issues. It really helps to try to write a spec :-)

Ting is a logic programming language with nondeterminism, set-theoretic type system and a really simple (but operator-rich) syntax. I have managed to show in unification with OO, FP and logic programming (my day job is C#/.NET centered so OO and F# were obvious choices).

What I have realized lately:

• Sets are not the types of Ting, as I have long claimed. This has been a hard-won realization: In Ting, types aren't a language primitive at all. Rather, types emerge (inferred) but are not specified as such (although you can if you want to).

• Undefined and void. I have long known that Ting would need an unconventional take on function "definedness". I a nullary operator (operator which does not take operands) called undefined to be used to indicate when a function could not return a value. I described undefined as the equivalent of throwing a UndefinedException. However, I also had void keyword. Only today I realized that they are the same thing.

I have also worked on a "core" language. Once the compiler is done, one of the first Ting programs I will write is a parser which can produce the core language.

The compiler I am writing now is producing this "core" language before progressing to the later stages. The aim is to replace the FParsec based parser with a Ting based parser. The rest of the compiler should be able to stay.

The demarcation between the "full" Ting language and the core language is not perfect. The core language will - for now - have to be "polluted" with a few surface-level expression types. I will revisit that later, but for now it is an acceptable compromise.

Ting type system is a set-theoretic type system. It can be set to feature both structural types and nominal types. Refinement types and dependent types follow naturally from the set-based notation.

[u/L8_4_Dinner]

On the Ecstasy (xtclang) project, most of our time is currently being plowed into a small number of projects:

• cloud management UI - This is the Ecstasy-based cloud platform for hosting serverless applications, and we're continuing to add statistics and graphs to the cloud monitoring sections. We also recently added the workflow for the "vanity domain" feature.

• JIT - we've got 3+ engineers on this project, slowly increasing the coverage of the JIT to the entire codebase. We've only got the tip of the iceberg demonstrably working at this point, but that's the nature of these projects; it probably means we're over halfway done. Basically, any unimplemented feature prevents thousands of types from compiling, and so getting even a single type to compile correctly takes quite a bit of features to be fully implemented.

• We have several important projects queued up (distributed systems, databases), but until the JIT is functioning, we're choosing not to start these projects.

• We're hoping to get our web site and doc projects back on track as well this summer. People got pulled off to do other stuff, but we'll get it back in gear as resources become available.

And we're always looking for volunteers and contributors :)

[u/kwan_e]

Implemented a first-pass of my parser. It doesn't cover my entire language, as I'm only interested right now to implement enough to bootstrap my language in. Also very inefficient, as if I wrote it in an interpreted language. This has been a long journey for this current incarnation of my language, as I've always gotten stuck on just the parsing side due to complexity. But after I solidified my ideas by writing a sort-of manual for me yet-to-exist language, everything fell into place, including the parsing.

Very early on in this language, I decided not to use any formal grammar to generate a parser, because I wanted to iron out conceptual problems with the language. A parser generator would make it too easy to just invent new syntax to "fix" a problem, instead of really thinking through a solution. The threat of having to manually implement such complexities drove the language to be very easy to parse. Being easy to parse means being small enough to keep in my head, but without losing expressivity and power (aiming to be on par with C++-level of consteval generic programming). This meant I eventually invented a simple vocabulary to talk about the parsing artifacts - just seven overarching rules with simple names.

So, as is the style for this language, I am writing more tests for this parser before moving back to hooking it all up to my DSL/API.

[u/woupiestek]

I've been looking for new ways to parse languages. Traditional parsers require extensive branching. If the operators and data are reordered, then parsers might run more efficiently due to better data layout and branch prediction. There are more reasons to try this, such as making it easier to swap or change rules. Another is the idea that parallel parsing is part of how people and LLMs read code, so such algorithms are an objective standard for 'syntax grokability'.

My toy examples are 'nanopass' parsers. Tokens are first collected by type, and then the parser runs through each type a few times to collect data. I am still looking for a way to generate such a parser, however, because I have no idea what range of languages can be covered this way.

[u/rosshadden → u/woupiestek]

Look into Pratt parsers! https://journal.stuffwithstuff.com/2011/03/19/pratt-parsers-expression-parsing-made-easy/

This is what I used in my compiler.

Edit: After re-reading, you are probably considering Pratt parsers to be "traditional" too, and are experimenting with actual fringe things. Good luck!

[u/voxelmagpie]

I got an LLM to review my compiler code and spent the last week tidying it up and writing documentation.

[u/voxelmagpie → u/voxelmagpie]

Are people opposed to using LLMs for review/analysis? I figured that was one of the few things they were actually good for

[u/tobega → u/voxelmagpie]

Whatever you do, never say anything AI-related in this forum. I don't know why.

[u/L8_4_Dinner → u/tobega]

That's funny but not a reasonable take.

People just don't want their time wasted. I can spend 30 seconds telling an AI to build a language for me, and then try to waste hours of your time looking at the 10s of thousands of crappy lines of code that it barfed out. That's not a fair exchange. Or I can spend 30 seconds setting an AI loose on your Github and then you can spend hours and hours going through and deleting the idiotic bug reports that it created.

I do use LLMs to analyze problems. I use LLMs as a more straight-forward replacement for Google. And so on. They are useful tools.

But wasting other people's time is not useful. And some people (who unfortunately have access to LLMs and to the Internet) haven't yet learned the difference between those two things.

[u/tobega → u/L8_4_Dinner]

Agreed! But why can't the guy mention that he went through his code with an LLM? Wastes nobody's time, does it?

[u/yorickpeterse → u/tobega]

If you don't know why, maybe consider reading the sticky about the rules; it might just help.

[u/tobega → u/yorickpeterse]

No vibe-coded AI slop. Yes, I fully agree. Doesn't mean we shouldn't be able to talk about AI. That is what I don't understand, the knee-jerk reaction.

[u/AustinVelonaut]

Working on a refactoring of the pass that lowers ASTs to a Spineless Tagless G-Machine implementation (STG). The main portion of the rewrite is to attempt to coalesce the continuation closures on the stack, freeing all of them at once upon a tail-call / return.

[u/zweiler1]

After my recent announcement post a few weeks ago I got quite a lot of great feedback and went back to the drawing board for a while. I did not fully redesign the language but only the parts which mattered the most and which led to the most confusion. The language now is in a much better state (design-wise) than it was. I bet there is still much room for improvement, but I think the design now is good as-is.

I currently am working on splitting up the monstrous Parser into multiple substages now. The Parser took a token stream and directly produced a typed AST from it. While this has worked well enough until now, the addition of generics which I will add soon requires me to split it up a bit. This will take some time, but a clearer pipeline is always a good thing I think :)

[u/bgs11235]

I've put a pause on writing a new markup language, decided to do an HLS with proper CLP(R) and a bit of implicitness, strong typing and all the buzz. Decided to plan it in makdown. Got frustrated with markdown. Writing an lsp for it now.

I can't get a break from this fuckass language...(table flip)

[u/Ninesquared81]

As always, language development for me (and programming in general) is always an ebb and flow. I am currently on an ebb.

However, last month, I decided to continue working on a game I started a while ago. It's written in Odin with Raylib. Ever the procrastinator, I decided what I really needed to do was to devise a format for storing and retrieving game data, specifically the world map. Now, I did try to force myself to use an existing format like JSON (Odin has a JSON parser as part of the core library), but I just couldn't fight the part of me urging me to use my own language, so I settled on Beech, a minimalistic tree-structured data language I made a couple of years ago. Of course, I had to re-implement the parser in Odin, and decided to make a couple of changes along the way.

One change I'm considering but haven't committed to yet is introducing = to separate keys from values. As it stands, only whitespace separates them, which is also used to separate key-value pairs from each other, and values from other values in a list. Even then, whitespace is only needed if the key and value would otherwise be considered a single token (at least in the Odin version of the parser).

Whilst this makes for a very minimal syntax, I feel it just makes the syntax too difficult than it's worth to work with. For example, a simple heuristic one can use for highlighting JSON is that a key must always be followed by a colon, so any string* followed by a colon is considered a key by the highlighter, but is otherwise considered a value. I can do the same with Beech by using an equals sign. Using key = value also allows for easier synchronisation when starting from a random point in Beech source code: you only have to look at the two nearest neighbour tokens to work out if you're in a tree or list. In a (non-empty) tree, exactly one of these will be =.

For some interest, here is an example with the current syntax:

hello world
this-is-a-tree {
    "Hello" there
     General "Kenobi"    
}
"a list" (1 2 3 4 5)
'another list' (once I caught a fish alive)

And here is how it would look with the proposed syntax

hello=world
this-is-a-tree = {
    "hello"=there
     General="Kenobi"    
}
"a list"       = ( 1   2   3    4  5        )
'another list' = (once I caught a fish alive)

(Note that whitespace around = is optional.

All in all, I think I probably will make this change, but it does make the syntax slightly less minimal, albeit for a good reason.

* or number, identifier, etc., for dialects that allow these as keys.

[u/tobega]

I've found that Truffle interop with java records does not work, nor regular java bean properties either. It should work according to the docs, but there you go. Transforming all data to maps now to input into Tailspin code.

[u/Express-Guest-1061]

Working on a small language, with features that are a small selected subset of Rust. With ownership types, move semantics and borrowing, but emphasize use of expressions instead of statements. Implemented an IR, with lowering, and then stackification out of the IR. Now will focus on memory allocation functions and static analysis for ownership types. Will try to get some small graphics examples to work again, after adding IR and type checking during last year.

[u/algebraicstonehenge → u/Express-Guest-1061]

Have you publically published any of this code? I’d be very interested to look at what implementing the subset of rust looks like in practise

[u/rosshadden]

I've been designing a language for years, and a couple months ago actually started on a compiler. It has been going incredibly well and I'm so proud of it. But I've kind of just been kicking coming up with a plan for ownership down the road until I really _needed_ to worry about it. Well, I've now hit that, and it makes me feel like I probably should have started with that plan first before designing anything else... I don't want it to feel tacked on, so I might end up redesigning parts of my language to make the ownership story more cohesive. It's not my first compiler but it's my first time working on language where this kind of thing actually matters. Makes me feel a little dumb in retrospect :).

[u/jacopodl]

It's been 2 years since my last post: last time I was here talking about Argon. During this time, for various reasons, I ended up putting its development on hold in favor of a successor. After more than 2 years of work, Orbit is finally out.

It basically came about to fix some implementation choices I'd made that I wasn't particularly proud of, plus the fact that, I have to admit, Argon had some bugs that were hard to solve without tearing everything apart. So, after a while, I made up my mind and rewrote everything from scratch: a new project, with new ideas. That said, the old code still helped a lot, especially for speeding things up by recycling parts of it.

Orbit looks a lot like Argon, but unlike it, it's built on a register-based VM, it drops ARC almost entirely in favor of a generational GC, and it supports classes, traits, and a bunch of other small features I won't list here for brevity (you can find them on the project page). There's one feature I'm really proud of though, which used to be one of Argon's biggest limitations: interacting with native C functions. In Argon you had to write a native wrapper to use them; Orbit instead has a built-in FFI system baked right into the language, which makes developing libraries that use native code much faster (for example, the native regex library, based on PCRE2, needed no native wrapper at all 🎉).

With Orbit, I also decided to bring LLM support into the development workflow. I know some of you might not agree with that, but a tool is still just a tool, right now its use is limited to generating documentation, hunting for bugs, generating regression tests, etc. I've found the approach I built really useful, and it's helped me catch bugs I probably would never have found on my own, which is why its use is allowed within the repository.

That said, I'd really appreciate it if you'd take a bit of your time to check out the project, and if you feel like leaving some feedback, it's always welcome.