thomask1995

I think this would be killer for OSS maintainers.

Hey! Saw you starred our repo. Appreciate it :)

Here are some of our differentiators:

- built with running in sandboxes to give users more flexible CPU and memory settings per DO

- declarative SDKs in Typescript/Python

- generated type-safe clients (no outer worker needed)

- built in debugging UI

- durability guarantee is using GCS rapid or other cloud technology for fast writes without having to manage a fleet

Happy to go more in detail as well!

For me it was the decorator syntax + opting into "dangerous" things.

I love the idea of tossing a decorator and modifying the durability guarantees.

Also, swift @sendable is really sweet, also want to add that in and flag when state data is about to leave the actor.

Actors really were a life saver at Apple. Agents are like what threads were to us on iOS

I'm always keen to learn more!

Do you have a reproducible set up I can try out to see this latency? We would love to offer an option to have 1ms writes

Hey! durable writes for celld (single node, wait for bucket) is 90ms. Documented pretty clearly on the landing page.

Celld is pretty cool in that you can configure a small fleet in the same VPS and get super fast durable writes (with a weaker guarantee). We are also going to allow you to tweak the durability guarantees so you can manage that trade off yourself!

Hey! Yea we are a very different API from them. Closer to Cloudflare for sure.

Our biggest differentiator is the configurable compute. With our helm chart, you just add a decorator and can specify how much RAM, CPU etc... an actor class has.

We are pretty opinionated on how to host these. The helm chart gets you a fully horizontally scalable deployment.

Olivier's comment seems to have been suppressed. Not sure why. reposting

thanks for the question verst. durable actors manages durable state, not durable execution. Azure Durable functions, temporal, aws lamda durable functions are for managing execution. each actor has its own sqlite DB and runs on one host at a time. Clients call it via RPC or Websocket message, changing state and actor pushes state changes back to every client. product is more similar to cf durable objects or orleans.

i took a look at durable entities, state model is similar but they don't support websocket handling.

This is a great comment! We actually get this a lot.

Since we are so early, we can build this the right way. I agree, I think we need something you can set up to sync to a data lake. I started really simple with exporting at certain times, but I think there is more to do here.

I really want to nail this part of the experience. I agree, it is a big sticking point

Hey! so celld is a direct port of Durable Objects.

We are actually a different API. I come from writing swift for 7 years (I was at apple) and really thought they nailed the actor model so modeled ours similarly.

Also, we make it really easy to configure each actors compute with just a decorator. So if you want to do something beefy like store file directory in an actor you can increase the memory to 4GB and you are good to go!

Happy to go into more detail here as well!

Yes! would love to know what you think.

Want to make this the best product possible

I think there could be some cool generative UI stuff to build with it.

Based on certain actions, choose a set of components to render. Want to give that a go once I get a chance.

Shame, it was probably the best designed No-Code workflow builder out there

Very cool project!

I think some sort of gui to help write the cors headers would help tbh.

it's quite difficult to get your stack to work for local dev, CI, and prod since each most likely needs different cors headers. Especially if you use tunnels and proxies like we do.

What made it click for me though was understanding what problem it solved.

Def this right now

https://impeccable.style/

This is the app I was begging for a few years ago!

Ended up buying a ton of Ear Training books and using those little web apps.

This would have been so much better.

I just started using it,

I will say, I feel we can skip the chords annotations and stuff if the ICP is intermediate guitarist.

Or do a quick survey at the start and see what fundamentals they know.

For intermediate guitar, I think the main gaps are:

- Ear training (unless they were taught early) - triads + inversions - Music theory beyond basic pentatonic shapes - Synchronization at higher speeds (this was my biggest one by far) - Chords beyond basic ones and M/m 7th.

I feel you could add little quiz or survery to see if they are already familiar with some of these.

just my 2 cents

Overall, love this. Very happy someone took the time to do it.

This is super cool!

Have you thought about making a tool to help preview/dry run migrations?

I feel that's something I would want a ton of confidence in if an LLM is making migration scripts.

Especially if it's doing scary stuff like breaking up a table.

Very cool! Would be sweet to add number of usages each tool gets.

Interested in seeing what other people use!

HI! OG Author here.

Honestly, I don't know.

This was purely a toy project/thought experiment to challenge myself to learn exactly how these LLMs worked.

It was super cool to see the loss go down and it actually "train".

This is SUPER far from a the real deal. Maybe it could be cool to see how far a fully in memory LLM running on CPU can go.

License added! Good catch

I wanted to learn exactly how these things work. Down to every detail.

So I built a Mini LLM from absolute scratch in Rust. No libraries other than ndarray and rand.

Started a few months ago but got stuck. Used claud code and fixed the remaining issues and now it works!