jasonsteving

You nailed an interesting nuance there about agents needing to make their own decisions!

I'm getting fairly excited about "agentic" solutions to the point that I even went out of my way to build "AgentOfCode" (https://github.com/JasonSteving99/agent-of-code) to automate solving Advent of Code puzzles by iteratively debugging executions of generated unit tests (intentionally not competing on the global leaderboard).

And even for this, there's actually only a SINGLE place in the whole "agent" where the models themselves actually make a "decision" on what step to take next, and that's simply deciding whether to refactor the generated unit tests or the generated solution based on the given error message from a prior failure.

Check out https://app.gov-notes.com/ - dig into US congressional committee hearing videos (for free)

It's interesting to hear about the twists and turns that got you here, thanks for sharing.

I happen to have built something in the same vein in a few months earlier this summer for the Gemini API developer competition.

For anyone interested, check out Gov Notes (https://app.gov-notes.com)

The site lets you dig into US house committee hearing videos posted to YouTube using AI search and chat. Even have some fairly powerful grounding in the chat - you can ask followups like "when was that discussed in the video?" and the chat will reply with a clickable link to a specific timestamp in the video where your current topic was discussed.

Thank you for the kind feedback!

Great question! This is actually something that will take more work to pull off "right" - but it's definitely planned.

For now, Java code can call into Claro code in a fairly straightforward way. The main hurdles are:

- the namespacing/naming of the Claro code you're calling into is funky because Claro doesn't use Java's "package" namespacing system

- manually constructing non-primitive data to pass to Claro procedures is currently very annoying and, more importantly, unsafe (you could break Claro's type system rules)

In the other direction, Claro's only (current) mechanism for calling into Java directly is restricted to the stdlib's implementation. For example the deque Module[1] exports an `opaque newtype mut Deque<E>` that is actually just a `java.util.ArrayDeque<E>` underneath[2]. The reason this isn't exposed to Claro programs outside the stdlib (yet) is because:

- the type systems are very dissimilar and would need mapping

- Claro doesn't use Exceptions, so you'd have to ensure that any calls into Java code that can throw manually catches and models an error return value[3]

All this said, it's very possible that in the future these limitations can be addressed!

[1] https://docs.clarolang.com/stdlib/deque_module.generated_doc...

[2] https://github.com/JasonSteving99/claro-lang/blob/b5e33ae4ef...

[3] https://github.com/JasonSteving99/claro-lang/blob/b5e33ae4ef...

I just want to echo your point that even though any individual new language is very unlikely to ever see significant use, I would still find deep satisfaction in some of the valuable ideas contained within finding their place in a more mainstream language :).

So, I understand why it seems like that Java signature you gave would work, but it in fact does not work. Check out this replit example to see the full example with your signature: https://replit.com/@JasonSteving1/DemoTypeSystemLimitation#s...

This section[1] gives a much deeper dive into how I'm thinking about this.

[1] https://docs.clarolang.com/generics/contracts/dynamic_dispat...

I'm glad you've found Claro interesting so far!

I can understand where you're coming from with the split between API and impl. It's certainly something I'm keeping on my radar. Personally I care more about readability than writability so it's not a big issue for me, but I can understand that others would land differently on this point.

One reason that I'm holding out on this (for now) is that I'm actually excited about how this one decision makes it quite easy to express some quite complex patterns using "Build Time Metaprogramming": https://docs.clarolang.com/metaprogramming/code_reuse/reusin....

The whole section is really more of an exploration than it is any sort of strong statement that this is what all Claro code should look like. But it's all fundamentally enabled by this "physical" separation between API and impl.

Thanks, this is exactly how I'm thinking about this! And actually, beyond just having a certain "innovation budget" (which is true) I also just personally want a language that's aggressively simple (a subjective measure). I'm trying hard to make something that will fit in my head in the end.

Hey! I wrote Claro so I can speak to this :). There are certainly some constraints to get these properties.

To eliminate deadlocking, Claro tracks any explicit "blocking" on the completion of a future<T> and requires the containing procedure (and any dependents) to be explicitly annotated as "blocking", and then these blocking procedures aren't allowed to be called within a Graph procedure OR be scheduled on the Executor directly in the form of a lambda for example.

Data races are prevented by simply making it impossible for two threads to share a reference to mutable data. The most obvious consequence here is that mutable data can't be passed into a Graph Procedure, and none of its internal nodes can evaluate to a mutable data type. Less obvious is that lambdas cannot "capture" mutable data. If they were allowed to capture mutable data, then they would effectively become stateful "objects" themselves in a way that the type system doesn't track (a `function<int -> int>` has the same signature regardless of what it captures) so this would effectively be a backdoor to allowing mutable data to leak between threads.

More details here: https://docs.clarolang.com/fearless_concurrency/fearless_con...

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

This is basically spot on. I'm glad you were able to come away with that understanding from your initial read of the docs.

Thanks for your interest in this! Claro's Graph Procedures are certainly something I'm very proud of. I think they provide a powerful concurrency abstraction that limit the spread of concurrency-related complexity in a way that I find very enjoyable to work with.

Hi everyone, I'm the creator of Claro. Thank you for taking the time to take a look into the language! It's been very satisfying and encouraging seeing so many largely positive reactions, it's been a 3 year labor of love (and learning) so I appreciate the feedback.

I'll do my best to finally respond to as many comments here that I can get to.