Hacker Newsnew | past | comments | ask | show | jobs | submit | bhansconnect's commentslogin

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 that can be done in rust/zig/c/c++. It fundamentally is a higher level language to increase developer joy and reduce bugs. So it isn't the right tool when you are trying to reach the limits of hardware like this.


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 a bit surprised we're switching to zig. I think it makes sense, it just kinda finally aligned and was decided now. I guess enough technical debt piled up and the core of the language was clearly discovered. So we really know what we want now.


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 the rewrite in zig is the right choice for us for various reasons, but I think at least a chunk of our compile times issues are self inflicted (though this happens to any software project that grows organically and is 300k LOC)




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 smoother.

But yeah, it is a risk.


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 obsficate a lot of the tracking required for robust error messages.

Personally, I find parser combinators nice for small things but painful for large and robust things.


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 have been a very big step.

Sometimes you need a stepping stone to learn and figure out what you really want.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: