11 ms·
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 n
by isaacvando 2y ago
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 https://youtu.be/42TUAKhzlRI?feature=shared.
- Muromec 2y ago>but the compiler needs to do memory-unsafe things sorry, but why?
- isaacvando 2y agoI believe the main reason is for achieving the best possible performance. Someone closer to the compiler could give more detail.
- vitiral 2y agoIt's not just the lang but the std lib too https://www.roc-lang.org/faq#rust-and-zig https://www.roc-lang.org/faq#rust-and-zig
- mrkeen 2y agoI 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.
- int_19h 2y agoIt still feels kinda weird. Parsers, compilers etc are traditionally considered one of the "natural" applications for functional programming languages.
- pjmlp 2y agoThere are plenty of compilers written in memory safe languages, including the list of self hosted ones linked from the gist describing the rewrite.