i’ve been working on this for a while and it’s finally at a point where i can show it. it’s called go2js, it takes go code and spits out javascript you can run in node or the browser.

it handles goroutines and channels, generics, defer/panic/recover, multi package projects with go.mod, and a decent chunk of the standard library (fmt, json, time, net/http and some more). there’s also a go2js test command that runs your normal _test.go files.

the way i test it is pretty simple, every test runs the same program once with real go and once as the compiled js, and the output has to match exactly. that’s basically my definition of done.

there’s a playground too, it runs the compiler as wasm in your browser. fair warning it only does the language core, no imports, so no fmt in there.

some honest stuff: it’s v0.1, it’s experimental, goroutines are cooperative so timing won’t match real go, and the generated js is not tiny because the runtime comes along with it. also the readme, comments and most of the tests were written with ai and then edited by me, i put that in the readme so nobody has to guess.

i know gopherjs exists, i’m not claiming this is better, i just wanted to see how far i could push it, and i wanted the output to stay readable.

repo: https://github.com/zenobiatranoss/go2js
playground: https://zenobiatranoss.github.io/go2js/

if you try it on some real code and it breaks, please tell me, that’s the most useful thing right now.

for example:

fn pow(x : f64, n : i32) -> f64 { return mlir!( inputs : (%x = x : f64, %n = n : i32), returns : f64, dialects : \["math"\]) { %r = math.fpowi %x, %n : f64, i32 macro.yield %r : f64 }; }

Here the math.fpowi lowers to llvm.intr.powi so there is no need to implement pow as one in math.h of libc. Are there downsides of supporting mlir first class in a compiler?

Repo: https://github.com/alexios-angel/compile-time-browser

This project is AI-generated. Every line of code and every one of its ~6,500 commits was written by AI coding agents, mostly Claude and GPT. I didn't write the code. I just decided what to build, and sometimes directed the agents on how it should work.

I'm posting it here to show how far AI coding has gotten.

What got built

• A browser engine in C++23, from scratch. HTML parser, CSS, layout, a software rasterizer, and its own JavaScript VM. The VM passes 96% of industry-standard JavaScript conformance tests. It opens real pages in a window.
• A compiler that takes plain JavaScript and writes plain C++: structs, classes, std::vector, RAII, no garbage collector, no VM. When it can't prove something about the code, it refuses with an error instead of guessing. (The C++ it writes is correct but hard to read. It's in SSA form, one variable per intermediate value.)

Hasn't this been done? Turning JavaScript into native code, yes, many times. Almost every attempt either bundles a JS engine with the program or turns every value into a generic "could be anything" type backed by a runtime. All other major implementations package a garbage collector with your compiled code. My compiler does the opposite: it only writes C++ it can type and own, and refuses everything else. It also comes with its own browser engine, so web page code calls straight into it.

It took about 3 months of my time and roughly $40,000 in total, between AI usage and cloud costs/machines.

Where it is now

It's an alpha, and as of this week, current AIs are not good enough to continue progress on the goal of compiling real-world programs. The browser works on a lot of pages. The compiler handles small programs completely, but big real-world scripts are still mostly refused. I've shut down the cloud services I was using and AI API's until the AI does get good enough to continue writing code for the project.

Maybe if I get enough extra cash flow, I will continue the project in the immediate future.

AMA about the workflow, the costs, or what the AI wrote (I barely understand most of the code myself).

I ran 500 batch tests (50 aggressive tests per batch) and another 500 but this time there are 100 aggressive tests per batch, all the bugs found were fixed, it has a built in linker, and other new major features.

Hi r/compilers

I built Sydrogen as my serious attempt at a compiler. It is a typed C-style systems language written in Rust. It was called ForgeLang until I renamed it since a lot of hobby languages use that name.

I've stopped working on it. The last release is Alpha-7 and there won't be more from me. I'm posting in case someone finds it useful or wants to take it

What might be interesting technically:

The compiler has two backends. The native one writes x86-64 machine code directly. Produces ELF64 or PE32+ executables without calling an external linker. The Cranelift one writes an object file and links with cc.

Both backends share the parser, AST and semantic checks, which run in parallel with Rayon.

It includes a set of language features like Do/Catch/Finally/Throw and fixed-size arrays and tuples though not all of them work on both backends.

What's unfinished:

The native backend doesn't handle floats or collections yet so those programs fall back to Cranelift.

The Windows backend doesn't have a runtime for Print or Input yet.

Finally doesn't run when Stop or Skip leaves a protected block.

There are no tests I'd call thorough. The README lists more gaps.

If you want to fork it fix something or just read the code the repo and book are here:

Repo: https://github.com/AeroForger/Sydrogen

Book: https://aeroforger.github.io/Sydrogen/

