Roc rewrites the compiler in Zig

I believe the `\` character for functions is original to Haskell. Miranda does not have anonymous functions as a part of the language.

Well, ML (or at least the first versions of it) used a λx • x syntax [1] for λ-abstractions, the same (excluding the use of • over .) notation as used with the Lambda Calculus, and I've always assumed \ was an ASCII stand in.

[1]: https://homepages.inf.ed.ac.uk/wadler/papers/papers-we-love/... (can be spotted on page 353)

Why? I'm used to \ meaning lambda. I understand you aren't, and that's fine. But it's just your weird opinion determined by what programming languages you've learned.

Ultimately, it's just syntax and not so important. Semantics are important.

Point-free is a functional programming style where you avoid assignments and prefer to do everything as a group of nested, mapped, and composed functions. It relies heavily on partial application. Like everything, it can be good when used in moderation.

Here's a made-up JS example. I've attempted to be fair to both approaches doing it how I personally would with each.

    //typical implementation
    const howManyAdults = (data) => {
      const adults = data
        .flatMap(obj => obj.type === 'parent' ? [obj, ...obj.children] : obj)
        .filter(obj => typeof obj.age === 'number')
        .filter(obj => obj.age >= 18 && obj.age < 150)

      adults.forEach(adult =>
        console.log(`${adult.name} is an adult age ${adult.age}`)
      )

      return adults.length
    }


    //nice "point-free" implementation using helper functions
    const transformData = obj => obj.type === 'parent' ? [obj, ...obj.children] : [obj]
    const isAdult = obj => obj.age >= 18 && obj.age < 130

    const howManyAdults = pipe(
      flatMap(transformData),
      filter(hasTypeOf('age', 'number'),
      filter(isAdult),
      logEach`${pick('name')} is an adult age ${pick('age')}`,
      len,
    )


    //completely point-free gets crazy
    const howManyAdults = pipe(
      flatMap(ifElse(
        compose(eq('parent'), pick('type')), 
        juxt([identity, pick('children']),
        identity,
      ), []),
      filter(hasTypeOf('age', 'number'),
      filter(both(gte(pick('age',18), lt(pick('age'), 130)))),
      logEach`${pick('name')} is an adult age ${pick('age')}`,
      len,
    )

Personally, I rather like reading the moderate middle example because it removes the boilerplate and allows me to easily follow the overall flow without getting caught up in the details. But I'll take the first example every time if it means never dealing with the third example.

It's in the FAQ. Someone else posted a link to it in the comments, check it out. And yes, it is about tacit programming.

It doesn't assume it, it's syntax, you can just use it without knowing where it comes from.

It's like english. You don't need knowledge in obscure proto-germanic linguistics to use articles in your sentences. But if you want to understand why we seem to randomly attach "a" before nouns— proto-germanic linguistics has the answer (probably, I just speak english I don't know where all its syntax originates).

Functional programming is common in university curriculum. Terrifying that it can still be considered obscure.

Lean does symbols very well. You can just type \r and it will replace it with a right arrow as you type.

Board games and craft beers are utterly unrelated objects who have commonality on essentially no axes (except sitting on tables, I guess). And, yet, if you like one, there's a very good chance you like the other.

I think that's where the sentiment comes from. It's not that Rust is similar to C++ in terms of the actual languages and their features. It's that people who like C++ are morely likely to like Rust than people who like C are.

I would argue that C is not a minimalistic language either. There is a lot under the hood in C. But it feels small in a way that Rust and C++ don't.

I think Rust and C++ appeal to programmers who are OK with a large investment in wrapping their head around a big complex language with the expectation that they will be able to amortize that investment by being very productive in large projects over a large period of time. Maybe sometimes the language feels like trying to keep a piece of heavy duty machinery from killing you, but they're willing to wrestle with it for the power you get in return.

The people who are excited about Zig and C wants something that feels more like a hand tool that doesn't demand a lot of their attention and lets them focus on writing their code, even if the writing process is a little more manual labor in return.

Today all of the code I'm not paid to write is in Rust. I spent many happy years previously getting paid to write C (I have also been paid to write Java, PHP, Go and C#, and I have written probably a dozen more languages for one reason or another over the years but never as specifically a thing people were paying me to do)

I always thought C++ was a terrible idea, from way before C++ 98, I own Stroustrup's terrible book about his language, which I picked up at the same time as the revised K&R and it did nothing to change that belief, nor have subsequent standards.

However, I do have some sympathy for this sentiment about Rust being a better C++. Even though Rust and C++ have an entirely different approach to many important problems the syntax often looks similar and I think Zig manages to be less intimidating than Rust for that reason if you don't want that complexity.

Personally I had no interest in C++† and I have no serious interest in Zig.

† Ironically I ended up caring a lot more about C++ after I learned Rust, and most specifically when understanding how Rust's HashMap type works, but I didn't end up liking C++ I just ended up much better informed about it.

It is not about memory safety or anything like that. It is about simplicity.

If you say "you can't do x with y in C++" you will get an "yes you can, you just use asd::dsadasd::asdadqwreqsdwerig_hfdoigbhiohrf() with weaorgoiawr flag". From what I have seen from Rust, it is similar. I don't want to fill my brain with vim bindings.. cough.. Rust ways of doing something. I just want to code my hobby game engine v7.

That said, I am happy to use software written in it. Even though the evangelists can be really annoying.

> † Reference counting is a form of garbage collection.

I agree with Raymond Chen's take on the academic definition of GCs[1], and therefore Rust is certainly a GC'd language (because your code behaves as though memory is infinite... usually). It's probably one of the first examples of "static garbage collection" - though I'm sure someone will point out a prior example.

[1]: https://devblogs.microsoft.com/oldnewthing/20100809-00/?p=13...

> There is no corresponding popular replacement for C that's more minimalist than Rust and memory safe.

In the real world, memory safety is not all-or-nothing (unless you're willing to concede that Rust is not safe either, since unsafe Rust exists). I'm working on an embedded project in Rust and I'd MUCH rather be using Zig. The only safety thing that Rust would give me that Zig does not is protection from returning pointers to stack-allocated objects (there are no dynamic allocations and no concurrency outside of extremely simple ISRs that push events onto a statically allocated queue). But in exchange I have to deal with the presence of unsafe Rust, which feels like a gigantic minefield even compared to C.

The similarity between C++ and Rust is that both bust your balls with complexity for programming at large. And the inverse goes for C and Zig.

Those are the axes relevant to the parent in the context of their comment - not specific language semantics or core features.

> > I was looking for a replacement for C, but Rust is actually a replacement for C++. Totally different beast - powerful but complex.

> The difference between Rust and basically any other popular language is that the former has memory safety without GC†. The difference between C++ and C is that the former is a large multi-paradigm language, while the latter is a minimalist language. These are completely different axes.

Indeed. Let one axis be the simple/multi paradigm. Let the other axis be no memory management / automatic memory management without GC / GC. This divides the plane into 6. In the simple + no memory management sits C and Zig, and in the multiparadigm + memory safe without GC segment sits C++ and Rust.

> There is no corresponding popular replacement for C that's more minimalist than Rust and memory safe.

Those are some weird requirements for "being a replacement", but it is obviously true, as you picked them such.

It's not a perfect analogy, but if you want to put yourself in the shoes of the people making it:

1. Rust is an immensely complicated language, and it's not very composable (see the async debacle and whatnot). On the simple<->complex slider, it's smack dab on the right of the scale.

2. Ignoring any nitpicking [0], Zig is memory-safe enough in practice, placing it much closer to Rust than to C/C++ on the memory safety axis. My teammates have been using Zig for nearly a year, and the only memory safety bug was (a) caught before prod and (b) not something Rust's features would have prevented [1]. The `defer` and `errdefer` statements are excellent, and much like how you closely audit the use of `unsafe` in Rust there is only a small subset of Zig where you actually need to pull your magnifying glass out to figure out if the code has any major issues. In terms of memory issues I've cared about (not all conforming to Rust's narrow definition of memory safety), I've personally seen many more problems in Rust projects I contribute toward (only the one in Zig, plus a misunderstanding of async as I was learning the language a few years ago, many of varying severity in Rust, at this point probably more code written in Zig than Rust, 10yoe before starting with either).

With that in mind, you have C/C++ on the unsafe axis and Zig/Rust on the safe axis. The complexity axis is self-explanatory, fleshing out the analogy.

Is Zig memory-safe? No, absolutely not. Does that mean that Rust will win out for some domains? Absolutely. In practical terms though, your average senior developer will have many memory safety bugs in C/C++ and few in Zig/Rust. It's a reasonable way to compare and contrast languages.

Is it a perfect description? No, the map is not the territory. It's an analogy that helps a lot of people understand the world around them though.

[0] Even Python is simpler than Rust, and it's memory-safe. If we're limiting ourselves to systems languages, you still have a number of options like Ada and Coq. Rust is popular because it offers a certain tradeoff in the safety/performance/devex Pareto curve, and because it's had a lot of marketing. It's unique in that niche, by definition, but it's far from the only language to offer the features you explicitly stated.

[1] It was just an object pool, and the (aggregate) resetting logic wasn't solid. The objects would have passed through the borrow checker with flying colors though.

Edit: To your GC point, many parts of Rust look closer to GC than not under the hood. You don't have a GC pause, but you have object pools (sometimes falling back to kernel object pools) and a variety of allocation data structures. If RC is a GC tactic, the extra pointer increment/decrement is negligible compared to what Rust actually does to handle its objects (RC is everything Rust does, plus a counter). That's one of my primary performance complaints with the language, that interacting with a churn of small objects is both expensive and the easiest way to code. I can't trust code I see in the wild to behave reasonably by default.

> Go is not a C or Python replacement.

Google stopped writing new Python, because they found that the same engineers would produce software with similar defect rates, at a similar price and in similar time, with Go, but it would have markedly better performance, so, no more Python.

Go manages to have a nice sharp start, which means there are going to be a bunch of cases where you didn't need all the perf from C, but you did need a prompt start, so, Java was not an option but Go is fine.

In my own practice, Rust entirely replaces C, which has previously been my preferred language for many use cases.

> But Rust has tons of extra features that C doesn't have, just like C++.

C++ has tons of extra features over C because it's a kitchen sink language. Rust has some extra features over C because in order to support static analysis for memory safety in a practically usable manner, you need those features. In practice, there are lots of C++ features that Rust doesn't bother with, especially around templates. (Rust just has a more general macro feature instead. The C++ folks are now on track to adding a clunky "metaclass" feature which is a lot like Rust macros.)

> Moving from C++ to Rust is a sideways move.

In what sense? Features or complexity? From a productivity/correctness perspective, Rust is a huge step up over C++.

> Zig is a good replacement for C.

I have never used zig, although I have looked into it. I have used C and C++ for a long time, and would like a replacement for C.

To my mind zig is nowhere near a good replacement for C. It adds way too much extra stuff (e.g. metaprogramming). A good replacement for C would have a similar simplicity and scope to C (i.e. a portable assembler) but address known issues. For example it should fix the operator precedence rules to be sane. It should close-off on undefined behavior and specify things more formally than C, and still allow low-level memory manipulation. To be even better than C it should allow stuff that would be obviously correct in assembler, but is UB or ID in C.

Go has plenty of bad design decisions, but not being a safer C isn't one of them.

TinyGo and TamaGo folks enjoy writing their bare metal applications on embedded and firmware.

https://github.com/carp-lang/Carp

posted yesterday:

https://news.ycombinator.com/item?id=42923829

Sure, in the sense that in C++ they've got the Head Of Vecna: https://rpgmuseum.fandom.com/wiki/The_Head_of_Vecna

Many of my favourite Rust features aren't in C++. For example they don't have real Sum types, they don't have the correct move semantic, they are statement oriented rather than expression oriented and their language lacks decent built-in tooling.

But also, some of the things C++ does have are just bad and won't get fixed/ removed because they're popular. And there's no sign of it slowing down.

I think that in practice you should use Rust in most places that C++ is used today, while some of the remainder should be WUFFS, or something entirely different.

explanation needed, bro.

nerdy langnoob or noobie langnerd here. not sure which is which, cuz my parsing skills are nearly zilch. ;)

The swizzling is pretty cool, rather special purpose but it makes sense that Ginger Bill wanted this and it's Ginger Bill's language.

Odin's "standard library" stuff is very silly, it still feels like we were just copy-pasted the lead developer's "useful stuff" directory. Bill doesn't feel there's a value to actual standard libraries, so instead here's... whatever. He insists that's not what's going on here, but that doesn't change how it feels.

Odin has commercial applications, basically all the JangaFX apps... But yeah, it's missing a killer open source app. Positive is it has a decent amount of batteries included.

> I've only really seen Odin mentioned on X, not even a HN post.

But there are some: https://hn.algolia.com/?q=Odin

I'm not a devotee to the creator of Odin. Odin may be fine, but I'm hesitant when it comes to contributing to it. Welp. Life goes on.

I am also skeptical.

A compiler is a function from source code strings to binary bytes. Writing out instructions to do memory-unsafe things is not in itself a memory-unsafe activity.

I believe the main reason is for achieving the best possible performance. Someone closer to the compiler could give more detail.

It's not just the lang but the std lib too

https://www.roc-lang.org/faq#rust-and-zig

At this point it feel like the are just playing with languages.

I know that, and obviously you can write a recursive descent parser in OCaml

But I'm saying there's nothing better about it than doing it in OCaml vs. C++ or Python -- it's the same or a little worse

IMW it's natural to express the interface to a lexer and parser as classes -- e.g. you peek(), eat(), lookahead(), etc.

Classes being things that control mutation

But objects in OCaml seem to be a little separate dialect: https://dev.realworldocaml.org/objects.html

When I debug a parser, I just printf the state too, and that is a little more awkward in OCaml as well. You can certainly argue it's not worse, but I have never seen anyone argue it's better.

---

Culturally, I see a lot of discussions like this, which don't really seem focused on helping people finish their parsers:

https://discuss.ocaml.org/t/why-a-handwritten-parser/7282/7

https://discuss.ocaml.org/t/good-example-of-handwritten-lexe...

I also use lexer/parser generators, and I like that there are more tools/choices available in C/Python than in OCaml.

Have you not read the post? Because compile times. Rust has awful compile times. If it didn't, I'm sure the Roc team would have stayed with Rust.

Since at least 2018, there's been a planned upgrade to the borrow checker to permit certain patterns that it currently rejects [0]. Also since 2018, there's been an implementation of the new version (called Polonius) that can be enabled with an unstable compiler flag [1].

But now it's 2025, and the new version still hasn't been enabled on stable Rust, since the Polonius implementation is seen as far too slow for larger programs. (I'm not exactly sure how horrible it really is, I haven't looked at the numbers.) A big goal of the types team since last year has been to reimplement a faster version within rustc [2].

I'd count this as a language feature (albeit a relatively minor one) that's been greatly deferred in favor of shorter compile times.

[0] https://blog.rust-lang.org/inside-rust/2023/10/06/polonius-u...

[1] https://github.com/rust-lang/rust/pull/51133

[2] https://rust-lang.github.io/rust-project-goals/2024h2/Poloni...

ABI stability is one of those things that seems obvious ("sane"), until you try to implement ABI-stable unboxed generics and discover that the amount of complexity you incur, as well as the performance tax, is absurd. The code bloat with the resulting "intensional type analysis" actually makes the compile time worse (and the runtime far worse) than just specializing generics in many cases.

I’m assuming the previous commenter thought you were referring to Roc being pre v1 and not Zig.

There are probably some risks to it. And I think that you wouldn’t want to release a Roc v1 before Zig v1 as well.

But if things are working well now, you could always stay on an older version of Zig while you rewrite things for breaking changes in a newer version.

Still potentially a pain, but Rust is post v1 and they ended up deciding to rewrite anyway, so there are no guarantees in any approach.