We also have to look at the design of the tools and the stack. The SQL has to get painted somehow and there are a lot of steps in between.
These steps come from the division of responsibilities, which requires layers of abstractions and associated tooling, each in theory isolating a layer of the stack with nice I/O boundaries, but adding up to a lot of handling to get that SQL query painted in the browser.
Paradoxically, React/Next is the worst possible starting point if you want performance, yet the LLM will reach for it automatically.
This question occupies my mind: given the necessary drive to validate market fit, and with the LLM reaching for common solutions like React/Next and an ORM, among many others, what opportunity is present for those who seek market fit but also develop a simplified stack that offers better performance?
> Many people are saying that AI will make software faster by rewriting it in faster languages, but this isn’t generally true. Most programs cannot be meaningfully sped up by rewriting them in C or Rust.
We also have to look at the design of the tools and the stack. The SQL has to get painted somehow and there are a lot of steps in between.
These steps come from the division of responsibilities, which requires layers of abstractions and associated tooling, each in theory isolating a layer of the stack with nice I/O boundaries, but adding up to a lot of handling to get that SQL query painted in the browser.
Paradoxically, React/Next is the worst possible starting point if you want performance, yet the LLM will reach for it automatically.
This question occupies my mind: given the necessary drive to validate market fit, and with the LLM reaching for common solutions like React/Next and an ORM, among many others, what opportunity is present for those who seek market fit but also develop a simplified stack that offers better performance?
> Many people are saying that AI will make software faster by rewriting it in faster languages, but this isn’t generally true. Most programs cannot be meaningfully sped up by rewriting them in C or Rust.
Article seems to start with a flawed premise.
This is 101 "optimization":
First the algorithms and the models. Then machine code on some micro-architecture.
The real problem with classic computer languages: dependency on vendor-locked (open source or not) compilers and runtimes happens super fast.