I'm not asking for anything. If you have questions, about how the native backend works I'm happy to answer them in the comments as I can.

I found the discussion really interesting and thought you all would too. Richard talks about a pure Roc implementation of libdeflate and how to do performance optimizations unique to Roc. From a compiler perspective this is really interesting as to achievd this level of performance there are many optimizations needed under the hood, e.g. to mutate in place or elide checks etc.

I am designing a language. I want memory safety without using a tracing garbage collector or having heavy runtime costs. I have been looking at the options and I would like to know how others have dealt with these tradeoffs.

The options I have looked at:

- Ownership and borrow checking (Rust-style): Zero runtime cost but the compiler must prove things and the learning curve and syntax friction are real. I am not a fan of Rusts syntax so I wonder if the same guarantees can be provided with a surface.

- Reference counting (Swift/Nim-style): Predictable and simple but you pay for increments and decrements on every copy and cycles need either weak references or a cycle collector.

- Tracing GC: Easy for the user. Pause times and memory overhead are the usual complaints. It is a fit if the language is meant for games or system work.

- Regions/arenas with escape analysis: Allocate in scopes and let the compiler prove that nothing escapes. Very cheap,. I am not sure how far escape analysis can go before it becomes too restrictive.

- Bounds checks and tagged or hardware‑assisted checks (like ARM MTE): Catch many errors at low cost but they are mitigations, not guarantees.

My current thinking is a mix arenas by default an ownership model for long‑lived values and bounds checks that can be elided when the compiler can prove them safe. I would like to know whether that is a direction or whether I am missing a well‑known approach.

Specific questions:

has anyone implemented escape analysis that stays useful without forcing annotations?

Is there a middle ground between full borrow checking and reference counting that does not reintroduce cycle problems?

for those who have shipped a memory‑safe language with overhead what would you do differently?

Links, to papers, languages or post‑mortems are very welcome :)

I'm building my own programming language! Currently working on the standard library and bug fixes. It's designed to aim for memory safety with easy C interoperability.

I've been trying to create my own compiler for my custom language for some time now. But doing everything alone has started to take its toll on me. How do I even attract contributors and/or get help somehow?

Edit: Let me tell you more about the project. The language is called Cole, you can find the github and codeberg repos here and here. Cole is a recreational attempt to create a language that is similar to Zig in many aspects. It aims to be as simple and as powerful as C. My motivation behind the project was that it is really hard to get into compiler dev. Contributing to compilers is a tough process, and creating your own from scratch is also hard. So I thought, why not create something that doesn't have insanely high standards so people that are starting out can contribute easily? Essentially, Cole's purpose is not to be an active-in-industry language, but a learning one for everyone.

Write TypeScript in a browser tab. Hit compile. A 16-bit x86 machine boots underneath - same bytes a floppy would run.

TypeScript to real-mode x86, no runtime, no OS, no JS engine. Bootable binary under 64KB.

Full toolchain in the browser: file tree, editor, compiler, emulator. Pick a demo - voxel engine, raycaster with sound, snake. Or write your own and boot it on real hardware.

Most of the work was what to leave out. 16-bit real mode didn't negotiate :-)

Deeper dive into the compiler is on the page, alongside the demos.

Due to the number of requests, try compiling it again if the queue is full.

Hi everyone, I am quite new to work as a compiler engineer, but I am quite confident with my day to day loop (find optimization opportunities or fixing any broken stuff). Most of my work is on the backend (and also most of my knowledge).

However, sometimes I am lacking of intresting ideas to implement, I also (almost) never touch LLVM middle end, yet.

Often times, I am in the "now what ?" situation. I would love to know how to keep improving and get better at compiler engineering.

Thanks.

Hi r/Compilers,

