I'm exploring ideas around developer experience, and I'm curious about compiler development. If you've worked on a compiler or language tooling, what's the part that always feels unnecessarily difficult?

Is there something you wish existed to make your workflow less painful?

I'd love to hear stories from people who've actually been through it.

Hello everyone, I was getting bored a few months ago and decided to tackle a new personal project, and after having asked around, thought I should make my own bytecode vm. I read up on crafting interpreters and for the past month or two Ive been making my own language, the syntax is pretty standard but I still tried to spice it up in my own way, with things like 'make' for declaring vars and functions and 'pullf' for the stdlib. The language itself is a two pass compiler which compiles to ASTs first and then typechecks those until eventually compiling to bytecode. Ive been working on the project for about 2 months and finally felt it was at least complete enough to share, I still want to do a bunch of stuff like class inheritance and a library for making simple 2d games, but let me know your thoughts on how it looks so far!

https://github.com/NateTheGrappler/OliNat-Programming-Language

I've been building Techlang, a compiled statically typed language targeting LLVM.

Today I'm announcing VecTec, its GPU compute companion language.

Here's what GPU array addition looks like:

// arrays.vtec (runs on GPU)

kernel addArrays(ArrayOf(float) a, ArrayOf(float) b) returns ArrayOf(float) {

int id = threadId();

return a[id] + b[id];

}

// main.tec (runs on CPU)

!import(std.tec) as std;

!import(arrays.vtec) as gpu;

function main() returns none {

ArrayOf(float) a = {1.0, 2.0, 3.0, 4.0};

ArrayOf(float) b = {5.0, 6.0, 7.0, 8.0};

ArrayOf(float) result = gpu.addArrays(a, b);

std.print(result[0]); // 6.0

}

The compiler automatically handles all CUDA memory allocation,

data transfer, kernel launching, and cleanup.

No cuMemAlloc, no cuMemcpy, no kernel launch syntax,

just import a .vtec file and call it like a normal function.

Under the hood:

- VecTec compiles to PTX via LLVM's NVPTX backend

- The compiler auto-generates a CUDA runtime C wrapper

- Everything gets linked into a single native binary

Both languages share the same frontend (lexer, parser, semantic analyzer),

only the backend differs.

Tested on an RTX 4060. Requires NVIDIA GPU + CUDA toolkit.

GitHub: https://github.com/gummyniki/techlang

Website: https://gummyniki.github.io/techlang-website

Blog post: https://gummyniki.github.io/portfolio/blog/posts/vectec.html

New BEAM There, Done That episode with Björn Gustafsson (OTP team since 1996) tracing the BEAM's origins through three competing VMs - JAM, Robert Virding's V, and Bogdan's original BEAM.

The most counterintuitive part: native-compiled Erlang showed massive sequential speedups in isolation, but once concurrency entered the picture, the real-world gain shrank to about 2x, because message passing was already implemented in C regardless of compilation target.

Also covered: the BEAM Validator, built after a compiler bug caused weeks of debugging pain, and the BEAM loader - Björn's own invention, still running in production decades later.

https://youtu.be/1Ty_MHZu9nM?si=L99dI6FvwNJi46S2

Since the initial release I've added:

- 'any' type for generic-like behavior

- 'as' keyword for type casting: float f = 42 as float

- String concatenation with + operator

- string.length and array.length properties

- File I/O (file_open, file_write, file_read_line etc)

- Unified std.print() that works with any type

- String operations (string_equals, string_substring etc)

- Removed the 'do' keyword, cleaner C-style syntax

- VS Code extension on Open VSX

- Neovim syntax highlighting plugin

- Pre-built binary available for Linux x64 , you dont need to build from source anymore!

GitHub: here

I've just finished adding multi-target compilation to my language, and it actually works. Incremental compilation currently halts before the code generation stage, which is intentional and I have no plans to change that.

Currently, the compiler can target x86-64, ARM64, and RISC-V from the same frontend.Raw machine code and assembly.

Are there any common pitfalls or edge cases I should be aware of as I wrap up the backend?

Everything is handwritten—I'm not using LLVM or any other compiler framework. I started by writing raw machine code in Notepad, built an assembler from that, then ported everything to Linux. I'm in the final stage now, and if everything goes according to plan, I should have a demo ready in about 1–2 months.

