That is what I thought before.

But what this library and some others are aiming for is the NEXT level of parsing difficulty: Parsers that work AND also provide high-fidelity output for SEVERAL consumers (IDE, editors, linters, ...) AND provide high-quality errors (aka: diagnostics) AND provide suggestion to fix that errors.

That is another level!

MUCH HARDER!

I agree that it's the least interesting part (at least for me), but a necessary part to be able to get to the juicy stuff. Getting a quick parser ready helps keep me wanting to code since I don't have to trudge though to get to the fun part.

Can you tell any other part of the compiler ecosystem that helps you write a new programming language in 1 hour?

This is supposed to be a fun article for experimentation in programming languages, not a new advancement in a garbage collection algorithm for increasing the efficiency of a datacenter by 2%.

My favourite new programming language is Svelte for example (just a parser that emits javascript), it's just a little different from HTML/CSS/JS, but just enough to make web development fun again for me.

Rust already has Nom for parser combinators, though. This library looks fine (at first glance) for a parser library, but it doesn't seem like it helps with building languages beyond just parsing (which is what I expected from the title).

The main points of focus for chumsky, beyond nom, are:

- Ease of use + ergonomics

- Backtracking 'by default'

- High quality errors and error recovery

Nom is very specifically designed for parsing input not intended to be read by humans, and that focus is evident in the things is prioritises.

LLVM

The article implements eval() for a couple stages in the language. It's not just parsing.

I mostly agree, this just seems like a case of a weird description in the HN submission. As it is... it's a parser library, the Github project calls it a parser library, and that's fine.

If it helps, I also have tutorials in the works for type inference & type-checking, monomorphisation, optimisation, and possibly codegen too.

Yep. Getting the initial AST/CST is easy. Going from that to whatever your target is is the meat of the entire project.

No where in the title or article did I read "compiler".

A programming language implementation is either a compiler or interpreter. Title says "write your own programming language..." which implies an implementation. But that's not the case. As other commenters point out parser is a tiny, usually inconsequential part of a lang implementation.

The article contains full interpreter?

I wouldn't call it a full interpreter, it just walks expressions' AST. No way to create class/abstractions.

Nearly all mature language implementations are compilers to some extent