elijahbenizzy

Strands is more opinionated and higher-level, also not vendor neutral.

wait till you see our other project github.com/apache/hamilton ;)

So decorators here specifically attach metadata to make a function a reusable component. Builder makes a workflow. In Hamilton it's all decorators because it's purely declarative construction (sans reusability, really).

Right it was a bit of a joke. Originally stefan and I presented frameworks when we were at stitch fix -- stefan called his "hamilton" and I called mine "burr". His was better for the use-case. But then we wanted to build something for state machines as opposed to DAGs, so we called it Burr. I wanted the git tagline to be "make your agents go burr..."

Ha! We went all out on the modern one (user contribution!).

This is where it's nice to have some guardrails -- coding agents work etremely well with limitations.

Right I think this is why we made it unopinioated to a fault. Burr doesn't really do these things rather it just provides an orchestration framework. So it's pure BYO functions, classes, components, etc...

Right -- possible it's slightly out of date https://github.com/apache/burr#-comparison-against-common-fr.... Good point on differentiating.

One of the co-creators/maintainers here! Will try to answer Qs over the day.

And then says... "you're welcome"

Ok do this but for JavaScript

This is amazing! I love that it requires very fancy hardware that is well designed. It's good someone finally made a chess game appropriate for the tiktok generation.

Really excited about this! Congrats on the launch. Ships make sense as a first target, but I'm curious -- do you see a future in which we have household fission reactors? E.G. power an entire house (city block, etc...) with fission reactors?

We’ve just learned that it’s possible to do AI on less compute (deepseek). if OpenAI doesn’t scale and that’s the problem then I’d argue that in the long run, if you believe in their ability to do research, then the news this week is a very bullish sign.

IMO the equivalent of moores law for AI (both on software and hardware development) is baked into the price, which doesn’t make the valuation all too crazy.

This is one of those fun reads because it unifies quite a few things that I’ve read about or been interested in recently — Hilbert curves for geospatial indexing in dbs, Gray codes, and fractals! And it’s all fairly intuitive — the 1-bit shift makes sense for space traversal and makes the numbers curve pattern easier to reason about.

Not believable, didn't read "double click"

We've leveraged Diataxis heavily for Hamilton and Burr documentation:

- https://hamilton.dagworks.io

- https://burr.dagworks.io

It's not always the easiest to follow (we often have disagreements about whether something is a tutorial or a how-to), but it's a really valuable framing and I think our docs have gotten better because of it.

Links to various resources + writeups!

Recursion/parallelism: - Docs: https://burr.dagworks.io/pull/370/concepts/parallelism/

- Example: https://github.com/DAGWorks-Inc/burr/tree/main/examples/para...

UI annotations: - Blog post: https://blog.dagworks.io/p/annotating-data-in-burr

OpenTelemetry: - Docs: https://burr.dagworks.io/reference/integrations/opentelemetr...

- Blog post: https://blog.dagworks.io/p/trace-all-parts-of-your-agenticai

Time-travel/forking: - Docs: https://burr.dagworks.io/concepts/state-persistence/#initial...

- Blog post: https://blog.dagworks.io/p/travel-back-in-time-with-burr

Monitoring: - Deployment: https://github.com/DAGWorks-Inc/burr/tree/main/burr/tracking...

- UI overview: https://blog.dagworks.io/p/burr-ui

And a few other writeups we're excited about: - Collaboration with instructor: https://python.useinstructor.com/blog/2024/07/11/youtube-tra...

- Full-stack example of a streaming app: https://towardsdatascience.com/how-to-build-a-streaming-agen...

- Human-in-the-loop app with Burr: https://towardsdatascience.com/building-an-email-assistant-a...

Heh, this was very much the design philosophy behind Hamilton (github.com/dagworks-inc/hamilton).

The basic idea was that if you have a data artifact (columns for dataframes initially), you should be able to ctrl-f and find it in your codebase. 1:1 mapping of data -> function.

People take a long time to figure out that the readability gains from having greppability is worth whatever verbosity that comes, largely because they think of code too much as a craft (make it as small/neat as possible) and not documentation for a live process...

Graph-based libraries for building ML/AI systems:

- Burr -- build AI applications/agents as state machines https://github.com/dagworks-inc/burr

