Live data from Hacker News

Becoming a compiler engineer

rona.substack.com

21–30 of 160 posts

Re: Becoming a compiler engineer

#21
post #5

Earlier quoted context omitted.

I mostly disagree. First, LLMs should be happy to use made up languages described in a couple thousand tokens without issues (you just have to have a good llm-friendly description, some examples). That and having a compiler it can iterate with / get feedback from. Second, LLMs heavily reduce ecosystem advantage. Before LLMs, presence of libraries for common use cases to save myself time was one of the main deciding f…

Have you tried having an LLM write significant amounts of, say, F#? Real language, lots of documentation, definitely in the pre-training corpus, but I've never had much luck with even mid sized problems in languages like it -- ones where today's models absolutely wipe the floor in JavaScript or Python.

Humans can barely untangle F# code..

Re: Becoming a compiler engineer

#24
Great article. Here is a very simple test that I use to find very cracked compiler engineers on this site.

Just search for either of the words "Triton", "CUDA", "JAX", "SGLang" and "LLVM" (Not LLM) and it filters almost everyone out on "Who wants to be Hired' with 1 or 2 results.

Where as if you search "Javascript", 200+ results.

This tells me that there is little to no interest in compiler engineering here (and especially in startups) unless you are at a big tech company or at one of the biggest AI companies that use these technologies.

Of course, the barrier is meant to be high. but if a recruiter has to sift through 200+ CVs a page of a certain technology (Javascript), then your chances of getting selected against the competition for a single job is vanishingly small.

I said this before and it works all the time, for compilers; open-source contributions to production-grade compiler projects with links to commits is the most staightforward differentiator and proof one can use to stand out against the rest.

Re: Becoming a compiler engineer

#25
post #5

Earlier quoted context omitted.

I mostly disagree. First, LLMs should be happy to use made up languages described in a couple thousand tokens without issues (you just have to have a good llm-friendly description, some examples). That and having a compiler it can iterate with / get feedback from. Second, LLMs heavily reduce ecosystem advantage. Before LLMs, presence of libraries for common use cases to save myself time was one of the main deciding f…

Have you tried having an LLM write significant amounts of, say, F#? Real language, lots of documentation, definitely in the pre-training corpus, but I've never had much luck with even mid sized problems in languages like it -- ones where today's models absolutely wipe the floor in JavaScript or Python.

I’m doing Zig and it’s fine, though not significant amounts yet. I just had to have it synthesize the latest release changelog (0.15) into a short summary.

To be clear, I mean specifically using Claude Code, with preloaded sample context and giving it the ability to call the compiler and iterate on it.

I’m sure one-shot results (like asking Claude via the web UI and verifying after one iteration) will go much worse. But if it has the compiler available and writes tests, shouldn’t be an issue. It’s possible it causes 2-3 more back and forths with the compiler, but that’s an extra couple minutes, tops.

In general, even if working with Go (what I usually do), I will start each Claude Code session with tens of thousands of tokens of context from the code base, so it follows the (somewhat peculiar) existing code style / patterns, and understands what’s where.

Re: Becoming a compiler engineer

#26
Interesting article to get a bit more knowledge about the field. I went quickly trough some of the books cited and I have the same feeling that they’re not very practical. Also I didn’t find many practical books about LLVM either.

I would like to read in the future about what is the usual day of a compiler engineer, what you usually do, what are the most enjoyable and annoying tasks.

Re: Becoming a compiler engineer

#27
post #5

Earlier quoted context omitted.

I mostly disagree. First, LLMs should be happy to use made up languages described in a couple thousand tokens without issues (you just have to have a good llm-friendly description, some examples). That and having a compiler it can iterate with / get feedback from. Second, LLMs heavily reduce ecosystem advantage. Before LLMs, presence of libraries for common use cases to save myself time was one of the main deciding f…

Have you tried having an LLM write significant amounts of, say, F#? Real language, lots of documentation, definitely in the pre-training corpus, but I've never had much luck with even mid sized problems in languages like it -- ones where today's models absolutely wipe the floor in JavaScript or Python.

Even best in class LLMs like GPT5 or Sonnet 4.5 do noticeably worse in languages like C# which are pretty mainstream, but not on the level of Typescript and Python - to the degree that I don't think they are reliably able to output production level code without a crazy level of oversight.

And this is for generic backend stuff, like a CRUD server with a Rest API, the same thing with an Express/Node backend works no trouble.

Re: Becoming a compiler engineer

#28
post #24

Great article. Here is a very simple test that I use to find very cracked compiler engineers on this site. Just search for either of the words "Triton", "CUDA", "JAX", "SGLang" and "LLVM" (Not LLM) and it filters almost everyone out on "Who wants to be Hired' with 1 or 2 results. Where as if you search "Javascript", 200+ results. This tells me that there is little to no interest in compiler engineering here (and espe…

I can't think of any of my employers I've had in the last 15 years that would have cared that I committed code to a compiler project, with one exception. That one exception would have told me they'd rather have me work on a different product than the one I was applying to, despite the one I was applying to being more interesting to me than debugging compilers all day.

YMMV, I guess, but you're better off demonstrating experience with what they're hiring for, not random tech that they aren't and never will use.

Re: Becoming a compiler engineer

#29
I've been in compiler engineering now for almost a decade. No grad school, just moved into the field and did a lot of random projects for my own entertainment (various compilers for toy languages, etc). It takes a particular type of person who cares about things like correctness. It is a very bizarre subsection of people with an improbably high number of transgender people and an equally high number of rad trad Catholics.

Which is to say that all it takes is an interest in compilers. That alone will set you apart. There's basically no one in the hiring pipeline despite the tech layoffs. I'm constantly getting recruiting ads. Current areas of interest are AI (duh) but also early-stage quantum compute companies and fully-homomorphic encryption startups. In general, you will make it farther in computer science the more niche and hard you go.

Post reply on HN