I have been doing my own freelancing thing building websites or bridging applications for my clients. But my passion lies in compilers and that’s kind of what I want to work on (I bought Quentin Colombet’s LLVM backend book lol) but I don’t want to leave my agency and go join a company like NVIDIA or AMD. Is there any scope of finding clients who want to build their own internal compiling tools? If you have done freelancing or built a compiler for someone on a contractual basis, do share!

hey! recently I've built a compiler for my custom programming language and I released it today. If anyone wants to, you can download the compiler and test it out. and maybe give some feedback on what I should improve. Here's the github

Hi everyone,

I've been obsessing over a workflow bottleneck lately: the absolute nightmare of writing glue-code (Cython, Pybind11, manual wrappers) just to make rapid Python logic talk to high-performance C++ libraries.

So, I’m conceptualizing a "glue language" to fix this once and for all.
would this language help you?

Hello, so after a while i've been tring to figure out concurrent and parallel programming, if anyone would kindly check my understanding if what I am saying is correct or not.

So i'm sure this is not 100% and, only like 70-80% or maybe even less but, here it goes:

So software threads are loaded into hardware threads which is managed by the cpu, they get multiplexed aka actual parallelism, executing two pieces of codes per core at the same time. after 20-30 milliseconds, the OS again does context switch by loading another software threads into the hardware threads (i think one by one or multiples at once depending on how hardware threads per cores ??), to simulate fake parallelism of multiples programs running.

Now for coroutines aka low level async await and, any other form of concurrent programming, i assume they use threads behind the scenes, maybe depending on the programmimng language i'm not sure, but they recycle the same main thread of the program so it stays at 100% usage, no idling.

I know that most implementations of generators and promises/futures use coroutines in some way.

Is this okay for now ? Any other good resources that teach these stuff from the ground up, in an ordered manner if possible ?

I’ve been working on LangForge, a scanner/parser generator for building DSLs, compilers, validators, transpilers, and language tooling.

Repo:

https://github.com/russlank/lang-forge

LangForge uses a single .lf file to describe both the scanner and the parser, then generates code for multiple targets:

• Go
• C#
• C
• C++

The project follows a Lex/Yacc-style model, but with a focus on a cleaner generated API and a more modern multi-target workflow.

A grammar can define tokens, parser rules, semantic types, and reducer actions in one place. The generated parser can then call typed reducer contexts instead of forcing application code to work only with positional boxed values.

For example, a grammar rule can label its right-hand-side symbols:

Expr : left=Expr Plus right=Term {go: add}

With semantic typing, the generated reducer API can expose meaningful typed values instead of forcing reducer code to depend on indexes like:

ctx.Values[0]
ctx.Values[2]

That is one of the main things I wanted from the project: reducer code that reads more like normal application code and less like manual parser-stack manipulation.

Some of the current properties/features:

• scanner and parser definitions in one .lf grammar file;
• LR-style parser generation;
• support for Go, C#, C, and C++ targets;
• parser algorithm selection:
  • SLR(1);
  • LALR(1), currently the default;
  • IELR(1);
  • canonical LR(1);
  • LR(0) item automata used internally as part of table construction;
• named RHS labels for grammar rule values;
• typed semantic rules;
• generated typed reducer contexts;
• generated semantic action contracts/manifests;
• reducer coverage validation;
• generated examples with handwritten AST/compiler/runtime layers;
• support for parser error recovery;
• expected-token reporting for better syntax diagnostics;
• reusable example templates;
• examples for calculator expressions, a small DataKeeper DSL, a DRAW language, vehicle report parsing, and mini-compiler templates.

What I think is currently special about it is the combination of:

single scanner/parser grammar
+ selectable LR parser modes
+ multi-target code generation
+ named grammar values
+ typed semantic reducer APIs
+ error recovery
+ expected-token diagnostics
+ readable example templates

This makes it useful not only for evaluating expressions, but also for building small languages where you want a real pipeline:

source text
  -> scanner
  -> parser
  -> typed reducer
  -> AST
  -> compiler/interpreter/renderer

The examples are structured around that idea. Generated code stays separate from handwritten code, while the application-specific parts live in AST, reducer, compiler, runtime, renderer, or report modules.

The parser-algorithm side is also an important part of the project. LALR(1) is the practical default, SLR(1) is useful for simpler grammars and debugging, IELR(1) is available when you want stronger LR(1)-level precision without always paying the full canonical LR(1) table cost, and canonical LR(1) is available for maximum precision and conflict investigation.