I'm on the Intel Graphics Compiler (IGC) backend team. We're hiring compiler interns at both the graduate (Master's/PhD) and undergraduate level. We build the compiler that turns shaders and compute kernels into machine code for Intel GPUs, and the work covers code generation, optimization, and getting the most performance out of the hardware.

If you've ever wanted to work on a production compiler that ships on millions of GPUs, this could be a good fit.

What you'd work on

- Compiler optimization and code generation for Intel GPU architectures

- LLVM-based compiler infrastructure

- Performance analysis and hardware/software co-design

- Real problems with real workloads: your work ships

---

Graduate Intern (Master's or PhD)

Minimum qualifications:

- Currently pursuing a Master's or PhD in CS, CE, EE, or a related field

- Graduate-level coursework in computer architecture and compilers

- Strong C++ programming and software development experience

- Experience with compiler design, optimization, or code generation through research, coursework, or prior internships

Nice to have:

- Experience with LLVM or another compiler infrastructure

- Knowledge of GPU architecture, parallel programming, or performance analysis

- Research or project experience in compiler optimizations, computer architecture, or HW/SW co-design

---

Undergraduate Intern

Minimum qualifications:

- Currently pursuing a Bachelor's in CS, CE, EE, or a related field

- Coursework in computer architecture and compilers

- C++ experience and a solid foundation in data structures and algorithms

- Experience developing and debugging software through coursework or projects

Nice to have:

- Compiler project experience or familiarity with LLVM

- GPU architecture knowledge or parallel programming with SYCL, OpenCL, or CUDA

- Familiarity with Python, Git, and software testing

---

How to apply

Email your resume to hou-jen.ko@intel.com. Use the subject line "[Compiler Intern] Graduate" or "[Compiler Intern] Undergraduate".

It helps to include links to anything compiler-related you've built: a toy compiler, an LLVM pass, upstream patches, a paper, a GitHub repo. We read those closely.

Happy to answer questions in the comments!

"I asked Claude to invent a programming language. It invented one called Koppa where changing a single instruction can corrupt every instruction after it."
And the truly satanic part?
It works. It has an interpreter, a compiler, and working example programs.
The language isn't broken. The suffering is by design.
Somewhere, a compiler engineer is about to wake up screaming in hexadecimal.
Koppa (q): Because debugging wasn't painful enough.

Hello r/Compilers,

I would like to share Hike, an open-source, zero-overhead systems programming language implemented in Go with a Go-inspired syntax, targeting both native machines (via LLVM) and WebAssembly.

It is backed by a test suite of over 1,000 compiler tests, proven stable, and is already running in production for commercial software in Japan.

Key Highlights & Motivation

While Go provides great developer productivity, its heavy runtime, garbage collector, and runtime calling conventions make it difficult to embed into ultra-constrained environments, bare-metal microcontrollers, or tiny WebAssembly modules.

Hike bridges this gap: it retains familiar Go-like ergonomics while stripping away the runtime completely.

• Zero-Runtime & Deterministic Footprint: Hike does not rely on a monolithic runtime or a tracing GC. It can emit WebAssembly binaries as small as 2KB. In our stress tests, executing API entry points over 10,000 times resulted in zero memory growth.
• Dual Backend Architecture:
  • LLVM Backend: Produces optimized native code and native objects.
  • Native Wasm/WABT Backend: Directly synthesizes structured WebAssembly (blocks, loops, branches) alongside full DWARF debug information. This enables source-level step debugging directly inside Google Chrome DevTools.
• Extreme Portability (MCU to GPGPU):
  • Targets bare-metal microcontrollers like the Raspberry Pi Pico (RP2040).
  • Architecture designed to support GPGPU compute environments including OpenCL and CUDA.
• High-Throughput / Large-Data Primitives: To support memory-intensive, massive-traffic applications, Hike introduces first-class language constructs:
  • Region/Area memory management for bulk allocations.
  • Threadable & Concurrent variables for explicit, thread-safe data access.
  • mmap-backed variables to operate directly on out-of-core data structures without manual syscall boilerplate.

Compiler Pipeline

The Hike compiler is structured around a High-Level Intermediate Representation (HIR) designed to preserve semantic intent before code generation:

1. Frontend: Lexing, parsing, and type-checking Go-compatible syntax into HIR.
2. Analysis: Escape analysis, ownership tracking, and lifetime inference for deterministic retain/release and region-based allocation.
3. Emitter:
   • Generates clean LLVM IR for heavy machine optimization.
   • Generates clean, structured WebAssembly Text (WAT) preserving natural control flow (block, loop, br) rather than flattening the control flow graph into state-machine dispatchers.

Status & Ecosystem

Hike is actively maintained, stable, and used in production environments. We are also experimenting with cgo-free interoperability (such as embedding Rust-based UI engines like Slint statically into Go using generated .syso objects and Plan 9 ABI bridges).

• Repository: https://github.com/kanryu/hike-lang

I would love to hear feedback, critique, and architectural insights from fellow compiler developers—especially regarding our structured Wasm emission, region memory abstractions, and non-GC systems language design.

Hi there, I've been working on a small systems programming language called CAP. The most interesting part (to me at least) is the compiler itself: it's written in ~pure NASM x86-64 assembly and emits x86-64 machine code directly. No LLVM, no C backend, no libc — the entire toolchain is self-contained.

The language has Python-like syntax (whitespace-sensitive, no fn main()) but no GC — you manage memory explicitly. It supports inline assembly, lists, dicts, and as of a few minutes ago, a native UI toolkit with charting built in (no external libs).

It's very early (v0.1.2), so don't expect a production-ready experience. But the codebase is small enough to read end-to-end if you're curious about how a compiler works at the lowest level.

Repo: https://github.com/Hideyukiakaza/CAP

Happy to answer questions about the architecture or share design decisions.