- Hamilton -- build dataflows as DAGs: https://github.com/dagworks-inc/hamilton

Looking for feedback -- we had some good initial traction on HN, and are looking for OS users/contributors/people who are building complimentary tooling!

I love CRDTs, but it really seems like the type of thing where the idea of them is the real impact (many systems are built with structures that enable CRDT-like operations without actually using CRDTs), and the implementations never quite hit product market fit.

The venn diagram of "problems that people have" and "problems that postgres solves" is closer to a circle than many would like to admit.

This is absolutely delightful. Perhaps my favorite line:

"Without it no websites, no Roblox studio, and no nothin."

One of the hardest parts of training models is avoiding overfitting, so "more parameters are better" should be more like "more parameters are better given you're using those parameters in the right way, which can get hard and complicated".

Also LLMs just straight up do overfit, which makes them function as a database, but a really bad one. So while more parameters might just be better, that feels like a cop-out to the real problem. TBD what scaling issues we hit in the future.

Interesting. I don't disagree, in general, but I actually have worked with a lot of applications that like to do this. Specifically in the world of ML/AI inference there's a lot of moving between external querying of data (features) and internal/external querying of models. With recommendation systems it is often worse -- gather large data, run a computation on it, filter it, get a bulk API request, score it with a model, etc...

This is exactly where I'd like to see it.

I'd like to simultaneously:

1. Call out to external APIs and not run any overhead/complexity of creating/managing threads 2. Call out to a model on a CPU and not have it block the event loop (I want it to launch a new thread and have that be similar to me) 3. Call out to a model on a GPU, ditto

And use the observed resource CPU/GPU usage to scale up nicely with an external horizontal scaling system.

So it might be that the async API is a lot easier to use/ergonomic then threads. I'd be happy to handle thread-safety (say, annotating routines), but as you pointed out, there are underlying framework assumptions that make this complicated.

The solution we always used is to separate out the CPU-bound components from the IO-bound components, even onto different servers or sidecar processes (which, effectively, turn CPU-bound into IO-bound operations). But if they could co-exist happily, I'd be very excited. Especially if they could use a similar API as async does.

There are a whole bunch of assumptions here. But sure, if you view the world as a closed system, then you have a decision as a function of inputs:

1. The world around you 2. The experiences within your (really, the past view of the world around you) 3. Innateness of you (sure, this could be 2 but I think it's also something else) 4. The experience you find + the way you change yourself to impact (1), (2), and (3)

If you think of intelligence as all of these, then you're making the assumption that all that's required for (2), (3), and (4) is "agentic systems", which I think skips a few steps (as the author of an agent framework myself...). All this is to say that "what makes intelligence" is largely unsolved, and nobody really knows, because we actually don't understand this ourselves.

This is humorous (and well-written), but I think its more than that.

I'm always making the joke (observation) that ML (AI) is just curve-fitting. Whether "just curve-fitting" is enough to produce something "intelligent" is, IMO, currently unanswered, largely due to differing viewpoints on the meaning of "intelligent".

In this case they're demonstrating some very clean, easy-to-understand curve-fitting, but it's really the same process -- come up with a target, optimize over a loss function, and hope that it generalizes, (this one, obviously, does not. But the elephant is cute.)

This raises the question Neumann was asking -- why have so many parameters? Ironically (or maybe just interestingly), we've done a lot with a ton of parameters recently, answering it with "well, with a lot of parameters you can do cool things".

I'm really curious to see how this will work with async. There's a natural barrier (I/O versus CPU-bound code), which isn't always a perfect distinction.

I'd love to see a more fluid model between the two -- E.G. if I'm doing a "gather" on CPU-bound coroutines, I'm curious if there's something that can be smart enough to JIT between async and multithreaded implementations.

"Oh, the first few tasks were entirely CPU-bound? Cool, let's launch another thread. Oh, the first few threads were I/O-bound? Cool, let's use in-thread coroutines".

Probably not feasible for a myriad of reasons, but even a more fluid programming model could be really cool (similar interfaces with a quick swap between?).

The title display is very clever but I really wonder if it would have as much of a punch if they displayed that one extra line on the "m"

Hey folks! Wrote a post on using Hamilton's async integration to build lightweight, scalable, and self-documenting LLM pipelines in python. Would love feedback/interest!