No one has been able to explain this to me.
224 karma · joined June 10, 2016
No one has been able to explain this to me.
Auth middleware is used for _routing_ (e.g. if you're not signed-in, you'll be redirected to the sign-in page).
This just means a 500 is thrown due to the auth() call returning null on the server.
What collateral damage? Didn't the whole thing burn up on re-entry? Do you know how much meteorite material burns up in the earth's atmosphere every day?
> And second, avoidable failure is still avoidable failure.
huh? we're talking about risk profile and development velocity
> Engineers who care more about the specific web technology being used rather than solving the problem don't sound like "elite" engineers.
Naive
If you build on NextJS you will get the entire tailwinds of the industry behind you. Having Cursor write a full-stack app that leverages server components alongside client components is a 10x velocity unlock that you won't get if you bifurcate your codebase (as is the rails model)
Typescript is going to be the language of AI engineering, (with Python being the language of ML engineering).
Rails is a fundamentally unserious framework:
1. It lacks LSP (any modern language should support this, think "clicking" a function call to go to it's definition)
2. it lacks type-safety (do you really want to write unit tests to enforce contracts and expectations in your code? or just use the type system?)
3. Object-Oriented-Programming is a failed paradigm for modern web development
4. elite engineers will not want to work for you
Prisma is now taking a lot of ideas from the drizzle team, if I were to start over again I’d just use prisma as it’s actually production ready and is starting to incorporate the good parts of drizzle.
1. I agree, Prisma is not a great ORM. Drizzle is a better choice. It's close to the metal and when the abstraction inevitably leaks, it leaks towards the user using raw SQL
2. Modern JS is extremely performant. Look at any of the benchmarks for the new JS runtimes that have come out in the past 6 months (e.g. Bun / WinterJS / etc...). It approaches Go / Java in terms of performance.
3. Even the traditional NodeJS runtime has been optimized out the ass by Google. For example: JSON parsing has highly performant SIMD instructions under the hood. When a trillion dollar company puts billions of dollars behind a technology it will get fast.
4. There is no possible way that building your CRUD backend in Golang / Rust is a "faster" solution than just using React Server Components.
5. The vast majority of startups are IO-bound, not CPU-bound - so "fast" languages like Go / Rust won't be as relevant.
The benefits of Go (for most companies) only apply once your company hits an inflection point and starts to scale and starts to see the throughput that can really take advantage of a lower-level language.
If you're building a high-throughput infra company or something, then the things I've mentioned are less relevant.
This was posted here a few weeks ago. Doesn't seem like there have been any developments since.