[isaacvando]

Roc couldn't be optimized for writing the Roc compiler without sacrificing some of its own goals. For example, Roc is completely memory-safe, but the compiler needs to do memory-unsafe things. Introducing memory-unsafety into Roc would just make it worse. Roc has excellent performance, but it will never be as fast as a systems language that allows you to do manual memory management. This is by design and is what you want for the vast majority of applications.

There are a number of new imperative features that have been (or will be) added to the language that capture a lot of the convenience of imperative languages without losing functional guarantees. Richard gave a talk about it here: https://youtu.be/42TUAKhzlRI?feature=shared.

[int_19h]

It still feels kinda weird. Parsers, compilers etc are traditionally considered one of the "natural" applications for functional programming languages.

[pjmlp]

There are plenty of compilers written in memory safe languages, including the list of self hosted ones linked from the gist describing the rewrite.

[Muromec]

>but the compiler needs to do memory-unsafe things

sorry, but why?

[mrkeen]

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.

[isaacvando]

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

[vitiral]

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

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