etse

Ah, got it. Still impressive.

The memory forking is really interesting. I wonder if copy-on-write at the VM level, O(1) with respect to machine size, won't scale cost with how many forks to take, but 320ms median seems good for the branch-and-explore pattern without reprovisioning every time.

One gap I'm noticing in these comments and in the current sandbox landscape is Windows. Every platform mentioned in these comments like E2B, Daytona, Fly Sprites, Sandflare appears Linux-native. Makes sense for coding agents targeting Debian environments, but a real category exists to automate Windows-specific workflows: enterprise software, ERP systems, anything that runs only on Windows.

If anyone wants to run agents in Mac or Linux and need to access Windows for computer use, Dexbox could be helpful. [github.com/getdexbox/dexbox]

I launched an open source developer tool called Dexbox to run agent workloads that quickly provision and run Windows desktops. It's a CLI and MCP experience that's different from Freestyle, but slightly closer to our Windows-specific production infra, Nen. I like Freestyle's cool UI that shows off the unique technical approach and developer friendliness. Nen's a bit closer to that experience.

So, neither?

Isn’t frontend more complex? If my task starts with a Figma UI design, how well does a code agent do at generating working code that looks right, and iterate on it (presuming some browser MCP)? Some automated tests seem enough for an genetic loop on backend.

What’s the challenge with getting it working in macOS? Vulkan?

That seems unusual. I would assume trivial means the default approach works for most cases. Perhaps mutable global variables are not a common use case. Unsafe might make it easier, but it’s not obvious and probably undesired. I don’t know Rust, but I’ve heard pockets of unsafe code in a code base can make it hard to trust in Rust’s guarantees. The compromise feels like the language didn’t actually solve anything.

I have hardly come across aspiring-CEOs who do not have much ego and listen to other founders, let alone founders or serial-founders. After some founder dating last year, I am a bit jaded, though.

Morality is not about intelligence, but some folks believe living by morals is submitting oneself to the lack of intelligence (or stupidity even). The real [evil] geniuses prune their decision tree by not considering morality so they maintain optimum efficiency.

There is a lot of sentiment in these comments about needing to scale still. I wonder how many need to do this in a pre-PMF stage vs growth stage? The trade off is faster growth if your PMF bet wins and loss of time if your bet goes south.

Maybe not capabilities, but I'm wondering if Postgres has gotten any easier to scale horizontally. The administrative overhead of scaling and maintenance with MongoDB seemed lower to Postgres to me.

Would love to hear from others with more Postgres than I.

Interesting idea, but questionable scholarship.

Hmm. Maybe you should test the site on a different phone. Not seeing an issue with responsiveness here.

Not when the roundabouts are placed within the bounds of a 4 way stop. Not sure if those are called roundabouts, but I don’t like them.

We don’t need to overstate racism, but “bigwig at TI” is a down leveling for Morris. Doesn’t seem right to limit greatness if it’s about race and not based on track record or other meritocratic signals.

How? Morris didn’t get the job because he was born in the wrong country?

Very wealthy people have access to very exclusive and potentially unethical and/or illegal capabilities. Many do not think they are bound to the same rules as the rest of society. Some are probably not.

OpenAI the company may not be responsible, but there are elites in the OpenAI sphere who might be.

I’m curious which are the well known projects or products that have ported or converted away from Go. Anyone have a shortlist?

why structured editors haven’t taken over the world: most programmers find them so annoying to use in some situations that they don’t view the pros as outweighing the cons.

Seems like "annoying" refers to a user interface annoyance.

I'm guessing the following since I couldn't tell what structured editing is like from the article:

Keyboard entry is immediate, but prone to breaking the program structure. Structured editing through specific commands is an abstraction on top of key entry (or mouse), both of which add a layer of resistance. Another layer might come from having to recall the commands, or if recognizing them, having to peruse a list of them, at least while learning it.

What does the developer's experience with incremental parsing feel like?

This article was kind of lazy. It’s a lot of conjecture, a couple anecdotal observations, and some rhetoric for good measure. Basically, the content was a let down from the title. On the other hand, I didn’t know Data Scientist candidates would also be tested with LeetCode questions.

“Yak” shaving of a sort!

Are you opposed to the process by which discussion can initiate a transition from negative state to positive state?

Seems healthy to me.

The opposite seems true (regarding Go being over-fitted to Google problems).

It was designed for Google, but Google has not adopted it widely. Google is still heavily C++ and Java after all these years. The outside world loves it way more. Kubernetes isn't used internally at Google (except Cloud, which is not any different from any other cloud provider) though it's sponsored by Google. Bazel is probably in a similar boat.

Being designed to solve Google problems doesn't mean that it actually solves Google problems well, or that Google thinks it does.

I became introduced to Go through my startup and my experience was it a delight to work with in very small teams.

Palo Alto is in Santa Clara County whereas Menlo Park and East Palo Alto are in San Mateo. That might be how.

Agreed. This is very well written.

I discovered the joy of Go from dealing with JavaScript promises while writing an API service in Node. So many painful runtime errors uncaught or unlogged because promises don’t (or didn’t) require the catch callback.

I think inverting the programming perspective to default to sync instead of async is more productive for web services development, than perhaps for UI.

The belly cut for comfort.

My reading of the article is that because LangChain is abstracted poorly, frameworks should not be used, but that seems a bit far.

my experience is that Python has a frustrating developer experience for production services. So I would prefer a framework with better abstractions and a solid production language (performance and safety), over no framework and Python (if those were options)

I'm not quite understanding how different prompts for different models reduces the attractiveness of a framework. A framework could theoretically have an LLM evals package to run continuous experiments of all prompts against across all models.

Also theoretically, an LLM framework could estimate costs, count tokens, offer a variety of chunking strategies, unify the more sophisticated APIs, like tools or agents–all of which could vary from provider to provider.

Admittedly, this view came just from doing early product explorations, but a framework was helpful for most of the above reasons (I didn't find an evals framework that I liked).

You mentioned not having this problem yet. What kind of problems have you been running across? I'm wondering if I'm missing some other context.

If you wanted to compare OpenAI models against Anthropic or Google, wouldn't the framework help a lot? Breaking APIs is more about bad framework development than frameworks in general.

I think frameworks tend to provide an escape hatch. LlamaIndex comes to mind. It seems to me that by not learning and using an existing framework, you're building your own, which is a calculated tradeoff.

Go's debugger has worked just fine for years. What do you prefer about gdb (which also seems to support Go)?

Go isn't pretty to look at, but I feel so much more confident in a successful Go build than starting up Python–not knowing when exceptions will throw or crash until it's run is frustrating.

I'm sure Rust folks feel exponentially more safety than Go at compile time, but the jump from Python to Go is dramatic for me.