bhansconnect

5 ms·

1.
by bhansconnect 2y ago
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 don
2.
by bhansconnect 2y ago
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.
3.
by bhansconnect 2y ago
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
4.
by bhansconnect 2y ago
Yeah, the rewrite will clean up a ton of technical debt for us. So it will very much be a bad comparison.
5.
by bhansconnect 2y ago
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
6.
by bhansconnect 2y ago
https://www.roc-lang.org/faq.html#self-hosted-compiler
7.
by bhansconnect 2y ago
https://www.roc-lang.org/faq.html#self-hosted-compiler
8.
by bhansconnect 2y ago
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
9.
by bhansconnect 2y ago
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 track
10.
by bhansconnect 2y ago
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
11.
by bhansconnect 2y ago
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 the code author has t
12.
by bhansconnect 2y ago
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.
13.
by bhansconnect 2y ago
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. Right now writi
14.
by bhansconnect 3y ago
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 less equivalent.
15.
by bhansconnect 3y ago
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 akin to monads and
16.
by bhansconnect 3y ago
0. Roc is capable of always inferring types. So type annotations are never required. That said, type annotations are used commonly and 100% supported.
17.
by bhansconnect 3y ago
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 arbitrary c library. Tho
18.
by bhansconnect 3y ago
> it's actively rude within three error messages. Can you share those error messages? I am sure that is not the intent.
19.
by bhansconnect 3y ago
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 syntaxes that aren&#x27
20.
by bhansconnect 3y ago
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 could expose an