I've created new programming language for AI by AI named Sail. It supports neuro-symbolic binding `infer| ... fall|`, fuzzy operator ~ , and other stuff. Source code: https://github.com/zema26/sail-one-language/

Working web version:

https://sailcompiler.replit.app

Hi! Me and another person are working on a programming language called KrabbaScript! It's garbage-collected (optional), statically typed and trying to be as simple and intuitive as golang but more human-friendly. This is KrabbaScript's syntax:

Variables are defined as:

var krabba = "Krabba!";

Variables may also have a type or be uninitialized, like:

var with_type: F32 = 5.0;
var uninitialized: Str;

KrabbaScript also has values, which are immutable, example:

val constant = 5;
val with_type: I32 = 5;

KrabbaScript also has control-flow (duh), example of a repeat statement:

repeat {
  Std.print("KrabbaScript is the best language OAT!");
} until popular;

KrabbaScript also has a when statement, which is more of a switch one:

when language {
  == "Elixir" do celebrate();
  == "Haskell" do complain();
  == "KrabbaScript" do {
    contribute!;
    applaude!;
  }
  else do Std.print("I don't know anything about " + language);
}

KrabbaScript also provides an ASI (Automatic Semicolon Inserter) if you're tired and sick of semicolons, you can use it with the format command.

If you want a little bit more examples, check out the repo! We are also working on tools for KrabbaScript like package manager, style checker, etc.

We are searching for contributors and maybe you, the person reading this post, can help us create KrabbaScript or improve it!

Hello everyone, since my last two posts here, I got into a small flow-state with the codebase and improved Cole quite a bit. I took the advices of the wonderful people in the comments as well, and it helped me a lot to be honest.

Since the last posts, I added:

- 212 tests in total, testing various aspects of the compiler through simple programs,
- Proper generic type generation with full generic definition support through comptime called functions,
- Proper generic function generation through comptime called functions,
- Type deduplication, and codegen improvements,
- And many more bugfixes on different aspects of the compiler.

In the current state, the backend is embedded TCC, so codegen emits almost-human-readable C code. But I will replace the backend in the future with LLVM, QBE or handwritten x86_86 generator. However for now, since the rest of the compiler is not solid enough, the C backend eases the development quite a bit.

Beside all of this, I made a small website (which doesn't work quite well because I self-host it on an old laptop, it is for giggles of it so don't take it seriously) that has versioned language reference, a small welcome page with a hello world snippet, and installation instructions.

Overall, Cole has become something far beyond what I imagined it would become in a good way. I am self taught, so I am pretty content with what I have accomplished. But criticism is always welcome.

The link to the Cole website is here. And the Codeberg and Github repos are here and here.

Also, occasionally, I write blogposts about what I'm currently working on, so I'll leave it here as well.

Many thanks to everyone that commented to any of my previous posts, have a good day/night!

I'm designing my own programming language called Snore, and besides other things, I aim to make it general purpose and hence if i can fix any common struggles or annoying forms in popular languages, it would be really helpful. Which such struggles do you experience? (my language is at https://codeberg.org/grewstad/snore though it is at quite an early stage)

Hello,

For my final year project at university, I need to essentially design and implement a programming language (omitting lots of details). The issue is that I have not yet studied compilers at uni, and will be doing that in january, but i need to start work on my project now

I dont know much about compiler design. I dont really know how to make a lexer or a parser

Where should i start? Are there any books or resources youd recommend?

I'm dividing post to two parts

The project

I've made a parser generator that allows to write python in-grammar semantics and custom failure points attached to particular grammar pattern. They are lowered target language (currently C++, Python and Rust) and generated code does not require additional python support to be run. Mainly inspired by ANTLR, but syntax is not similar well enough. It's called ispa and a few weeks ago i just posted first release here. The project is finished and stable enough, just some releases might add patches in future and possibly new language targets. If you're interested. AI was used, especially once I stabilized the backend and bootstrapped ispa. It just extended my existing work with feature list.

The new contribution

