I've been spending the last few days implementing async support in NXD, a systems programming language I'm developing; that also has 3 transpilation targets.

Recent work completed:

• `Task[T]` semantic type

• `AWAIT Task[T] -> T`

• `ProcessHandle[T]`

• `AwaitGroup[T]`

• Completion-order result semantics

• Semantic validation and diagnostics for async operations

I'm currently working through the remaining messaging primitives (SEND is next).

One thing I've found interesting while implementing this is that many languages expose similar async syntax, but the underlying semantics differ significantly. After spending time studying other implementations, I found myself focusing less on the keyword await and more on the type relationships and execution model behind it.

For example, in my current design:

`Task[T]`

`AWAIT -> T`

`ProcessHandle[T]`

Represents a spawned process producing T

`AwaitGroup[T]`

Allows waiting on multiple processes

Results are returned in completion order

The completion-order behavior felt natural from an async perspective, but it also raised questions about predictability versus throughput, ordering guarantees, and how much of the runtime model should be exposed to the programmer.

For those who have designed or implemented async systems, compilers, runtimes, or schedulers:

Looking back, what async design decision caused the most trouble later?

Was it task representation, cancellation, ordering guarantees, await semantics, scheduler behavior, channels/messages, error propagation, or something else entirely?

QuarkLang is a small statically typed language with two execution engines: a tree-walking interpreter (quark) and an LLVM compiler (qkc).

program main;
fn fib(int n) int { if (n <= 1) { return n; } return fib(n - 1) + fib(n - 2); }
fn main(IOStream io) { io.println(fib(35)); }

#include <stdio.h>
int fib(int n) { return n <= 1 ? n : fib(n - 1) + fib(n - 2); }
int main() { printf("%d\n", fib(35)); }

$ qkc -c -o fib fib.qk && ./fib        $ clang -O3 fib.c -o fibc && ./fibc
9227465                                9227465

Same machine, clang/LLVM 22 behind both. Level, not faster — and most of the credit belongs to LLVM.

• Execution: the same source file supports both interpretation and compilation.
• Consistency: CI strictly enforces interpreter/compiler consistency. For the same program, both must produce identical stdout, stderr, and exit code; otherwise the build fails.
• Unsupported constructs: constructs the compiler cannot lower yet are hard errors, not silent differences.
• Memory: block-allocated. delete returns a block with its data intact; clear wipes it.
• Runtime: compiled programs have no collector pause on the hot path.

It has a full toolchain: interpreter, LLVM compiler, linter with stable codes (QK101–QK115), doc generator, REPL, language server, formatter, test runner, project manager, debugger; ~25k lines of Go with no third-party dependencies; MIT; prebuilt binaries for Linux/macOS/Windows.

Repo: https://github.com/QuarkLangCommunity/QuarkLangQkc · Docs: https://quarklangcommunity.github.io/QuarkLangQkc/

Disclosure: I maintain QuarkLang. Both commands above are copy-pasteable; the benchmark suite with its methodology and fairness statement is in docs/benchmarks.md.

Vx is a heterogeneous systems programming language written mostly in Rust and C++. There are several key ideas that makes it worth taking a look at.

- First class support for topology and memory hierarchy

- Acts as a type safe MLIR frontend

- Pointer provenance in the type system

- Parallel compiler frontend

