Hi folks! @Chris Krycho’s message above reminds me that I've actually just been a lurker here for the past several weeks and haven't actually introduced myself yet! Lol I'm an Ex-Googler/Ex-Amazonian that left work this past February to spend a year full time committing to my passion project, the Claro programming language! I'm ~3 years into development on the language, and in 2023 things have really accelerated and the language is at a place I'm very proud of (although it still is lacking in the way of documentation). If you're interested in checking out an early stage language with some very novel ideas about provably safe/efficient concurrency and a powerful module system and a sprinkling of compile-time "meta-programming" magic, take a look! I'll be working through Advent of Code in Claro this year, so if you'd like a taste of what that looks like: I'll be dumping my solutions here.

That language looks excellent

Trying to grasp the concepts, which languages would you say Clari is related or inspired from? Rust? Elm, Kotlin, Scala, Haskell, etc. What makes Claro "Claro"? I see talk about concurrency, so maybe a comparison to Go and Erlang/Elixr would help?

Cool. Graph procedures seem like a great idea. I don't know how important avoiding deadlocks is most of the time, but this seems like an easier approach than, say, modelling your hand-made concurrency system in TLA+, or something. I did find the keyword "root" unintuitive. Is the order of the nodes in the graph procedures semantically meaningless?

Oops turns out I wasn't logged into this slack group on my phone so missed these replies. But thank you all for taking an interest! @Mike Austin Claro takes a fair bit of inspiration from Rust, largely in the form of the aim of "fearless concurrency", monomorphized generics, their Traits system (which is tweaked to my preferences in the form of "Contracts"), error handling, and pattern matching support (WIP). But I also have taken some inspiration from Python's simplicity goals, as well as some specific features like lists/set/map comprehensions. Claro's concurrency story is probably closer to Go than Erlang/Elixir as this is not a message passing/actors world. However, unlike Go, the goal really is strictly proving by construction that your concurrent code will be performant and correct - you simply declare your DAG of concurrent operations as a Graph Procedure and Claro generates the optimally scheduled async execution. This idea is explicitly an extension of Google's internal "Java Producers Framework" that was used to run all Java backend services for a decade+ (that framework is partially available as Dagger Producers but keep in mind this comes with none of Claro's compile-time correctness guarantees). @Jason Morris thanks! I'm glad Graph Procedures seem interesting/useful to you! I can resonate with your feeling that

root

is unintuitive. This is something that'll need workshopping to find ways to make it more clear so your feedback is really valuable to me. The textual ordering of `node`s in a Graph does not matter at all. Claro will simply schedule based on the actual dependency graph encoded. However, I've constrained the

root

node such that it must come either first or last. The best-practice organization is that nodes should be ordered in a topological sort (so that all data conceptually "flows" in one direction) but I think it's up to the user to decide whether it makes more sense to them for data to flow "up" or to flow "down". Ideally, I'd have some auto-formatter that could be configured to just reorder node definitions to align consistently with your preferred dataflow direction. Does that make sense?

Makes sense, yes. But I would be inclined to look at the semantic meaninglessness of order as a strength. Forcing the ultimate node to be first or last might needlessly prevent some interesting things you could do with whitespace to make it look like a tree with the root in the centre, for a certain category of graph where that would work.

That's a very interesting point, it's possible that I'm overstepping the types of decisions the language should impose on users. I may have my own personal style preference but perhaps there's value in leaving users free to choose. I leaned towards what I've done because in my experience using the Java Producers Framework at Google, the biggest things that people new to this declarative dataflow model complained about was being confused about the inversion of control flow. Standardizing the order that nodes were declared helped those people feel less lost and disorganized

That's fair. I come from a logic programming background, where the fact that there is any semantic meaning to order in a conjunction is a source of confusion. So my biases are in the other direction, and a minority view.

That's actually super interesting that the perspective could be so influenced by the languages you've previously used. It's very encouraging to me that you and people with a similar background are proof that there's nothing inherently confusing about this inverted model. I'll say that it took me some adapting, but once I was steeped in this way of thinking I'd hate the prospect of needing to explicitly order concurrent operations to maximize parallelism