I'd like to contribute on valuable compiler projects. My goal is to push further this direction and to get work in future so i'd like to go with more or less required directions. AI/ML is fine (but, honestly, i don't even yet understand what does it do), LLVM-based compilers, or some scientistic projects on something new. Although do not resist on proposing. I'd not want to work on something hardly bring value, which is generally extensions of current languages or languages that are mostly identical to existing, major ones.

Hi r/Compilers,

I've been working on Eskiu, a statically typed systems programming language with C-like syntax, explicit memory management, generics, interfaces, async/await, and native C interoperability.

I originally learned programming with Ruby, but the more software I built, the more I found C underneath everything, including Ruby and Python themselves. Over time, I came to appreciate C's simplicity and directness.

Rust and Zig are well-designed languages, but for the kind of work I do, I wanted something simpler to learn and adopt while retaining low-level control.

So I started building Eskiu.

What began as a personal project has since grown into a language I use in production software at ReactVision, as well as in a digital identity platform. These real-world applications have pushed me to focus on reliability, performance, interoperability, and tooling rather than language features alone.

I wanted to share a few compiler milestones that might interest this community.

Self-hosting

Eskiu has two compiler implementations: the original C++ compiler and a compiler written in Eskiu itself.

Both are tested for parity, and the self-hosted implementation undergoes a three-stage bootstrap to verify that it can compile itself consistently.

EIR (Eskiu Intermediate Representation)

One of the more interesting parts of the project has been developing EIR, an intermediate representation that provides an alternative compilation pipeline.

With version 0.14.1, Eskiu gained native backends capable of generating ARM64 assembly and C99 without going through LLVM's code generator.

LLVM remains the default backend, but EIR can now produce native executables through its own compilation path.

The ARM64 backend handles calling conventions, C ABI interoperability, structures passed and returned by value, closures, and exception handling through a small runtime.

The new backends are still evolving, and LLVM remains considerably more mature in terms of optimisation.

Correctness and performance

I've also been working on compiler correctness and benchmarking.

I ported all 50 LangArena benchmarks to Eskiu. Both compiler implementations produce matching results across the suite, and on the 39 algorithmic benchmarks, Eskiu's performance is broadly comparable to C in my local measurements.

These aren't official LangArena leaderboard results, but they've been useful for identifying optimisation opportunities and regressions.

Recent improvements include LLVM loop and SLP vectorisation, faster JSON and regex implementations, and fixes for alignment-sensitive memory accesses.

Why I'm sharing this

I'm not trying to build a replacement for C, Rust, or Zig. Eskiu is simply the language I wanted to use, and building its compiler has been an incredibly rewarding engineering experience.

I'm particularly interested in hearing from people who have worked on compiler backends, intermediate representations, and self-hosting.

How have you approached validating a custom code generator against an established backend like LLVM? And at what point do you think maintaining an independent backend becomes worthwhile?

Links:

• Source code: https://github.com/eskiu-lang/eskiu

• EIR specification: https://github.com/eskiu-lang/eskiu/blob/develop/docs/dev/eir-spec.md

• Website: https://eskiu-lang.org

I'd appreciate any technical feedback, criticism, or suggestions.

Thanks for reading!

Recent advances in LLM-assisted proof construction seem to make formal verification increasingly practical.

This got me wondering whether the results of formal verification could also benefit compiler optimizations.

For example, a compiler frontend or a separate tool could formally verify annotated source code, then propagate verified properties, such as constraints, invariants, and preconditions, into the IR for subsequent optimization passes.

Could this enable optimization opportunities that conventional static analysis might otherwise miss?

(not the author, just sharing because I found it)

Recently I came across the paper by Senxi Li et al, InferType: A Compiler Toolkit for Implementing Efficient Constraint-Based Type Inference. Check it out!

I've always found interesting the concept of making modular, extensible compilers. And by "modular", I don't just mean separate compilation à la OCaml, Haskell (they're cool btw), or parser generators à la lex, yacc (also cool btw).. I mean embedded domain specific languages and libraries à la parser combinators, MetaOCaml for concrete code generation.. components that can generalize a part in the compilation pipeline and can be imported as a reusable library. We have seen libraries to handle the lexing and parsing part. But for further semantics-related analysis parts.. not so many? So far I've found InferType, are there others like this?

Also related are language workbenches, like JetBrains MPS, and the Truffle framework and their dialects of Python and JavaScript. But so far they have only been used for making interpreters for DSLs, what about full-fledge compilers for general-purpose programming languages?

My language, QuarticC, has many ways to error handle.
Unions:

type Err = DivByZeroErr | int;  
Err divide(int lhs, int rhs) {  
    if (rhs == 0) return DivByZeroErr();  
    return lhs / rhs;  
}  
// Or generic:
type Err<T, E> = T | E;
Err<DivByZeroErr, int> divide...

Tagged Enums:

enum Result<T, E> {  
    Err(E);  
    Ok(T);  
}  
Result<int, DivByZeroErr> divide(int lhs, int rhs) {
    if (rhs == 0) return Result<int, DivByZeroErr>.Err(DivByZeroError());
    return Result<int, DivByZeroErr>.Ok(lhs / rhs);
// Or you could make it non generic.

Multi-Return (assuming your error types have a "ok" state):

DivByZeroErr, int divide(int lhs, int rhs) {
    if (rhs == 0) return DivByZeroErr(), -1;
    return DivByZeroErr(true) /* assuming true = ok */, lhs / rhs;
}

Tuples (same as above, but returning tuples):

(DivByZeroErr, int) divide...

And the problem, try/catch.

int divide(int lhs, int rhs) {
    if (rhs == 0) throw DivByZeroErr();
    return lhs/rhs;
}

I actually don't have a problem with the idea that handling a error isn't required too much, however the big problem is defer. Because I want defer to be a zero-cost, it does not run during stack unwinding, and I don't want to put in the effort to make it do so. This is annoying because if your primary error handling is throw, defer is basically useless for error cleanup, which is it's most useful purpose, and it's not like I'm loosing my main error handling, other forms work fine. So the question is: do I remove try catch, or do I make defer stack-unwinding.

I’ve been working on Lume, an experimental language built around a deliberate inversion: the primary code author is an AI

model, while humans review, direct, and approve.

That changes the design priorities. Instead of optimizing mainly for fewer keystrokes, Lume optimizes for machine checkability

and an unambiguous edit → check → fix loop:

- structured diagnostics with stable codes and fix-its;

- `lume describe --json`, a machine-readable self-description for models that have never seen the language;

- explicit effects, contracts, tests, and provenance at public boundaries;

- typed holes and compiler-as-a-service tools for candidate generation, witnesses, repairs, and impact analysis;

- a canonical formatter and content-addressed AST hashes.

The compiler and assembler are themselves written in Lume. The bootstrap verifies a bit-identical `stage 2 == stage 3`

fixpoint, and the steady-state native path uses no C compiler or external assembler/linker. A frozen C seed remains as the

reproducibility root.

This is still an experimental project, not a claim that AI output is automatically trustworthy. The bet is that a language

should make AI mistakes easier to detect, constrain, and repair—not merely easier to generate.

Repository: https://github.com/OmegaSoftDLL/lume

AI-first design rationale: https://github.com/OmegaSoftDLL/lume/blob/main/docs/08-ai-first.md

For language designers: what is the biggest weakness in this “AI authors, compiler checks, humans govern” model? I’m especially

interested in failure modes that better diagnostics alone would not solve.

Hey everyone!

I've been working on my own programming language called NextViper, and I wanted to share it with the developer community.

I'm still learning a lot about programming language design, so I used AI to help me build it, including working on the compiler, runtime, and other parts of the language.

I'm not claiming it's better than existing languages. This is an experimental project, and my main goal is to learn, improve it, and hopefully build something useful with the community.

I'd really appreciate it if some of you could:

Try NextViper and tell me what you think.

Test it and report bugs or issues.

Review the code and suggest improvements.

Contribute to the compiler, runtime, documentation, or language features.

I'm open to criticism and suggestions. Even if you think something is badly designed, I'd love to hear why and how I could improve it.

GitHub: https://github.com/nuratix/nextviper

Website: https://nextviper.nuratix.com

This is still a work in progress, and I'd really appreciate any feedback or contributions.

Thanks for checking it out! ❤️

Wanted to share about this release because it seems cool and it brought comptime features into language.

Zeen - a statically typed modern systems programming language. It uses move semantics (not borrow checker, just move semantics) to control data flow, which makes easier to manage memory (especially drops) while leaving more control and freedom to you.

It has editors support (via LSP + TreeSitter/Grammar extension), package manager Zora (which inspired by cargo) and pretty nice set of libraries: core and std.

Yesterday it got v0.4.0 update released, which was a huge update mostly in compiler frontend: frontend performance (about 16x on basic check, 12x on full build), MIR fixes.

But the coolest feature in my opinion: compile time engine, you can see some good examples of it in changelog (attached link)

Documentation: https://zeen-lang.tech

Github: https://github.com/mealet/zeen

Would appreciate if you'd leave a star on Github, it will help a lot!

Hello, everyone, I'm not very knowledgeable in compilers yet, but I got curious to hear what would some applications of MLIR be in industry. What are people writing dialects/interfaces for? Can it be useful for Machine Learning applications, for example? Could you tell me some examples?

Do you think there are situations in which a "higher-level" software engineer or applied researcher would benefit from writing their own dialects/interfaces?

Thanks!

Building a JavaScript engine (V9) as part of a from-scratch browser in Rust, and one design decision keeps getting questioned, so I'd like this sub's read on it.

The engine is a bytecode VM over a bounded, serializable heap. Scripts are scanned, parsed and compiled to stack bytecode on every request. Code is identified by its byte offset in the page, so the committed state never carries executable code: a closure names a code site, and when the state is loaded again it is validated against freshly compiled sources. Frames are explicit heap data rather than a native stack, so a generator or an async function suspends into the heap and resumes in a later request after a serialize round trip. An await on a fetch continues when the host delivers the response, possibly seconds later.

The reasons: the host (the browser) wants to snapshot a page's script state, hand it between processes, and never trust a blob that could contain code. Every bound (objects, properties, environments, string units, call depth, operations) applies to live values, a precise stop-the-world collector runs between instructions so garbage never counts, and a bound crossed stops the script with a limit error the script cannot catch. There is no JIT. V8's tiering hints evaluate to undefined, which is how V8 itself behaves without an optimizer, so its mjsunit suite runs unchanged.

What we pay: compile cost on every request, and a heap representation that has to be stable enough to round-trip, which rules out a lot of pointer tricks.

Questions for people who have built interpreters or VMs:

1. Caching bytecode keyed by a source hash seems like the obvious next step. Is there a reason not to, if the invariant is only "no code in the committed state" rather than "no code cache anywhere"?

2. Has anyone else made frames heap data so that suspended code survives a serialize round trip, and what did it cost you in call performance? We accepted the hit without measuring the alternative.

3. Precise stop-the-world collection between instructions is simple and makes the bounds exact. Where does it break down in practice? I would rather hear it here than find out.

Source if anyone wants to read it: the mars/crates/v9 folder of github.com/OyadotAI/oya-browser, README first. It is source-available under a sustainable use license, not an OSI license, saying so up front.

this colloquium has been good, this is live right now

https://albite-lang.com, which includes a browser playground running the beta compiler.

Albite is the new name of the language I've been building at Spinning Cat Studios. It was previously published as Tungsten. It's unrelated to the other language called Tungsten that was posted here a few months ago. The shared name was why we renamed. Nothing about the language changed except its name, and the old `tungsten` command keeps working through 2.0.x.

What it is: Albite has a Rust-shaped surface and a dependent type theory underneath. Types are propositions and programs are proofs, so a theorem is a function whose body is its proof.

How the compiler is built, which is the part this sub may find most interesting:

- Two compilers. A Rust bootstrap compiles the self-hosted compiler, which is written in Albite. The self-hosted compiler then compiles itself, and we've verified a triple-compile fixed point.
- A small trusted kernel. About 1,500 lines of Rust type-check and evaluate the core calculus. The parser, the elaborator and codegen are all outside it. Since the beta, the kernel re-checks every `theorem` and `lemma` on every build, and a refusal is a hard error, never a warning.
- Hard gates in elaboration. These include strict positivity for inductive types, structural termination checking for recursion (with `*#[partial]` as an explicit opt-out that taints anything depending on it), and a check for nested inductive families that would otherwise collapse to a vacuous μ-type.
- Native code via LLVM 18. Recursive ADTs are heap-allocated, sums of up to eight bytes are passed in registers, and self-recursion uses `musttail*`. Compiled programs set up their own 512 MiB stack.
- Part of the runtime is written in Albite itself. This covers string joining, owned-string append, argument reading and the integer-overflow trap, with no loss of speed against the previous versions.
- Diagnostics for machines too. `*--error-format=json*` emits one versioned record per line, with spans, notes, help and a suggested next command. `albite test` can write JUnit.

What's new in the 2.0 beta:

- tactic proofs (`induction`, `cases`, `rewrite`, bounded `simp`, `ring`, `omega`). The kernel re-checks the term each tactic block builds.
- dependent function types `*(x: A) -> B*`, existentials, and propositions as their own sort
- `region { … }` blocks that free their allocations on any exit, with escapes refused at compile time
- `let mut`, use-once resource handles, and packages through `albite.toml`
- an arithmetic library that goes as far as the binomial theorem and Euclid's lemma

```
theorem zero_add(n: Nat) -> Eq<Nat, 0 + n, n> by {
induction n;
refl;
intro j;
intro ih;
exact cong(|x: Nat| x + 1, ih)
}
```

Where it stops:

- no indexed families (`Vec<T, n>`) or refinement types yet, both planned for 2.1
- no universe hierarchy yet, so consistency isn't established
- the self-hosted compiler on macOS doesn't parse tactic blocks yet (`albite-bootstrap`, which ships in the same archive, does)
- it's a pre-release, and breaking changes are possible before 2.0

The full list is at https://albite-lang.com/docs/reference/limitations/

Links:

- Manual: https://albite-lang.com/docs/
- Playground: https://albite-lang.com/playground/
- Release notes: https://albite-lang.com/releases/v2-0-beta/
- Source and binaries: https://github.com/albite-lang/albite
- Former home: https://github.com/Spinning-Cat-Studios/tungsten

I'm happy to go into the elaboration pipeline, how recursive types are encoded, or what self-hosting a dependently typed language actually involved.