Hacker News: bhansconnect

New comment by bhansconnect in "Roc rewrites the compiler in Zig"

bhansconnect — Tue, 04 Feb 2025 23:00:07 +0000

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.

New comment by bhansconnect in "Roc rewrites the compiler in Zig"

bhansconnect — Tue, 04 Feb 2025 22:57:18 +0000

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.

New comment by bhansconnect in "Roc rewrites the compiler in Zig"

bhansconnect — Tue, 04 Feb 2025 22:55:13 +0000

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.

New comment by bhansconnect in "Roc rewrites the compiler in Zig"

bhansconnect — Tue, 04 Feb 2025 22:53:05 +0000

Yeah, the rewrite will clean up a ton of technical debt for us. So it will very much be a bad comparison.

New comment by bhansconnect in "Roc rewrites the compiler in Zig"

bhansconnect — Tue, 04 Feb 2025 22:49:13 +0000

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)

New comment by bhansconnect in "Roc rewrites the compiler in Zig"

bhansconnect — Tue, 04 Feb 2025 22:45:25 +0000

https://www.roc-lang.org/faq.html#self-hosted-compiler

New comment by bhansconnect in "Roc rewrites the compiler in Zig"

bhansconnect — Tue, 04 Feb 2025 22:43:38 +0000

https://www.roc-lang.org/faq.html#self-hosted-compiler

New comment by bhansconnect in "Roc rewrites the compiler in Zig"

bhansconnect — Tue, 04 Feb 2025 22:39:26 +0000

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.

New comment by bhansconnect in "Roc rewrites the compiler in Zig"

bhansconnect — Tue, 04 Feb 2025 22:37:45 +0000

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.

New comment by bhansconnect in "Roc rewrites the compiler in Zig"

bhansconnect — Tue, 04 Feb 2025 22:34:35 +0000

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.

New comment by bhansconnect in "Roc Lang – Elm but for everywhere [video]"

bhansconnect — Wed, 21 Aug 2024 00:22:32 +0000

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 to fundamentally deal with correctly specifying what the return type is. Technically a fancier query builder could be defined that removes the sql and instead defines both the query and return type at once to avoid the double specification.

Otherwise, something like squirrel would 100% be doable in roc. [Something similar](https://github.com/isaacvando/rtl) already exists for templating in roc via code gen.

New comment by bhansconnect in "Roc Lang – Elm but for everywhere [video]"

bhansconnect — Tue, 20 Aug 2024 23:48:10 +0000

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.

New comment by bhansconnect in "Roc Lang – Elm but for everywhere [video]"

bhansconnect — Tue, 20 Aug 2024 23:46:14 +0000

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 writing a platform is a much harder process than it will be in the future. Until a certain chain of features land, I expect this to stay as bespoke knowledge that is obtain through modifying examples and asking questions on zulip.

New comment by bhansconnect in "A look at the Mojo language for bioinformatics"

bhansconnect — Mon, 12 Feb 2024 22:10:56 +0000

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.

New comment by bhansconnect in "Roc – A fast, friendly, functional language"

bhansconnect — Sat, 25 Nov 2023 04:50:23 +0000

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

New comment by bhansconnect in "Roc – A fast, friendly, functional language"

bhansconnect — Fri, 24 Nov 2023 19:23:11 +0000

0. Roc is capable of always inferring types. So type annotations are never required. That said, type annotations are used commonly and 100% supported.

New comment by bhansconnect in "Roc – A fast, friendly, functional language"

bhansconnect — Fri, 24 Nov 2023 19:21:37 +0000

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. Those primitives must always come through the platform.

https://www.roc-lang.org/platforms

New comment by bhansconnect in "Roc – A fast, friendly, functional language"

bhansconnect — Fri, 24 Nov 2023 19:19:41 +0000

> it's actively rude within three error messages.

Can you share those error messages? I am sure that is not the intent.

New comment by bhansconnect in "Roc – A fast, friendly, functional language"

bhansconnect — Fri, 24 Nov 2023 19:18:43 +0000

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't as common in procedural or OO languages.

New comment by bhansconnect in "Roc – A fast, friendly, functional language"

bhansconnect — Fri, 24 Nov 2023 19:16:25 +0000

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 append function that has the same interfaces as `List.append`, so that could easily lead to confusion.