vendiddy

I can't remember who I read this from (it might have been Alan Kay) but they basically said the web browser should have been an address bar with the ability to run any sandboxed applications in the screen below. They said the internet well designed but the browser was a disaster.

So hyperlinks were good but the rest was a bad design. An HTML viewer and Javascript interpreter would have just been one possible app to run in the browser.

It is a shame that, to this day, the browser can't easily handle running arbitrary applications. You're still effectively locked into JS/HTML.

I customized the hell out of my keybindings. I might be in the minority though! I was trying to give examples of (stupid) little points of friction that might prevent someone from taking the leap.

The vision sounds interesting but I think if they have two challenges they will need to overcome to compete in the IDE space

1) Their LLM integration needs to be at the quality of Cursor and VSCode to pull people away from those

2) Reduced friction to move over (keyboard shortcuts, common plugins, etc)

I think the Zed team is perfectly capable of winning. The bigger risk would be them trying to tackle fancy stuff before making sure the basics are good enough to get developers to switch.

They need to build up a deep understanding of why folks are sticking to Cursor/VSCode and not swapping over.

P.S. I would love for Zed to win in the market because I'm sick of slow software and it's refreshing to finally see an intense focus on performance.

I don't think it is because it just requires that you write frontmatter in YAML which is pretty human readable and common in certain markdown formats.

Your notes are still in markdown.

But exactly. The one thing you care about in a gym app is getting into the gym!

If get a chance to read some Elixir/Erlang code you'll see that pattern matching is used frequently to assert expected error codes. It does not mean ignore errors.

This is a common misunderstanding because unfortunately the slogan is frequently misinterpreted.

I think the slogan was meant to be provocative but unfortunately it has been misinterpreted more often than not.

For example, imagine you're working with a 3rd party API and, according to the documentation, it is supposed to return responses in a certain format. What if suddenly that API stops working? Or what if the format changes?

You could write code to handle that "what if" scenario, but then trying to handle every hypothetical your code becomes bloated, more complicated, and hard to understand.

So in these cases, you accept that the system will crash. But to ensure reliability, you don't want to bring down the whole system. So there are primitives that let you control the blast radius of the crash if something unexpected happens.

Let it crash does not mean you skip validating user input. Those are issues that you expect to happen. You handle those just as you would in any programming language.

It is but requires discipline.

I've been coding for 15 years but I find I'm able to learn new languages and concepts faster by asking questions to ChatGPT.

It takes discipline. I have to turn off cursor tab when doing coding exercises. I have to take the time to ask questions and follow-up questions.

But yes I worry it's too easy to use AI as a crutch

sounds like legacy code

This is exactly what I want!

This will also allow the wider community to innovate rather than waiting on standards bodies to decide what the think is best.

Personal experience - it comes down to how good the product manager on my team is.

Bad PM: I need to make sure I am not wasting time building the wrong thing. So I am forced to be "distracted" and play the role of a PM.

Good PM: I need to stay focused building. The PM has already done a great job figuring out what needs to get built. They have given me a good mental model of how the customer thinks.

Sure some facetime with customers is good but the article has a simplistic conclusion.

I don't know much about CPUs so maybe someone can clarify.

Is this effectively having a bunch of tiny processors on a single chip each with its own storage and compute?

I usually feel more concern whenever more features get stuffed into the browser.

It is an accumulation of complexity that, for backwards compatibility, we get stuck with.

The browser should be simple.

If the focus just stayed on making wasm better for web development, folks can use any language they want and the API surface area can stay small.

I personally find that doing it well in the first pass slows me down and also ends up in worse overall designs.

But I am also pretty disciplined on the 2nd pass in correcting all of the hacks and rewriting everything that should be rewritten.

There are two problems I have with trying to do it right the first time:

- It's hard to know the intricacies of the requirements upfront without actually implementing the thing, which results in designing an architecture with imperfect knowledge

- It's easy to get stuck in analysis paralysis

FWIW I am a huge fan of John Ousterhout. It may be my all time favorite book on software design.

Just seeing this now. (Is there a way to turn on notifications here?)

Thanks for the breakdown!

And I suppose they are eating the cost of worse latency to allow for more scalability?

To be fair, I think most apps don't need zero-downtime deployments in the telcom sense.

Most host have blue-green deploy options which reduce downtime and there are fewer corner cases to deal with.

I find local recompile very useful for prototyping in development mode. So much so that I have a keyboard shortcut to trigger a recompile. (I don't like recompile on save.)

I think in many cases the ecosystem issues are overblown. For the common 90% of use cases there are battle tested libraries out there.

For the less common ones, we tend to just roll our own which in most cases isn't that bad if you have reference implementations.

I think the most under-appreciated aspect of Elixir is how it helps reduce complexity. And there isn't a silver bullet here, but the tooling, immutability, pattern matching, process-based concurrency model, etc are all design decisions that, IMHO lead to simpler, more robust code.

(Caveat: of course, like any language, you can make a mess of things.)

I'm curious what libraries they wish existed.

I expect we'll reach AGI before we get a printer that prints.

Why is it an awful idea? I don't understand the trade-offs well.

Do you honestly believe what you're saying

They've been pretty explicit about their goals in not settling for a local optimum in the language and taking their time.

It seems like folks expect stability pre 1.0.

One habit I've gotten into is trying to aim for negative LOC pull requests on occasion.

It has the added benefit that I'm forced to keep the codebase fresh in my mind.

I will frequently extract OSS style libraries out of our app and put them in a packages/ folder.

Do LLMs need to be good at math with the same approach?

To draw an a analogy, we've got our human brain specialized.

Why not implement a part of the AI brain that's not neural nets, but instead circuitry specialized to math?

Maybe a dumb question since I'm a layperson!

Thanks for the breakdown! I love reading quick overviews like this.

I really like using o3 to help with thorny architecture problems by researching existing related solutions on the internet, distilling them, and comparing trade-offs with me

Do you have an example?

I'm trying to understand what you mean by meta promoting

I find o3 to be the clearest thinker as well.

If I'm working on a complex problem and want to go back and forth on software architecture, I like having o3 research prior art and have a back and forth on trade-offs.

If o3 was faster and cheaper I'd use it a lot more.

I'm curious what your workflows are !

I would love for them to optimize the ChatGPT desktop client. It lags on me quite frequently.

I think a lot of people including myself feel this way.

I really like the Nix model of derivations and approach to deterministic builds. It's the language IMO that prevents it from getting mainstream adoption.

I think they would be best served by picking a subset of an FP language that already has good ergonomics and tooling.