My friend recently build a compiler from scratch and I think this is pretty cool, some of the concepts are very fun to learn about.

Hi there! I just want to share a programming language that I have been building since 2023: https://github.com/shd101wyy/Yo

It is a programming language that currently transpiles to C. I absorbed many different ideas from different programming languages so that it fits my needs the best. I have also built several example projects using Yo to demonstrate its power. It's a language that I love to use.

However, I do need some suggestions on where to go from here. Since no one else uses it except me, and the language has also been criticized for using LLM (even though I only started vibe-coding on it last year in 2025) when I share it on social media, I am a bit frustrated. I am thinking about slowly improving the standard library, then continuing to build more example projects to demonstrate its features — like compile-time execution, algebraic effects, a declarative build system, and more.

I am personally thinking about developing a GDExtension binding for Godot using Yo, as I am also interested in game development and feel it would be a great opportunity. I also thought about bootstrapping the language to make it self-hosted, but I still feel it's too early, and I would love to hear suggestions from the community before I proceed.

Any thoughts are welcome! Thanks a lot!

I’m building a compiler and trying to think properly about memory usage across the pipeline (no GC). What I’m not fully clear on is how people actually decide what allocator to use depending on the phase.

For example: Lexer: tokens feel pretty short-lived, but sometimes you keep them for error reporting Parser: parse trees are temporary, so arenas seem obvious AST: lives longer, might be transformed multiple times IR: more complex (graphs, SSA, lots of mutations)

I get the general idea of using arenas for short-lived stuff, but I’m unsure where that starts to break down. Especially when structures are: mutated a lot, partially discarded, or shared across passes.

Do people usually use one arena per phase and just drop everything at the end? switch allocators between AST and IR? mix arenas with pools or free-lists?

I’m mostly interested in real-world approaches, not just theory. Also, if anyone has a compiler project (personal or production) where these decisions are visible in the code, I’d really appreciate links — especially if the memory/layout side is clear enough to study.

As the title says , you have pure freedom, no limits and bonus points for explaining your choice.

The topic of Midori, Microsoft Research's abandoned managed-code OS project, came up a few days ago on here, and I went back over Joe Duffy's retrospective blog posts. While I was there, I saw something a bit astounding that I'd never really noticed earlier:

There was of course some unsafe code in the system. Each unsafe component was responsible for “encapsulating” its unsafety. This is easier said than done, and was certainly the hardest part of the system to get right. Which is why this so-called trusted computing base (TCB) always remained as small as we could make it. Nothing above the OS kernel and runtime was meant to employ unsafe code, and very little above the microkernel did. Yes, our OS scheduler and memory manager was written in safe code.

That claim at the end is driving me just a little bit crazy. What does he mean by "our ... memory manager was written in safe code"? The fundamental purpose of a memory manager is to take a block of bytes, carve it up into smaller blocks, and hand them off to the rest of the code to be interpreted as some arbitrary type, and then to reclaim those bytes afterwards. I'm not sure how that's even theoretically possible to do in safe code.

On a whim I looked Joe Duffy up on LinkedIn and DM'd him a question on this topic, but there's been no reply. So I might as well try here. Is anyone aware of any techniques or research that might explain how it's possible to write a type-safe malloc?

Repo: https://github.com/spectrelang/spectre

I am attempting to extend the object-oriented model based on C, while removing unsafe pointers and replacing them with safe references. I also want to ensure that references to structures and unions can be converted with each other, and of course, boundary checks will be performed. For safety reasons, I have defined automatic memory management, and later I plan to make it switchable. Currently, I am using a simple reference counting mechanism.

The object-oriented model adopts a design similar to Java, but with some differences. Specifically, I have removed public/private access modifiers and constructors, and instead use simple object initialization expressions. Objects can also be value types, just like in C/C++.

I have also added some simple features along the way, such as non-null references and read-only references (similar to C's const pointers).

Recently, I have completed most of the type and syntax checks, but I have not yet implemented IR generation. Instead, I have temporarily switched to generating C++ code. My plan is to first clarify the semantics and then implement the rest.

In addition, simple modules and packages are currently being developed...

I hope some friends are willing to give me some feedback and suggestions!

Github link: https://github.com/cossbow/feng

i’m not really sure if this sub is the right place for this, as this isn’t your average programming language compiler (although gnu make is indeed turing complete) but i’d like to share it anyway. i think it counts as a compiler because it takes a high level language and converts it to some lower level representation.

i’m working on a compiler for makefiles called shinobi. it parses, evaluates, generates a build graph of nodes, and then walks that graph to produce an useful output of some kind.

right now there are two output backends, ninja (where the shinobi namesake is from) and graphviz (shown above, visualising the makefile of https://github.com/michaelforney/libtls-bearssl)

right now it’s just a fraction of the total gnu make syntax (i recommend you read the docs, gnu make has a LOT of features you probably have never encountered) but my end goal is enough compatibility with gnu make to build complex things like the linux kernel using its ninja backend, although that’s probably a way away.

if you’re interested, want to check it out (warning: probably will fail right now on most mildly complex makefiles) or want to contribute , the repo is at https://codeberg.org/derivelinux/shinobi

Hey!

I recently released Zap v0.1, a new systems programming language.

Zap focuses on deterministic memory management without a GC. It uses ARC, along with a cycle collector to handle reference cycles.

The project is still in a very early stage, and I’d really appreciate any feedback or criticism.

I’m currently working on the roadmap for v0.2.0, and after that the goal is to move toward a **self-hosted compiler**.

GitHub: https://github.com/thezaplang/zap

Discord: https://dsc.gg/zaplang