Dependency injection provides the same hermetic-testing capability, so that's not really an answer to OP's question. Effect-as-world-model is, in this specific way, just a special argument slot that only accepts dependency-injected functions.
What effects provide beyond DI is entirely in their ability to abort (resume zero times) or (in the case of multi-shot effects) resume multiple times. An effect that resumes exactly once is structurally the same as a dependency injected lambda.
> What effects provide beyond DI is entirely in their ability to abort (resume zero times) or (in the case of multi-shot effects) resume multiple times
Thanks, this answers my question and does sound handy. Also I do see the value in having more problem-shaped versions of a general construct.
> Algebraic effects with deep, multi-shot handlers. A handler can resume a computation zero, one, or many times, which is what makes exhaustive search and exact inference ordinary library code.
I love me some algebraic effects, but this sets off alarm bells for me.
Multi-shot effects are neat and powerful but are incredibly difficult to reason about for humans, and given that there are few languages that have implemented them (and they're so niche with very little training data) I'm skeptical that LLMs are sufficiently better at them to make up the gap.
One-shot effects are a cross between `throw` and a function call. Multi-shot are full-on delimited continuations and come with all the complexity that entails.
That’s a fair concern. I’d expect multi-shot handlers to be relatively rare and mostly something library code uses rather than a day-to-day utility. But an LLM given free rein may decide to behave differently.
For now, I am looking into making a clearer distinction between one-shot and multi-shot handlers so we can reject cases where resuming again would be unsafe, like around filesystem writes.
Looking at the official description of a Forward Deployed Engineer I'm uncertain what even the nominal difference between this and a Solutions Architect is.
Is the nominal difference between an archetypal FDE and an archetypal SA greater than the difference in the SA role from company to company?
The skillset is different. SAs everywhere I’ve worked are solidly salespeople. They can do AE work in a pinch, they use Salesforce, they know how to understand the state of an account, etc. They tend to be more limited technically and as such are generally deployed for the sale of a product which is “finished”, and as such spend most of their time mapping customers onto existing patterns that are already known to work, and identifying those patterns.
FDEs are different in that they’re deployed to sell and integrate products which are unfinished in some way. For example Palantir sold a fairly low-level generalized product which required bespoke technical work to integrate with a customer. This integration work is more like normal engineering work in that lots of code may have to be written and there’s technical creativity required. The reason why FDE is increasingly in vogue now is because AI companies haven’t yet found a high-level product shape which is generalizable across many customers, because the market is immature and customers probably don’t know what they want. So there’s lots of engineering work required to take a lower-level offering (e.g some sort of agent) and figure out how to use it to generate value for one particular customer.
Based on what I first heard it described as, yeah, I think so.
In most places I've worked SAs are generally just connecting existing pieces of a system together to meet a customers needs. They may write code, but it's often just glue to connect two bits of the system together or transform some data or something like that. They're not really contributing to the underlying product, they're just using the product and some custom code to meet a specific customer's needs.
An FDE is supposed to be closer to a regular software engineer on a product or platform team in that their goal is to solve a specific customers problem, but they're supposed to be more focused on the big picture and using their learnings to build a better product. They're still using existing systems to solve problems and writing plenty of glue code, but they're also supposed to have the leeway to contribute to the underlying product to make it better for all customers.
The simplest example I can think of would be something like a customer saying something like they need a way to convert a bunch of their data to a CSV and then send that to a certain email address every Friday. A more traditional SA mindset may be to write a Python script that runs on a cron that connects to that customers DB pulls the data, converts it to CSV, and then emails that specific email address. Even if the SA knows that's not the best way to do it, it's the tools they've been given to work work. A FDE should have the leeway and skills to go talk to a PM and their engineering team and just build an in product, self serve tool to do that (assuming everyone is aligned that that is good for the product).
Again though, what I've heard is that most FDEs at most companies are just SAs by another name.
I think it is. I work for a (relatively) small company. I naturally grew from project engineer to senior/lead/sme (including pioneering tech _for my industry_) to SA. I had also stuck with my company for many years, so I have the industry connections and got to be known as a heavy hitter. That trust relationship with the customers mixed with technical know how = sales and consulting.
Again, because of the size of my company I can make my role fluid (including a good way), but call it what you will I engineer, I sell, I consult.
I chose Porkbun because it's a small company with good prices, a good vibe, and all the tools that I need. Cloudflare was never going to be on the table because I don't want to feed the beast that is already swallowing the entire internet.
I'd honestly be careful with squarespace. They are owned by private equity, advertise on countless YouTube channels, and at the same time their core market is under a looming threat from the AI companies.
You need your domain registrar to be stable and predictable. Their profile is not that.
Their prices had already been going up for a few years before that, which finally pushed me off them starting around August of last year. I'm about to swap my final few domains over this month before they renew.
Porkbun has been great so far. Easy to use, refreshingly minimal, and good prices.
The weird twist here is that I've found that there are times where Fable is actually worse than Opus at a straightforward task, not just more expensive. It'll launch off into its own little world for an extended thinking, then start editing files, and I'll already have spent $5 in tokens before I see enough response to know that it's on the wrong track.
Opus's verbosity is actually a boon sometimes for catching false starts early.
This piece focuses on the cost differences from the tokenizer, which do matter, but I wish they emphasized more that even adding the tokenizer to your calculation doesn't provide you with a good way to calculate cost for agentic coding tasks.
Other traits where models differ that have an even greater impact on your total spend:
* How much context do they load in to solve a given task?
* How long do they spend thinking to get equivalent results?
* How many times do they stop and ask you for input, and are you there to respond to them before the cache runs out?
* Etc.
Incorporating the tokenizer just makes a very imprecise measurement of cost a little bit more precise, but in my own experience I have not found that the token cost is a significant driver of task cost whether or not you incorporate the tokenizer. Everything else about the model's behavior has a much larger impact.
No one's obliged to respond to hearsay by trying to guess what the other party might have misheard to arrive at a false conclusion. It's enough to demonstrate that the conclusion they came to was false, and if the other party would like to defend themselves they're welcome to explain why they came to that misunderstanding.
If that's what he meant that doesn't speak well for his communication in this post, because "the Bun team told us that they were not fuzzing anything" is a wildly different claim than "the Bun team told us they weren't using a specific tool for fuzzing".
What effects provide beyond DI is entirely in their ability to abort (resume zero times) or (in the case of multi-shot effects) resume multiple times. An effect that resumes exactly once is structurally the same as a dependency injected lambda.