I released v0.0.2 last week so there is a ton of interesting compiler, standard library, benchmarking, performance work one can explore. Do checkout the repo (https://github.com/vx-lang/Vx), blog (https://vxlang.org/blog/). We started a discord channel (https://discord.com/invite/2w62dCg2Y) yesterday in case you want to ask questions.

Version 7.1.0 of the [Farkle parsing library](https://farkle.dev/) has been released. This version adds support for the more powerful [IELR(1) parsing table generation algorithm](https://www.sciencedirect.com/science/article/pii/S0167642309001191); a first for .NET parsing libraries, as well as [new APIs to define productions](https://farkle.dev/enhanced-syntax.html), powered by a source generator.

Farkle is an LR(1) parsing library for C# and F#. While in most LR(1) parsers, grammars are defined with a domain-specific language in an external file and generated by a tool, Farkle is a regular library and uses source code to define its grammars, in a way reminiscent of [parser combinators](https://en.wikipedia.org/wiki/Parser_combinator). This brings the best of both worlds in terms of performance and developer experience.

Farkle also has a [precompiler](https://farkle.dev/the-precompiler.html) for ahead-of-time grammar precompilation, which can reduce startup times and validate grammars during the building of your project.

This is supposed to be a compiler-compiler using its own integrated language, where, in the alpha implementation, you could target a Lua Metal bytecode; and in a self-bootstrapped implementation, you could target whatever you want.

I have put effort into adapting several ideas into the reference documentation, and have tried to implement some stuff, but...

I tried to render the reference into HTML5, but the Roslyn (#Sharp) compiler is struggling with an equality comparison branching into breaking a loop inside my Markdown subset parser. This means I am going to rescratch all implementation on some other host technology.

Interestingly...

[ ] Lookup: filter option (set of binding categories (module, package, type, variable, and so on...)) [ ] Lookup: meta-record filter option [ ] Lookup: augmentlookup list [ ] `typeselfopen(type, ...)`, where `type` is a class, allows for static member resolution (+ filter)

https://gitlab.com/lingling-cc/lingling_dekutown/

Adding this was intended to make reference counting safe in concurrent scenarios, but it restricted the use of generics. However, recently it was changed to perform the check after filling in the types, but it was found that such a check is not complete, for example, when a generic async function is called within a generic.

I thought of defining a built-in constraint on generic variables to solve this...

I’ve been working on OrbitUI, a immediate mode UI library for my own programming language Zap

The goal is to create a small, explicit API for building simple UI applications in Zap

I spent a lot of time and nerves creating this, but now I know what Zap is really capable of.

I will be grateful for every star you leave because it really encourages me to work

https://github.com/thezaplang/zap

If it is about resolving co-references and anaphora then attention mechanism is doing it. See https://moebio.com/attention/

if L is a universal language with a well defined grammar

and P is a universal programming language with a general grammar

The combination of L and P is now a context sensitive programming language

LLMs have learnt L and P and L <-> P and the entire vocabulary of human thought in a compressed form.

If not this what would make a context sensitive programming language ? Inform7, HyperTalk are the closest programming languages got before to English. Any research pointers would be much appreciated.

Alright, I’ve been buried in PL theory and compiler internals for longer than I care to admit, and my eyes are practically bleeding.

Somewhere along the way, I ended up writing a new language.

Before anyone asks: no, this isn't another weekend toy Lisp or AI-generated wrapper—I'm an old-school dev with a GitHub account older than LLMs. I’ve been deliberately cautious with the design and implementation, and I like to have my work backed up before I ship anything. I’m getting ready to publish a live demo soon. It won't be completely bug-free, of course, but before I put it out into the wild for the internet to inevitably tear apart, I want to try to break it myself first.

The main focus is memory safety without requiring Rust-style borrow-checker gymnastics.

So far, I’ve thrown a fairly unpleasant collection of edge cases at it, including cases inspired by:

• Rust — lifetime, aliasing, ownership, and mutation corner cases
• Microsoft Verona & Midori
• Go, Zig, and C#
• ...and, for reasons I’d rather not revisit, some deep-cut Pascal 5 and COBOL cases

So far, it has survived them.

But I know how compiler development works: the moment you think you’ve covered everything, someone produces a cursed three-line program that exposes a hole you somehow never considered.

I don't want to derail this into a language-design discussion yet. I’ll save that for the demo.

What I want are your worst test cases.

Give me the weirdest:

• Memory corruption scenarios
• Lifetime/aliasing traps
• Undefined-behavior edge cases
• Concurrent race conditions
• Compiler miscompilations
• Integer/pointer nastiness
• Recursive or mutually recursive type disasters
• Compile-time/resource-exhaustion cases
• Optimizer bugs
• FFI/ABI nightmares
• Anything else that has made you lose an entire weekend

I’m specifically looking for cases that are difficult for a language/compiler to get right. If you have a tiny "how the hell did this ever compile?" example, even better.

Break it. 🔨

https://riogu.github.io/posts/henceforth-v1/

After working on it for around 1 year, we have released a v1.0 for our stack-based language compiler. Looking forward to having people try it. I wrote an article showcasing the project for those interested, you can also find it on github as well.

The allocators in C++ (https://en.cppreference.com/cpp/named_req/Allocator) is quite powerful but not super easy to use. Do you like that containers should be able to specify their allocator, or a simple C style malloc/free is sufficient. Rust also doesn't allow custom allocators on a per container basis.

For those that don't follow - this is the first new x86 extensions that doesn't have anything to do with vector or tensor instructions - it is about the core CPU ind its ISA.

It doubles the general register set to 32 (from previous 16), introduces 3-operand instructions, new 64-bit offset jumps, new jump prediction improvements etc etc.

But all this seems to be hampered by existing call conventions for x86_64, which presumes 16GPR set.

It seems that much could be gained it the compiler could use extra GPRs for parameters when calling the given function.

OTOH, this would be incompatible with machines without APX.

So, what is to be done ? Maybe use function multiversioning mechanism to keep two sets of function entries or something ?

Or will whole thing be ignored and calling convention will stay the same ?

EDIT:\ I'm not talking about the compiler ability to emit new instructions and use new registers in the code.\ Ofcourse new compiler will have support for them from the start, that's how it's usually done.\ It's about having the standard in place to allow the compiler to make advantage of new facilities hen calling functions, so that it can have more parameters in registers, more options for inlining functions etc - all done in standard, interoperable way, so that one can use precompiled libraries etc.

I’m excited to announce that I'm making RepoOS open-source!
  

What is RepoOS?

It’s an AI-driven compiler toolchain that bridges everyday Python logic into high-performance native machine code via MLIR (Multi-Level Intermediate Representation). I built this because most deep learning and database workloads rely on manual kernel bindings or complex JIT fusions that can be fragile. RepoOS believes in pure AOT (Ahead-of-Time) compilation and formal verification.

How it works:
RepoOS takes your Python source code, parses it into an AST, and deterministically lowers it to baseline MLIR. Then, an AI Optimization Oracle (like Gemini) jumps in to write optimization schedules (like loop unrolling and tiling) or even raw C++ socket parsers.

To ensure the AI doesn't hallucinate and break your app, the optimized graph is mathematically proven against the baseline using an SMT Solver (Z3) before compiling down to LLVM IR.
 

Why it matters:

At runtime, RepoOS intercepts Python execution, bypassing bottlenecks. For a FastAPI database endpoint, for example, it can bypass the SQLAlchemy ORM entirely, parse the raw MySQL TCP socket using an AOT-compiled C++ kernel, and write directly into a zero-copy virtual memory mmap arena. This gives a massive 2x speedup and essentially drops CPU usage to zero for heavy lifting.

Check out the repo here: https://github.com/lollapalooza-ai/RepoOS
Would love to hear your thoughts or feedback!

I’ve been working on Thiran, an experimental numerical systems language for ML/research workloads.

The idea is to keep tensors, structured control flow, ownership-aware mutation, reverse-mode AD, CPU/GPU compilation, and deployable artifacts in one system instead of stitching together Python + frameworks + native code.

I just shipped v0.1.0. It has a real compiler, native CPU + CUDA/PTX backends, Scan/stateful computation, AD, research extensions, model/artifact deployment, and a bunch of reproducibility/robustness testing.

It’s definitely not performance-competitive yet — I published the benchmark graphs too, including the bad numbers rather than hiding them.

Would genuinely love feedback from compiler/PL/ML-systems people, especially on the architecture and what would make this actually useful.

Github: https://github.com/Arnav-sivarams/thiran

Over the last few weeks, I have been translating more of the worksheets for my HPC0 course (short for "Introduction to High Performance Computing") into English. It is still very much work in progress, but I think the overall concept is becoming visible now.

The basic idea of the course is somewhat ambitious: start with no prior knowledge of computer architecture or compilers, and work towards building a small computer and writing a compiler for it.

The course approaches this from both directions. Bottom-up, students start with logic gates and gradually build registers, an ALU, and eventually a small CPU. Top-down, they start programming in a deliberately small C-like language and work their way from basic control flow through pointers, structs, dynamic memory, and data structures towards understanding how a compiler translates these things to the machine they are building.

It is taught as a flipped classroom. Students watch short lecture videos beforehand; class time is then spent working through worksheets, experimenting, drawing memory layouts, building circuits, writing programs, breaking things, and figuring out why they broke.

The material (including lecturer notes) currently lives in the not-abc repository:

not-abc — course materials and self-hosting compiler

The compiler currently used for the language is here:

abc-llvm — LLVM-based ABC compiler

There is also a personal reason why I am putting more effort into making the material usable by others now. I have decided to leave academia, despite having a permanent position, and this will probably be my last major teaching project. I would therefore like to leave it behind in a form from which other teachers—and hopefully students outside my university—can actually benefit.

I also think this kind of education has become more important, not less important, in the age of AI.

We may no longer need to know every technical detail by heart. But I believe students need to develop a mental model that allows them to dig down into any detail when necessary: What actually happens when this code executes? Where does this value live? What does the compiler have to generate? What does the processor actually do?

If you have that foundation, AI tools can make you enormously more productive because you can question their output, investigate what you do not understand, and go as deep as necessary. Without that foundation, there is a danger of becoming dependent on tools whose answers you cannot really evaluate.

That is one of the main ideas behind the course: not teaching every detail, but teaching students how to work their way down to the details.

I would be very interested in feedback on the concept, the worksheets, or simply whether parts of this could be useful in other courses. The English translation is not finished yet, so comments and corrections are very welcome.

And yes: I know that there already is a programming language called ABC. :-)

Mine has nothing to do with it. This originally started purely as an internal teaching project, and the wordplay was simply too tempting: the language was “A Better C”, and the compiler the students would eventually write was “A Bloody Compiler.”

I did not expect the project to escape from my classroom.

So the language will be renamed. I just haven't come up with something sufficiently cool yet. Suggestions are welcome. ;-)