early stage product: 🪵 collect tinder, start fire before freeze
later stage product: 🔥 keep fire alive, grow fire, defend fire
very different
h/t @christineluc
let me make the case for sandbox:
gives idea of an environment and doing stuff (building sand castles, stateful, designable, …)
does not imply durability (but also does not limit if eventually there is a durability angle, good!)
but maybe most important: it is already a term people are familiar with
better to piggyback on familiarity unless you want to invest in establishing a new paradigm
the name is just the 'hook' in the association space
you want to then define/spec/doc what it means in exe-land anyway
think of it a bit like cloning the prototype association of 'sandbox' vs 'ephemeral' and how useful that would be to you, how large is the diff in meaning to what the thing means in exe-land
that's the bridge every user has to cross (and you to help them cross)
@timsoulo@ahrefs e.g. for branded searches via tool use the agent will look up the landing page (homepage?) of a brand or product and often also app store listings
so if this is your brand it definitely makes sense to curate well what's on there
@timsoulo@ahrefs re #2 can you elaborate more on how you categorize whether they are influenceable or not?
what makes educational pages, reviews, news, blog posts influenceable and homepages and app store pages not influenceable?
so much of performance (optimization) is schlep
yes, it's also data structures, algorithms, access patterns and so on
but a lot is not about cleverness and more about facing what needs to be done
and then doing it
One of the big challenges right now is choosing between a large generic human reviewed dependency or small focused generated code that is under reviewed.
remember the dev trope
investing hours to write a program for a one-off task that would only take minutes manually
agents do this now all the time but in seconds
Have you noticed Anthropic's shipped pdf-viewer plugin never actually shows the PDF?
It's fundamentally broken and has been for a while.
So we at Nutrient built one that works.
https://t.co/RdwGgNSSXD
Fork your dependencies, trim them to only your use case, never update unless it breaks for your users. I’ve been vocal about this for 10+ years. I’ve always said that updating is way riskier than latent bugs (which can be tracked and CVEs monitored).
If you are updating a dependency, it’s on you to analyze every single commit in the full transitive set of dependencies. If you dont see anything compelling, dont update!
I remember at HashiCorp once in awhile an engineer would try to update a dep or replace a DIY lib with an external one and id always ask “show me the commit we need.” Dont update for the sake of it.
Feeling pretty swell about this mentality with all the supply chain attacks happening.
It isn't unexpected that the focus of the Bun Rust rewrite is on the anti-Zig side more than anything, since the internet loves to hate. What is unexpected and unfortunate is that leadership within Bun hasn't tried to steer the conversation away from that at all.
There are so many positive and interesting takeaways from this and I'm not really seeing any of them pushed as the primary message.
A positive thing that hasn't been talked about at all is how far Bun came thanks to Zig. And even if you dump it now, its meaningful for how good Zig was to even build a product to this point and impact by any metric. I would've loved to see anyone in leadership say this.
On the interesting side is how fungible programming languages are nowadays. Programming languages used to be LOCK IN, and they're increasingly not so. You think the Bun rewrite in Rust is good for Rust? Bun has shown they can be in probably any language they want in roughly a week or two. Rust is expendable. Its useful until its not then it can be thrown out. That's interesting!
There's been a lot of talk about memory safety and no doubt Rust provides more guarantees than Zig. But I'd love to see a better analysis of why Bun in particular suffered so much rather than take the language-blame path. How could engineering as a practice been more rigorous to prevent this? What were the largest sources of crashes other programs should watch out for? How does Rust prevent them? How could Zig theoretically prevent them? That's interesting.
I know the official blog post hasn't come out yet from Bun. But they're smart enough to know that that PR would stir up controversy the moment it opened, or they should've been. And plenty in the company have been tweeting and writing about it. Its somewhat telling to me in various dimensions what they chose to talk about first.
I tend to think I'm pretty good at corporate PR/comms (especially when it comes to developer audiences) and I think appealing to the negative is never the right long term strategy; it does work to get short term eyes though.