Marc MacLeod

Finally. It's time. A decade after starting my first company (wow time flies), I'm working on something new! The new company is Datanaut, and while it's too early to share specifics, I'm excited to work with @scottfaust43 and our small team to re-imagine how we as humans interface with AI, each other, and the treasure trove of data that is fragmented across the apps we use every day. I'm not much of a sharer, but this go-around I'm committed to building more in public. Expect to see regular posts from me on things like ui / ux design, agentic patterns, running a lean company, and more in the weeds technical stuff - basically a log of the real-world challenges that we're faced with every day as we build Datanaut. I can't wait to share more. Most importantly, I can't wait to start shipping again 🚀.

the more claude code types for me the worse i get at typing myself

Messing around with formal Job abstraction w @EffectTS_ and @Cloudflare. Define a job like you define state - `Job.Tag`, implement a handler, then schedule from any actor. Works in memory (for tests) or on CF. Builds on x.com/marbemac/statu… -

@MichaelArnaldi @EffectTS_ hmm crazy, just because it's looking at .ts source in node_modules/effect instead of .ts source in repo cloned somewhere on disk? tbf we JUST made this change to try using node modules instead of on disk clone, so it's fresh - will def monitor to see how it does

@marbemac @EffectTS_ yes output is about 20% worst requiring more tool calls

love that @EffectTS_ ships the ts source with the npm distribution - more libraries should do this. really helps llm's out.. don't need to clone the repo and point them at it if they can just look in node_modules

ah true on the tests, maybe those could be shipped too :). yes increases size on disk but meh, might be worthwhile tradeoff. re de-optimising the model, have you found any degradation if you encourage llm to search source in node modules for specific libs? In our agents file I just instruct it to use node modules for a few key libs we use like effect, that do indeed ship source. It doesn't seem to get confused and try to use node modules for other libs that aren't mentioned. (this is w opus, haven't tried other models)

@marbemac @EffectTS_ models are trained not to look at node_modules, by relying on node modules you're basically deoptimising the model, and also you don't get access to useful context such as tests

Been working on an @EffectTS_ lib to smooth over the experience working with actor patterns, with a specific focus on making it trivial to swap out backing implementation between @Cloudflare durable objects and node/bun/memory. Lot more to it than this, but it's coming along nicely!

Very excited about the @EffectTS_ v4 beta! Haven't seen much mentioned about this and curious if there's any guidance on what to expect wrt tsc type check perf, and stack traces / debuggability dx. Similar characteristics between v3 and v4, improvements, not sure yet?

@audibledata @makisuo @EffectTS_ Ah for some reason I thought the opposite and that things were being consolidated around the effect.service pattern - is there anywhere we could reason more about this? (Discord, gh issue, etc?)

@makisuo @EffectTS_ Note that Effect.Service is no longer recommended and will most likely be removed in v4

As promised here is my HIGHLY opinionated @EffectTS_ best practice guideline I have slowly building up over the last year of shipping effect code im production by hand and agent. Additional to this skill I would recommend pulling the whole effect repo locally Hope you guys enjoy!

@dillon_mulroy So eager for this - curious if code (even just WIP throwaway code) is available anywhere?

iterating on effect native durable objects

@flapalap1 @tan_stack Lucky you - some of us have been patiently anticipating it for a while :) github.com/TanStack/route…

@marbemac @tan_stack Damn.. i asked Tanner about supporting parallel routes in mid December.. not even a full month later its almost here 🥳

Let's goo - the parallel routes proposal for @tan_stack router looks so promising github.com/TanStack/route…

favorite alias: `git gone` - it removes local branches whose upstream has been deleted add it: `git config --global alias.gone "! git fetch -p && git for-each-ref --format '%(refname:short) %(upstream:track)' | awk '$2 == \"[gone]\" {print $1}' | xargs -r git branch -D"`

@NathanFlurry @EffectTS_ @rivet_dev And tanstack query! orpc.dev/docs/integrati… is 🔥

> the RPC lives on the stateless HTTP layer checks out the fact that this requires a separate protocol client <-> http and http <-> actor makes me think it might make sense to look at a simpler way of adapting our action handlers to exiting rpc protocols (orpc, capnweb, trpc, graphql, mcp). food for thought.

For Christmas I'd like an e2e architecture that: 1. uses @EffectTS_ as much as possible AND... 2. with actor based backend that makes it easy to swap concrete impl from CF to node, with incredible DX ala @rivet_dev AND.. 3. with a thin RPC layer for logic that is not owned by actors, and an incredible client<->server DX ala orpc AND.. 4. an easy way to expose some of those RPC procedures over a public api ala ORPC openapi integration Is that too much to ask? 🙏😅

@NathanFlurry @EffectTS_ @rivet_dev > the RPC lives on the stateless HTTP layer Exactly this - although we could probably re-arrange things so that everything is backed by an actor, just not how we're setup atm. > our native http/websocket support got a huge upgrade recently Neat I'll check it out!

> 3. with a thin RPC layer for logic that is not owned by actors, and an incredible client<->server DX ala orpc AND.. "not owned by actors" as in the RPC lives on the stateless HTTP layer or you want to communicate with actors in a framework agnostic way? if the latter – our native http/websocket support got a huge upgrade recently, it's probably plug'n'play related to openapi, if relevant – the actor api is also now standardized with openapi + asyncapi

@NathanFlurry @EffectTS_ 🤤 ok where/when/how can I dig into this

We've been toying with @EffectTS_ in Rivet Actors for a couple months now, sharing some progress Should we ship it? What should we change?

@NathanFlurry @MichaelArnaldi @EffectTS_ @rivet_dev YES, this looks super promising

@MichaelArnaldi @marbemac @EffectTS_ @rivet_dev we're close! sharing some progress, last couple bits on workflow integration are still wip x.com/NathanFlurry/s…

@jonas @EffectTS_ @rivet_dev @MichaelArnaldi 👀 what a tease! topical as innn... something along these lines is being thought about? say it's so

@marbemac @EffectTS_ @rivet_dev @MichaelArnaldi how topical 🤣

nope! can just define the schema, and start as a local only collection (tanstack.com/db/latest/docs…). then swap the collection type to electric, query, whatever, when ready and have the backend setup to support it. entire frontend can be driven off of the local collection and when the swap happens usually need little to no change on the frontend

@marbemac @tannerlinsley @tan_stack Wait so you don’t have to define the connections I collections?

forget creating a mock backend - really enjoying pattern of: 1. start with local only @tan_stack DB collections 2. hook frontend up to those collections 3. once all feels good, define pg schemas, migrations, backend handlers, etc, and swap the collections to electric/query

@kylemathews @tan_stack haha yes! and easier to iterate on db schema if don't need to fiddle with migrations etc until the api has settled

@marbemac @tan_stack yesss! I always have loved this pattern but now the switch to the backend is waaay simpler