Roc never plans to self host. We want roc the compiler in the long term to be as nice as possible for end users. A big part of that is as fast as possible. While roc can be fast, it can't compete with all the techniques…
It sadly helps a lot less than you would hope. A true dev backend can be many times faster than llvm to compile code. Crane lift is more like a 1.5x or 2x. Not to mention a lot of time is spent in the rust frontend.
Yeah, the compiler was started in 2019 when zig wasn't nearly as viable of an option. On top of that, you don't necessarily know what you want until you build something. I'm part of the core team, and I'm honestly still…
Yeah, the rewrite will clean up a ton of technical debt for us. So it will very much be a bad comparison.
Thank you for your work! Rust is still a great language. I think a significant portion of our pain with rust compile times is self inflicted due to the natural growth of our crate organization and stages. I still think…
https://www.roc-lang.org/faq.html#self-hosted-compiler
For sure, but we have a really good relationship with the zig folks and they are willing to help us out. On top of that, zig has gotten a lot more robust and stable of the last few releases. Upgrading is getting…
This is more about simplicity, maintainability, and possiblity for new contributors to easily jump in and fix things. Our current parser is not fun for new contributors to learn. Also, I think parser combinators…
Zig was not ready or nearly as popular back in 2019 when the compiler was started. Not to mention, Richard has a background mostly doing higher level programming. So jumping all the way to something like C or Zig would…
As a general note, the code there is an initial more exploratory api. It definitely could be simplified (solid bits of extra noise in it). That said, it does have the fundamental issue of the query is just a string and…
It isn't "no escape hatch". It is platform dependent escape hatches. A platform can give you full access to mutation and libffi if it wants.
There are some major changes to platform development that are coming (both flexibility and usability). Sadly, they have been slow to introduce. I think that is a large part of the reason the documentation doesn't exist.…
This is not accurate. The blog post used `--release` for it's Rust numbers. The confusion comes from the 50% performance win being specific to running on an M2 mac. On an x86_64 Linux machine, the results are more or…
Roc doesn't allow side effects. All effects are wrapped and returned from a function. So this is just as pure as haskell. Though it may not be exposed in the same way as haskell, effects still boil down to something…
0. Roc is capable of always inferring types. So type annotations are never required. That said, type annotations are used commonly and 100% supported.
Yes and No. Roc fundamentally is built on top of platforms. Platforms are communicated with through cffi. So cffi is fundamental to roc. At the same time, roc will never have general cffi where a package can wrap an…
> it's actively rude within three error messages. Can you share those error messages? I am sure that is not the intent.
Can you clarify what you mean? I don't think Roc actually has that many keywords or operators in total. I would bet that C has more keywords that Roc. I do agree that default convention may rely heavily on a few…
Roc cares a lot about explicitness, so I don't think this would be a wanted feature. That said, it is easy to get this functionality with something like ``` append = List.append ``` An important note is that any module…
Roc never plans to self host. We want roc the compiler in the long term to be as nice as possible for end users. A big part of that is as fast as possible. While roc can be fast, it can't compete with all the techniques…
It sadly helps a lot less than you would hope. A true dev backend can be many times faster than llvm to compile code. Crane lift is more like a 1.5x or 2x. Not to mention a lot of time is spent in the rust frontend.
Yeah, the compiler was started in 2019 when zig wasn't nearly as viable of an option. On top of that, you don't necessarily know what you want until you build something. I'm part of the core team, and I'm honestly still…
Yeah, the rewrite will clean up a ton of technical debt for us. So it will very much be a bad comparison.
Thank you for your work! Rust is still a great language. I think a significant portion of our pain with rust compile times is self inflicted due to the natural growth of our crate organization and stages. I still think…
https://www.roc-lang.org/faq.html#self-hosted-compiler
https://www.roc-lang.org/faq.html#self-hosted-compiler
For sure, but we have a really good relationship with the zig folks and they are willing to help us out. On top of that, zig has gotten a lot more robust and stable of the last few releases. Upgrading is getting…
This is more about simplicity, maintainability, and possiblity for new contributors to easily jump in and fix things. Our current parser is not fun for new contributors to learn. Also, I think parser combinators…
Zig was not ready or nearly as popular back in 2019 when the compiler was started. Not to mention, Richard has a background mostly doing higher level programming. So jumping all the way to something like C or Zig would…
As a general note, the code there is an initial more exploratory api. It definitely could be simplified (solid bits of extra noise in it). That said, it does have the fundamental issue of the query is just a string and…
It isn't "no escape hatch". It is platform dependent escape hatches. A platform can give you full access to mutation and libffi if it wants.
There are some major changes to platform development that are coming (both flexibility and usability). Sadly, they have been slow to introduce. I think that is a large part of the reason the documentation doesn't exist.…
This is not accurate. The blog post used `--release` for it's Rust numbers. The confusion comes from the 50% performance win being specific to running on an M2 mac. On an x86_64 Linux machine, the results are more or…
Roc doesn't allow side effects. All effects are wrapped and returned from a function. So this is just as pure as haskell. Though it may not be exposed in the same way as haskell, effects still boil down to something…
0. Roc is capable of always inferring types. So type annotations are never required. That said, type annotations are used commonly and 100% supported.
Yes and No. Roc fundamentally is built on top of platforms. Platforms are communicated with through cffi. So cffi is fundamental to roc. At the same time, roc will never have general cffi where a package can wrap an…
> it's actively rude within three error messages. Can you share those error messages? I am sure that is not the intent.
Can you clarify what you mean? I don't think Roc actually has that many keywords or operators in total. I would bet that C has more keywords that Roc. I do agree that default convention may rely heavily on a few…
Roc cares a lot about explicitness, so I don't think this would be a wanted feature. That said, it is easy to get this functionality with something like ``` append = List.append ``` An important note is that any module…