News for hackers. Stuff that matters.
Re:The Claro Programming Language by saghm on Thursday February 29, 2024 @02:07AM (#39547045)
From glancing over their guide, it seems like it achieves this by essentially requiring you to manually specify a state machine that it can verify won't cycle by composing together "graph functions" that return futures (which are not allowed to block on the results of any futures directly or transitively). If I understand correctly, combining this with only allowing immutable data to be shared (like you described) makes it possible to parallelize graph function calls when that don't depend on each others results.
Re:The Claro Programming Language by rakoo on Thursday February 29, 2024 @03:12AM (#39547364)
From their doc, immutability is used for avoiding data races. Deadlocks are avoided by only starting a procedure when all dependencies are ready.
Re:The Claro Programming Language by saghm on Thursday February 29, 2024 @11:50AM (#39551857)
Yeah, I didn't mean to imply that immutability was needed for avoiding deadlocks; I just thought it was interesting that it "composes" with their deadlock avoidance to provide the follow-up "optimally scheduled" and "scalable by default" features.
Re:The Claro Programming Language by kaba0 on Thursday February 29, 2024 @02:13AM (#39547075)
Well, that’s true. Though then it is pretty similar to the “build tool” problem, which is actually an interesting parallel :D Nonetheless, I do think that big limitations at most places, with optional, explicit escape hatches is a good pattern.
Re:The Claro Programming Language by jasonsteving on Friday March 01, 2024 @02:37AM (#39559514)
Definitely a clear similarity to the problems that incremental build tools (i.e. Bazel) are solving! At the moment, Claro doesn't allow any "escape hatches" but the logic there has really been to start with a strong/safe foundation, and then afterwards evaluate whether escape hatches are necessary, and if so what they should look like.

At the moment, with specific regard to Claro's concurrency story, I'd say it's unlikely that there will be any escape hatches for writing obviously thread-unsafe code whatsoever explicitly available to user code.

It's worth taking a look at this section of the docs to see Claro's current stance on the StdLib itself being given the unique right to "bless" certain mutable data structures to be shared between threads after they've been explicitly verified to be thread-safe. https://docs.clarolang.com/guaranteed_data_race_free/guarant...

Re:The Claro Programming Language by jasonsteving on Friday March 01, 2024 @02:30AM (#39559473)
This is basically spot on. I'm glad you were able to come away with that understanding from your initial read of the docs.