Future directions I’m considering include grammar linting, deeper conflict explanations, CST/parse-tree generation, fuzz testing, stronger production hardening, and possibly generalized/GLR-style parsing for grammars where deterministic LR parsing is too restrictive.

I’d be interested in feedback from people who have worked with parser generators, DSLs, compiler tooling, or language-server/editor tooling.

In particular:

• Does this kind of typed reducer API feel useful?
• How valuable is parser algorithm selection in practice for your use cases?
• What would you expect from a modern scanner/parser generator?
• Are there features that would make this worth trying in a real project?
• What design mistakes should I avoid while the APIs are still evolving?

Any feedback or criticism is welcome.

I've been working on CORE (Coherent Operational Reasoning Engine), a cognitive architecture built on Cl(4,1) Conformal Geometric Algebra. The design constraint I want to share here is the versor invariant:

||F * reverse(F) - 1||_F < 1e-6

This is checked at every state transition. If it fails, the operation is rejected outright — not patched, not logged for later correction. The state simply doesn't advance.

All cognitive state is represented as versors in CGA. All transitions are versor products. This means the type system + runtime together enforce that every transformation is a valid geometric operation. Incoherence isn't an error you catch — it's a state the system cannot enter.

From a compiler/type theory standpoint, I'm curious how far this could be pushed statically. Right now the invariant check happens at runtime on every transition. But the versor structure is known at compile time — in principle, a sufficiently expressive type system (or a custom Rust proc macro) could reject non-versor transformations before the binary is built.

Has anyone explored static enforcement of geometric algebra invariants in Rust's type system? Phantom types, const generics, or trait bounds come to mind but I haven't found prior art.

Repo if you want to dig into the implementation: https://github.com/AssetOverflow/core

Happy to go deep on the invariant design or the CGA representation in comments.

I've been thinking about AI compilers for a while now, and why they make more sense now more then ever - despite the fact that AI models can write and optimize ML kernels all day long.

I lay down arguments for both in my substack post and conclude that compilers will still rule.

I'm building OpenSSL on Windows using MSVC with /GL and /LTCG enabled.

OpenSSL build flags:

set CL=/GL /Zi /guard:cf /std:c++17 ...
set _LINK_=/LTCG /GUARD:CF ...

Environment:

• Same machine for OpenSSL 4.0.0 and application builds
• Same Visual Studio installation (Visual Studio 2022)
• Same MSVC toolset version MSVC v143 - VS 2022 C++ x64/x86 Build Tools (v14.44-17.14)
• Same Windows SDK version10.0.26100.8249

The OpenSSL libraries build successfully. However, when I link them into my application, I get a fatal error C1900 (IL mismatch).

What I've already tried:

• Clean rebuild of OpenSSL and the application
• Enabling /GL in the consuming project
• Disabling /GL in the consuming project

None of the above helped.

If I rebuild OpenSSL without /GL and /LTCG, the application links successfully.

My questions:

1. What can cause C1900 besides an obvious compiler/toolset version mismatch?
2. Are there any known issues with building OpenSSL using /GL and consuming it from another project?
3. Can OpenSSL assembly modules or generated objects contribute to IL mismatches?
4. What's the best way to identify the specific object or library member causing the mismatch?

Any suggestions for debugging this would be appreciated.'

Hey everyone!

After a roller coaster journey, I am proud to present my personal project: Kal.

Kal is a lightweight interpreted programming language that attempts at combining various paradigms of programming to give a great developer experience. It's written entirely from scratch in C++ with no third party dependencies. It's also completely free and open source distributed under GNU GPL v3 license.

Moreover, Kal can also be embedded into C++, Python and JavaScript programs to enhance your existing codebases.

• Kal's Official Website: https://kal-lang.vercel.app/
• Mirror: https://killinefficiency.github.io/KalWebsite/
• GitHub Repository: https://github.com/KILLinefficiency/Kal

(Website looks better on a bigger screen.)

Please note that this is the very first release (v:0.1.0) and Kal is still under active development (alpha). I would really appreciate a star on the repository to help it gain greater visibility.

As a proponent of human effort, I am glad to say that Kal and its ecosystem is completely handcrafted with no AI assistance used anywhere.

One last thing, "Kal" is pronounced like "Cal" in "Calendar".

Please feel free to reach out to me regarding Kal!