Comment by rohan_ | Hacker News Reader

Comment by rohan_ | Hacker News Reader

Parent Full thread

I'm fairly opinionated about this:

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.

>> 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.

https://www.techempower.com/benchmarks/#hw=ph&test=composite...

I like JS but lets not blow smoke up anyones ass here. Your not picking node or its faster safer cousin bun for server speed. You're picking it because you can keep your engineering overhead to a smaller number. Your picking it because you need to generate pages out of your SPA like app.

> 4. There is no possible way that building your CRUD backend in Golang / Rust is a "faster" solution than just using React Server Components.

Spend a month with SQLC and writing blood and guts API's in go. Your gonna realize that the slight slow down in finishing the feature code is more than made up for in finishing testing, ease of deployment and a million other things that you skip by NOT using a JS backend.

>> 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.

This is some holdover thinking from PHP vs JAVA days that isnt true when comparing node/ruby to go/rust ... Im going to leave python out because you may have OTHER reasons (existing bindings to C ...) to head in that direction.

>> If you're building a high-throughput infra company or something, then the things I've mentioned are less relevant.

Maybe this is true. But I worry about the long term stability and paintability of anything written in JS. So much flavor of the month and then poof, off to the next thing, it IS a concern.

I only use TS on the frontend, so less opinionated about some of this.

I’d love to see some of the codebases where people complain about performance so I could profile them myself. Would put money on being able to improve the situation by orders of magnitude without switching stack.

We use Python on the backend of our web app for realtime image recognition and it’s fine because we’ve been thoughtful about data structures and algorithms.

>> We use Python on the backend of our web app for realtime image recognition

I have no qualms with python. But Python is the high fructose corn syrup of programing languages... It's in everything.

It's dead easy to write out c bindings so from ML to Math to big data tasks it forms the glue to a lot of things.

My question is: is your real time image processing IN python or in C that python calls out to?

There’s numpy in the middle, so bits are outside python. The vast majority of the code is Python though and the performance gains come from being strategic about the architecture.

My point is that for most usecases you can go a lot further by looking at the code that’s running rather than the language that’s running it.

I think python have the best libraries you can buy, and that makes python a very strong choice if you do not suffer the NIH syndrom or do not need extremely fast code (python is fast enough now).

One big issue i have though: the lack of easy multithreading reduce your possibilities, or at least limit your creativity: you will often choose to use async/await (and sometimes use signals) rather than use producer-consumer designs, which are often the optimal solutions.

Reply on news.ycombinator.com