HN user

MehdiHK

181 karma

https://mehdikhan.dev/

Posts4
Comments79
View on HN

If you need true multithreading

I didn't say multithreading anywhere. Mutitasking (concurrency) != Multithreading.

You can do pre-emptive concurrency with a single thread in other runtimes, where each task gets a pre-defined amount of CPU time slice, that solves fair scheduling for both IO and CPU-bound workloads. Nobody is supposed to pick NodeJS for CPU-bound workload, but you cannot escape JSON parse/stringify event-loop blocking in practice (which is CPU-bound).

JSON.stringify was one of the biggest impediments to just about everything around performant node services

That's what I experienced too. But I think the deeper problem is Node's cooperative multitasking model. A preemptive multitasking (like Go) wouldn't block the whole event-loop (other concurrent tasks) during serializing a large response (often the case with GraphQL, but possible with any other API too). Yeah, it does kinda feel like amateur hour.

Not related to VPC, but I'm a big fan of the author. Loved his book "Grokking Algorithms: An Illustrated Guide for Programmers and Other Curious People" when it came out a few years ago. If you know anyone struggling with common data structures and algorithms, this book can make it fun for them.

This.

I'd also add that code readability goes a long way too. Rust compiler has better checks than Go, but when LLMs make mistakes it's a lot easier to identify and fix generated Go code than Rust.

So the balance between verbosity and readability is important too, in addition to soundness checks. Java and Go are both verbose, but Go is intentionally designed for readability.

And compile time as already mentioned. Go wins there too.

All of these help together to iterate faster with fast and often subtly wrong generated code. LLMs will continue to be less wrong as the available training samples increase over time. That's something for the future to see what wins there.

I don't have enough HN points to downvote this comment, otherwise I would.

You don't know how comments like this affects people with anxiety, which probably led them to search for a solution online in the first place.

Anyway, you are person unworthy of any attention. I'm just trying to make sure op isn't taking you seriously.

One solution that seemed to be the best of both is, a take home test followed by pair programming session to add a small feature on top of that, or refactor something, or write tests etc.

Real world challenges needs time to think, often time to refactor after initial working prototype. A take home allows that.

Also the candidate is already relaxed in the pair programming session because it's a familiar codebase. You'll get signal if they didn't write it or wrote something they didn't quite understand.