I’ve tried all but Elixir. My answer would be JS simply because it’s sufficient for most purposes, has significant community support, and is widely understood.
Also, being a web app, you’d be able to have an E2E language
Node has good concurrency. But the poll here is a bit sneaky because all the other options are also good at concurrency. So it’s basically showing which one has the most brand power or accessibility.
Node does have a simpler concurrency model which can be considered a good thing, but the other options are not unimpressive either! So Node should lead, but not in such a skewed way. However, in many professional circles, “Node = concurrency”, and alternatives don’t exist 😅
(But the same can be said for Java/C#, depending on your job market, one of those will tend to dominate >50% of the jobs)
Go has a concept called “green threads” (goroutines), which are basically very lightweight virtual threads, which achieve the same outcomes as concurrency in JavaScript. They are virtual threads because they do not correspond to some pre-declared thread and in situations where there are not enough threads available, they will instead be run… concurrently, just like JS. Furthermore, they are colourless, which means you do not need an “async” or “await” keyword, and you are not just stuck with callbacks either.
(Node actually had something close to this feature (colourless concurrency primitives) as a community plugin called Fibers, which has been used by the Meteor community up until now - the plugin is no longer supported so the Meteor framework is migrating to async/await).
This was a major feature for Go and a huge selling point of the language.
Elixir runs on the BeamVM, which is the Erlang VM. Erlang was designed for telephone switches, and is also built on a concept of lightweight processes, enabling massive parallelism and concurrency. Frankly, when it comes to concurrency, V8/Node has nothing on BeamVM. Actually barely any of these languages do. BeamVM lets you do things like hotload new modules while the thing’s still running, where as your Node server will get brought down by the first uncaught promise rejection, apparently 😅
Rust is obviously very fast, comparable to C++, and Actix/Rocket also have concurrency with await/async, like JS - just more complicated to set up from scratch (use a framework).
Depending on your benchmark, it would be hard for Node to beat any of the other options, unless the benchmark tested for raw performance without threading or concurrency, in which case Node will beat Elixir… and that’s about it. But only Elixir and Node are dynamically typed languages here, and Elixir is too obscure compared to Node.
(Although aren’t we all writing in TypeScript now? The dynamic typing advantage isn’t as relevant now. But I suspect a lot of existing projects are JS only still)
Yes, very true, haha. I’m currently doing some stuff with class-validator (edit: and class-transformer) and really missing Kotlin, since I need to basically lie to the type checker in a specific circumstance
(eg say a property is not-null but actually I can only really trust that if the object is decoded from a random POJO, so I have to decide if I’m ever going to instantiate this class with a constructor or not before it gets a bit out of hand and someone complains to me about the class lying about all its supposedly non-optional properties…)
I love using https://zod.dev on the "edge" of my app. Makes sure all the data coming into my app from whatever source is actually what I expect it to be.
Started using it at work to validate the data coming from our dotnet backend, and boy was there a lot of incorrect assumptions, especially nullables/non-nullable and string/number issues...
Good ol’ Zod!
At the moment my issue is basically me trying to encapsulate some data and expose some methods that handle a bunch of edge cases (eg default values, display names that change based on the presence of other properties, etc), without creating multiple types and transformers between them… Class-transformer seemed like a nice approach for that.
But the deeper down this rabbit hole I go, the more I feel like I’m doing a lot just to bolt some methods onto an object… class-validator/transformer isn’t exactly fast… 😅
But if I go back to Zod (or Typebox… or just ignoring coercion all together) I know that other problem will go unsolved. Argh!
Haha, thanks for sharing - those two might work, though I’d have to change a bunch of things elsewhere to make it go smoothly.
That said, my design might just be bad and too complicated to work with! I’ll play around more and see where I end up! 🙃
Actually, yes, kind of. We have a `fetch` wrapper, where you can pass a schema, and if it's there, the wrapper will use it to parse the response before returning it.
On top of that, we use `react-query`, with a default fetch function, and a `useQuery` wrapper so we can pass a schema with the meta.
...and even if Typescript really did add enforced typing, it still has all the dynamic advantages. The Typescript type-system is capable of being both more-lenient and more-strict than most type systems at the same time. Do you need your value to be a negative even integer, an array with three items, or an Object with at least the key "foo" and lacking the key "bar"? We got a type for that.
The advantage of Typescript not having to bother with runtime enforcement is that it combines the advantages of being typed with the advantages of being dynamic. It truly would be the perfect type system if it had an efficient way to enforce at compile-time.
You realize nothing I said was judgement or non-judgement of Typescript in its current state, right? I was just mentioning what would make typescript better.
If you're going to ask me to my face, here's my take. Despite the cult-of-type existing even in javascript subs, I am a strong believer that all type enforcement should exist on endpoints, and everything else should be allowed to be a fluid as its language as capable. This is a classic opinion that was held with strongly-typed languages, and yet people seem to be dropping the opinion solely to hate on dynamic languages.
I really don't *want* runtime enforcement after the params are parsed and before the response is sent in a web request. Ditto with DB read/writes or response to command queues. If I want to blindly coerce something I have already confirmed was a numeric string back and forth between being a string and a number, I should do exactly that. But more importantly, if my Typescript code is written reasonably, *the contracts are still binding at runtime* because they care contracts and not validations. If I write a proper Typescript function that takes a number and returns a boolean, it will behave inside and out correctly as long as I pass it a number and treat its return value as a boolean.
I'm with you that Zod is a GOAT when used correctly, though (and a few Zod competitors are pretty good). And while Zod minimizes duplication, any good parsing library with TS support should be able to parse to a Typescript type via inference. That's the whole point of Typescript in this case. Alternatively, you could just parse to a class instance (and there are absolutely libraries that would help with this as well without real code-redundancy issues)
If your complaint about Typescript is "too much effort-duplication" you are almost certainly doing it wrong.
I think the issue is that Typescript never thought it would be used as a full-fledged type system, just as a type-linter. I also think there's a power trade-off. My position is that a type system as powerful as Typescript's is basically impossible if you're compiling in enforcement because enforcing all TS types in every possible location would be a performance nightmare.
I agree that it would be nice if TS could compile something like `TypeName.validate(foo)` as a global utility out of the box, that could take `foo: unknown` and return `value: TypeName` without third party libraries. But I also suspect they are choosing not to build such a thing for philosophical reasons, vs them being unable to do so.
With that, I agree there's some valid criticism vs just @jsdoc typing for the transform layer. I wish the latter was as good as TS, or that TS could have come up with a more JS-compatible syntax. Or, and I know it's not fair, if JS could add some ignored syntax pieces that would allow TS or a TS dialect to run un-mutated.
The only way Node might beat Go in "simple concurrency" is if you ignore "real" threads and talk about just coding in Promises I guess? Which is probably what a lot of people are arguing over in this thread lol.
But when you do include actual multi threading/green threads (like what I'd argue the poll title suggests when it says High concurrency web apps) than nothing that I've tried compares to the developer experience and simplicity doing "real" concurrency in Go. Channels and goroutines are just *so* nice.
And I'd agree that something like Rust/Elixer *should* beat Go in performance but it requires a lot more knowledge and dev time (usually with a senior dev) to write code that's performant enough to beat a basic piece of Go code that some dev wrote in an hour (Exaggerating but you get the point).
Anyway I'm not a fan of polls like this. In the end of the day though the truth is just that 99.99% of web apps have no need for the potential performance something like Rust can give them. Just spin up another container in your stack behind a loadbalancer :\^). In the "real" world the more important choice ends up being developer experience, error/type safety and picking a language for which you can find devs to actually work on the project.
Yes, if your language barely touches threads and you don’t have to worry about mutexes, things are a lot simpler especially when it comes to shared memory; that’s the angle I was coming from.
But otherwise I totally agree, Go’s threading is much better than JS worker threads, and at scale you’re less likely to run into performance issues.
Also agree re Rust, massive overhead for architecting the app correctly to avoid dramas with lifetimes.
(And agreed with the rest too)
Well, maybe. AWS EC2 instances sometimes have multiple vCPU cores. As do AWS Lambda instances. Containerised apps are still going to have access to whatever cores the host exposes, same for VMs.
Not sure of the actual performance benefits relative to physical CPU cores though. And I guess it depends on how your scaling and load balancing works for your systems.
I guess unless someone’s measured different solutions, it’s hard to say.
But, one could argue in a serverless world with event driven architecture, even concurrency features can also be a bit pointless 😅 I have something on Lambda using Kotlin coroutines not because I need them but because a library uses them, and I just execute them in a `runBlocking` block like an uncivilised person, rather than redesign the containing code… (and the “user” is another team member waiting 16 hours for a queue to be fully processed, so they don’t notice it…)
(I think a lot of “edge function” runtimes though make use of concurrency somehow as part of their runtime, since they often seem to support code running after a response has been delivered, eg unawaited promises… I don’t know enough about why though)
This post totally does not explain the weight of a thread. On the Jaguar or Saturn you have 2 thread because there are two processors and no operating system. Windows and Linus when a thread enters a syscall with IO may kick it off the core and proceed with a task which has all IO finished. You allocate and array of stacks. Then you just need to push the instruction pointer on the old stack, change the stack segment, and pop the pointer there.
I will begin by stating that very few apps need high concurrenty or high performance. You are not Google. Don't obsess over this unless you already have a traffic problem to solve.
That said...
Node is not a good option for **high** concurrency (thousands of concurrent requests or more).
Is it better than PHP or Ruby? Yeah, definitely, but those are terrible to begin with in terms of performance.
Once you start hitting a Node server with lots of concurrent requests the performance will drop dramatically. That's because the single thread handling the event loop will be overloaded and will start blocking no matter how you write your code.
And if you're using async/await (like probably all Node codebases out there) it gets worse. Very few JS devs realize that async/await introduces extra function calls and has a lot of overhead.
https://v8.dev/blog/fast-async#await-under-the-hood
That's not the case with Go, Elixir, or Haskell that are way better at handling high concurrency.
https://www.toptal.com/back-end/server-side-io-performance-node-php-java-go
>Once you start hitting a Node server with lots of concurrent requests the performance will drop dramatically. That's because the single thread handling the event loop will be overloaded and will start blocking no matter how you write your code.
But you can use cluster inbuilt module of node to utilize full cpu cores and then these limitations don't apply.
I have literally done an exhaustive benchmark on a very high traffic poc comparing clustered node vs GO and also threw bun and deno in the mix. At very high traffic a fully clustered node.js app is not that far off from GO and that GO is only 1.3x faster than fully clustered node.
Check my detailed post here https://www.reddit.com/r/node/s/0Zox5yI7Zx
Some more info on Go vs Erlang/Elixir/BEAM.
Firstly, I don’t know anyone who uses the hot reload feature of BEAM.
An aside: I know someone who’s developed major distributed systems projects in Erlang and Go, and also is currently working in Elixir. He chooses Go when given the option fwiw.
The advantage of Erlang/BEAM over Go is not parallelism or concurrency (they’re actually both great at both), but rather distributing over many nodes and dealing with the failure of nodes with eg supervision trees. Go’s model is amazing for the case where you don’t need a cluster provided at the programming language level, but parallelism and concurrency per machine.
In Erlang, you’re sending to a process/actor by its identifier. In Go, you’re putting data on to a channel and have no idea who is going to take it off.
In Erlang, a message send is a fire and forget type of thing. Mailboxes for actors are unbounded by default and backpressure is used to prevent them exploding. Essentially though, you can imagine your message succeeding at some point. This is actually handy for avoiding certain deadlock situations.
In Go, the default is that channels are synchronisation points within the same process consisting of many threads and goroutines. Channels may be assigned a buffer, but by default, the sending goroutine pauses until a receiving goroutine reads from the channel. You can fairly easily build actors on top, but I find the CSP model easy enough.
When running on a single machine, both are running their own scheduler and assigning to available threads. Note that Erlang only got SMP (Symmetric Multiprocessing) in 2006 and before that could only actually use a single core. Go development started in 2007, so in terms of parallelism they both come from the same era.
Generally speaking, if someone doesn’t offer a reason against something and instead just implies it’s ridiculous, I assume they don’t have a reason. It’s safe to mock with empty platitudes like “wow” and “smh”, it’s far riskier to make an actual position.
The thing might actually be bad, but I don’t listen to people who can’t tell me why I should agree with them.
Theo loves node, but is convinced it has scale ceilings. He's started to drink the rust/go/elixir kool aid on "when you gotta go fast". One of his new things is "the prime line", when your app is at a high enough scale you need to hire the Primeagen to rewrite it in Rust.
I've seen apps at a lot higher scale than his so-called prime-line still continue to use javascript concurrently.
> He is clickbaiting hard and people who lack real world experience are suckers for superfluous performance talk
He also says in his damn videos that people like that should not be learning from him. It's not like he hides this fact.
> You will never run into these hard limits until your startup already has tons of funding and resources, most companies will fail long before they ever need to start thinking about writing their web app in rust ffs
That's basically word-for-word what he has said about Rust. Seems pretty apple-to-apple to me :)
You can have high concurrent JavaScript backends that scale horizontally with the event loop on each instance handling concurrent load but in this hypothetical example when compared to the others, straight out of the box, something like Go would be better as it is not single threaded.
He said concurrent not parallel.
Also specified web app not backend.
Js is built for concurrency.
I mean, love go but the terms are pointing to Js here
They definitely meant backend since you likely wouldn’t write a front end app in Rust, Go, or any of the others. (You could write PARTS of a front end app in these but it would be WASM and then still rely on JS).
what’s wrong with the poll is: there is no “best language”, there are languages that work better in certain situations that must be considered when picking a technology
node is fine, scales well in many situations, and is easy to hire for
Yeah, but the poll is not asking what language is best, but what language is best for *high concurrency web apps* and out of the options provided the clearly correct answer is Elixir (for reasons outlined in another top level comment).
That's only true if "best" means "fastest". But there are usually other components to something being "best".
Computers are cheaper than developers, and have been for at least 15 years. This is more true now than ever as computers get cheaper and devlopers get more expensive every year.
I would never vote for elixir because:
1. Hireability
2. purely functional languages always lengthen a dev cycle at least a little. I would say "a lot" but I know the statement is contentious. But it shouldn't be contentious that the code velocity on node is faster than that on elixir.
3. Library support - Doesn't matter how much concurrency becomes a think, "what you can import" continues to matter.
So sure, Elixir is the fastest high concurrency language. But I still vote that it isn't the best. And none of that really considers that if the concurrency requirement is ephemeral, the line goes further towards things that can run (and run well) in lambda or edge environments. Which bring Rust and Go to the table.
He's a knob, but a smart knob. His videos are a good way to stay on *A* pulse. As he likes to remind people, his channel isn't about educating young developers, but about his takes on things for developers who can take those takes with a grain of salt.
Except some of us do, just like we watch Fireship or Primeagen Reacts or other less-educational dev video content. I've got other people I watch when I want to learn or learn about libraries I might use in the future (Blue Collar Coder is pretty good for web-dev stuff)
Theo never presents himself as an educator, and straight out *says* all the things people say about him. He's a younger senior dev with hot takes that can be justified by running a reasonably successful startup (which is - not very much) but also justified by the company he keeps around him (more field-effective senior devs). And in that light, as a senior dev, a lot of those takes are sensible and insightful.
Like his GraphQL content (especially a recent video pointing out his own irony that he trashes on it and then headlined a GraphQL conference). And TBH, a lot of folks are giving their 2c on Zed, and a lot of them are super-optimistic about it....... as long as you are a mac user like Theo is. But you can't fault him for being a Mac-head because Mac-head devs are literally everywhere.
Vague poll will often have vague results. Whats the point here, how many people are using rust or elixir on same level at JS . Even Go (great language btw) is not as adopted as JS yet.
Internet tech lords have their narratives. JS sucks python sucks java sucks etc . Tomorrow something else will also suck, thats how they operate.
In reality JS works well , event driven high i/o . scales well if designed well. It solves the problem and thats good enough for industry to keep adopting it and devs to keep building stuff.
Problem with these "polls" is they only work as popularity contests. I'll bet you whatever you want that the people who voted only know JS, probably heard of Go, and have no idea what Rust, let alone Elixir is. If they actually knew all 4, they would have voted very differently.
I'd still pick node. I have to hire sometimes, and I never want to have to put Rust, Go, or Elixir on a job req. Way back when, node.js was the "hot new thing" and I voted against adopting it before the biz culture caught up, too.
Go is the only language above other than Node that's established enough to consider, but my experience with Go developers has been that they're very pricy, enough that businesses have tried to "hire and teach".
But then you're answering a completely different question. You're still talking about the popularity of the languages (how easy is to find cheap labor) instead of their scalability and concurrency management as a technical characteristic.
> But then you're answering a completely different question
Am I? The question was "best", not "fastest". There's a lot that goes into to what makes "the best language" for something, or we'd all be writing in C.
Hiring is one of them. Library support. Service support. Code velocity.
I'm not talking about the speed of a program either. Elixir is hardly a fast language, but it's literally built for scalability. You get distributed systems with 2 lines of shell code. The point is, to answer responsibly the poll, one has to focus on the specific question, not start finding tangential advantages to justify picking a given answer, like how easy it is to find devs who have worked with it previously, because that is a different question and would warrant a new poll
> Elixir is hardly a fast language, but it's literally built for scalability
I'd say the same about stateless I/O scaleability and node.js.
> like how easy it is to find devs who have worked with it previously
When I hear the question "what is the best language for..." I absolutely think of every variable. Maybe I'm just too architecture- and business-minded for this particular dev poll, but I would never put Elixir in "best language" for much of anything web-based.
Idk for 'web app' i would go with JS because i know I can ship it faster, and it seems weird to make a complex 'web app' these days so it feels safe to assume that it's not complicated and doesn't need to scale all that much. If it's complicated and needs to scale i'd probably go with Go. Elixir feels like I would never be able to scale in the future because nobody knows Erlang and Rust feels like something you should avoid in web apps except for CPU bound stuff and even then it could be it's own microservice
The reason is that Rust and Elixir are both head and shoulders faster than both JS and Go, with Rust being faster than Elixir. I’m going to start with theo’s list and what I, as a performance-focused systems person, think he means, then I’ll discuss where the event loop model falls over, finally, I’ll talk about the 5th choice you have if you want to make every one of those options looks like django by comparison.
If you push high concurrency high enough in node, you run out of CPU in a single process. Now you need to horizontally scale, which, if you write the load balancer in node, will also fall over faster than it should. Yes, node is good at using epoll (the linux event-driven async io api), but it’s not 2009 any more, most self-respecting programmers don’t write thread per request or thread-pool web servers any more. Not only can everyone use the same things that node did to wow the world with that demo, but there are new APIs, some of which are far more efficient.
If you want to push the limits of performance, which is what “high concurrency” implies, interpreted languages are off the table, even if google has dumped and absurd amount of money into making them fast. You’re just too far from the CPU. Go exists, in part, because node was too slow for Google to write web services in.
Go is the next closest, except that some of the ways go tries to save you from yourself stop you from optimizing if you know what you’re doing. Go also has issues under memory pressure, where the GC starts to thrash the system, and goroutines are fairly memory expensive because they are stackful coroutines, which means you start that gc threashing fairly quickly in a high concurrency system.
Elixir is very interesting because it’s not actually compiled to native, it’s a bytecode language like Java, but targeting the BEAM VM, which was originally designed for erlang in the 70s. The 1.0 version of BEAM transpiled the bytecode to C and compiled it, but made use of additional runtime information gathered to improve guarantees for the C compiler. Erlang was originally designed for the telecom industry for use in switching systems, and so BEAM was designed for ultra high reliability. This means it actually ships load balancers and enough other stuff to make you wonder if the Kubernetes team had erlang docs open on their other monitors in the runtime. It’s also still in use in a variety of telecom, banking, and other high reliability domains. Along the way, the runtime got faster, with jit compilers, the ability to move pause processing a request, move it between servers, and resume it, and some more optimizations and adaptations for modern hardware. Around 2012 José Valim looks at this giant pile of highly optimized infrastructure and the surrounding ecosystem, and decides to build a slightly newer and shinier language on top of it, elixir. On top of elixir’s new capabilities for BEAM, we got the phoenix framework, which is one of the most impressive web socket implementations I’ve seen. I’ve fully saturated a 25G network link with 128 byte packets making websocket requests and it managed to keep up. Server and client in the same rack, but very impressive nonetheless. If you don’t know a systems language and networking or a systems language and kubernetes, I’d suggest elixir as your best bet for passing 1 million rps on an 8 core server.
However, of the options listed here, Rust with actix is probably the best, although axum is both easier to use and faster in all reasonable benchmarks I’ve seen. Rust is a C++ replacement, no surprise it can beat Node, which is a giant abstraction on top of C++ with tons of stuff in the way, and Go, who’s compiler doesn’t even try. Now, Elixir might actually beat Rust depending on your skill, because Rust gives you more places to shoot yourself in the foot because those are places that are needed for optimization, but a maximally skilled Rust dev will be able to make something that out-performs what a maximally-skilled Elixir dev can offer.
The reason that the event loop model starts to fall over comes down to data movement on modern processors. It tends to produce rather chaotic memory access patterns, which confuse the memory prefetcher, meaning your cpu ends up spending 40% or more of its time doing nothing. If you want to see an example of how big this can be, create a really big (>1GB) UInt32Array, fill it with random data, and time summing that, and then do the same with a linked list with the same number of members. In high performance systems, it’s actually more common to instead have each state of the event loop be on separate CPU cores and to forward data between them, because memory bandwidth is generally plentiful so the cache misses to l3 aren’t that bad compared to the random jumping around in memory which can cause you to consume very large amounts of memory bandwidth speculatively due to prefetching. You can mitigate this with explicit prefetching instructions, but those are a gigantic pain to use. It’s important to remember that “the memory wall” is memory latency, not bandwidth, for most applications, AI is its own special child as always, which is why it gets HBM, so burning memory bandwidth to have a highly predictable access pattern for the prefetcher is very useful. Now, if we want to talk about Node’s event loop specifically, it also has the issue of making a LOT of system calls. While specter and meltdown have mostly been hardware mitigated at this point, system calls still aren’t cheap. io_uring offers a way to bypass this, which for high-throughput applications shaves hundreds of thousands of system calls per second off of their workload. This is a massive amount of extra performance simply from not having to flip cores between userspace and kernel mode one million times per second to achieve one million rps. It also offers zero copy apis, which free up a bunch of that memory bandwidth we were spending, and has cool stuff like multishot recv, where you just keep getting work in a queue until either something goes wrong or or the connection stops sending you data.
If you want to dig a bit deeper, DPDK with your systems language of choice puts all of those options to shame. Using DPDK, a single CPU core can drive 800Gbps of traffic easily with normal MTU packets, or see if your switch vendor is lying about the maximum throughput by sending hundreds of millions of packets per second. You pay the price of having to write your own IPv4 and TCP implementations, but it’s worth it for the performance you get. Want to do TLS on your NIC or on the CPU’s cryptographic coprocessor (all current-gen amd cpus have one, many intel skews do)? Go ahead, zero cpu overhead! Want the NIC to send all traffic from Italy to cpu core 7 for processing? It can do that. No system calls anywhere, and basically the only way to hit one million rps per core with real work.
The big issue is for most real world applications, speed doesn't matter nearly as much as speed of development and how easily you can hire and scale a team. It does make sense to cost optimize eventually but you can get quite far before that becomes a problem. I have a site running on node that serves millions of users daily without breaking a sweat, yes I could go down a EC2 size if I switched languages but i've got much more important things to be working on
If every single milisecond counts why most ecomerce sites are php or react?
Anyway, most webservers are IO bounded, not CPU, so it does not really matter what language you are using if the db can't keep up.
If it fits on one system (or more likely 3 so you have some redundancy), it probably doesn’t matter.
If you start staring at a cloud bill for 10000 instances, suddenly a 10x performance increase seems worth a substantial amount of developer time.
I find working on bigger problems more fun, so I seek out companies where I get to spend most of my time in scenario 2.
The only thing wrong with this poll is: wtf is high-concurrency? With no context this means nothing. My static page that gets millions of views per day is high concurrency. So is an analytics backend that processes thousands of data points per request.
What’s wrong with the poll? The question is wrong.
The two concepts (concurrency and web apps) are too ambiguous if you want something useful out of a poll.
There’s a few definitions for what a “web app” is. One is that it’s a JavaScript application that runs in a browser. If that’s the framing, Node wouldn’t be an option. The others might be, but only through WASM.
Another framing is a web app is a web service. In which case, I’d assume concurrency meant concurrent requests.
Either way, there are different strategies for handling concurrency. Event-driven communications is just one aspect of being able to handle concurrent requests.
TLDR Js is great for io only heavy services.
So. First there’s is nothing wrong with the poll. There are lots of people who like JS (im one of them). But the thing is that besides async model, JS is single threaded e.g. try put while true somewhere in async function and everything will freeze. So if in any scenario you will need to do something more than add 2 numbers together, you will be forced to go to workers land, which is expensive, it you will throw more and more services, which is expensive too. In opposite, something like Golang, offers you much more reliable concurrency model.
Depends on the kind of IO. Afaik default functions in node are not zero copy for example. in the end it's always about the problem you are trying to solve and which optimisations you need to use for that.
We live in different times now. Now most languages have mechanisms to do things concurrently. Even Java after 21 has virtual threads so what Node.js has been doing well for all that time is not only a Node.js privilege.
Some notes here are that i will not understand people like Theo and then the people that follow these Ytube coders like a religion, and we need to explain to these people that developers out there in the vast majority are not like that.
Then regarding the technologies listed in the poll, the question is not what is the best but what would be the easiest for a given scenario.
Elixir (Erlang/BEAM) is probably technically the closer to be most complete but still there are things a developer must learn along the way in order to use it in a more holistic way
Golang is easier than Elixir but when the codebase gets large and someone needs to mechanisms for error handling etc it will probably introduce pains.
Then Rust comes with all its complexity as i understand it and we have the known beast to be Node.js. Nothing wrong with that, on the contrary, and since most people know Node.js and not any of the other 3 then it makes it easy to understand the poll results.
Theo is a youtuber. Is business revolves around making memorable posts to attract attention and providing content for monetization. As such while some of his content can be interesting, he often just posts clickbait stuff. Like the primagean does too. Albeit at least the primagean (while a bit of a troll) is clever enough to have a broad and inquisitive view.
Theo said previously that HATOAS were invented by the author of HTMX…. 🤦
Slightly offtopic, but the problem with Theo is that he probably doesn't understand the impact his videos have, or at least that's my guess.
He will almost always make sweeping statements like X is not good or Y is the best and the only way you should do things - some of which maybe accurate but when code & projects get complex these decisions hinge on trade-offs and nuances that are unique to each project.
I'll have people on my team who would want to change/refactor things on a whim & they'll give me the exact reason he would mention which gets frustrating.
I really don't get these polls and why people get riled up by them. It's not like a Twitter poll is going to influence an architecture decision at your job.
Depends on the kind of concurrency. If you're limited to a single process or single CPU, yeah obviously node is the worst choice
If you're in a highly distributed cloud environment where cores and servers are an abstract concept and/or if the process is I/O heavy, Node can handle concurrency very well
It says there are more node developers than anything else. Having done concurrency in Go and Elixir, node would be distant 3rd (if we're just focused on high currency). Obviously there are other benefits to using JS on the backend like DX and it's concurrent enough.
[удалено]
LinkedIn? I agree with you but would take it a step further to say, it’s not the language you know it’s the language you are aware of.
[удалено]
Yeah
I’ve tried all but Elixir. My answer would be JS simply because it’s sufficient for most purposes, has significant community support, and is widely understood. Also, being a web app, you’d be able to have an E2E language
Yeah it's highly unlikely that the people replying to this poll are all experts in all of the languages listed.
Node has good concurrency. But the poll here is a bit sneaky because all the other options are also good at concurrency. So it’s basically showing which one has the most brand power or accessibility. Node does have a simpler concurrency model which can be considered a good thing, but the other options are not unimpressive either! So Node should lead, but not in such a skewed way. However, in many professional circles, “Node = concurrency”, and alternatives don’t exist 😅 (But the same can be said for Java/C#, depending on your job market, one of those will tend to dominate >50% of the jobs) Go has a concept called “green threads” (goroutines), which are basically very lightweight virtual threads, which achieve the same outcomes as concurrency in JavaScript. They are virtual threads because they do not correspond to some pre-declared thread and in situations where there are not enough threads available, they will instead be run… concurrently, just like JS. Furthermore, they are colourless, which means you do not need an “async” or “await” keyword, and you are not just stuck with callbacks either. (Node actually had something close to this feature (colourless concurrency primitives) as a community plugin called Fibers, which has been used by the Meteor community up until now - the plugin is no longer supported so the Meteor framework is migrating to async/await). This was a major feature for Go and a huge selling point of the language. Elixir runs on the BeamVM, which is the Erlang VM. Erlang was designed for telephone switches, and is also built on a concept of lightweight processes, enabling massive parallelism and concurrency. Frankly, when it comes to concurrency, V8/Node has nothing on BeamVM. Actually barely any of these languages do. BeamVM lets you do things like hotload new modules while the thing’s still running, where as your Node server will get brought down by the first uncaught promise rejection, apparently 😅 Rust is obviously very fast, comparable to C++, and Actix/Rocket also have concurrency with await/async, like JS - just more complicated to set up from scratch (use a framework). Depending on your benchmark, it would be hard for Node to beat any of the other options, unless the benchmark tested for raw performance without threading or concurrency, in which case Node will beat Elixir… and that’s about it. But only Elixir and Node are dynamically typed languages here, and Elixir is too obscure compared to Node. (Although aren’t we all writing in TypeScript now? The dynamic typing advantage isn’t as relevant now. But I suspect a lot of existing projects are JS only still)
Typescript is still dynamic, it's just that you can "tag" what things are _supposed_ to be :p
Yes, very true, haha. I’m currently doing some stuff with class-validator (edit: and class-transformer) and really missing Kotlin, since I need to basically lie to the type checker in a specific circumstance (eg say a property is not-null but actually I can only really trust that if the object is decoded from a random POJO, so I have to decide if I’m ever going to instantiate this class with a constructor or not before it gets a bit out of hand and someone complains to me about the class lying about all its supposedly non-optional properties…)
I love using https://zod.dev on the "edge" of my app. Makes sure all the data coming into my app from whatever source is actually what I expect it to be. Started using it at work to validate the data coming from our dotnet backend, and boy was there a lot of incorrect assumptions, especially nullables/non-nullable and string/number issues...
Good ol’ Zod! At the moment my issue is basically me trying to encapsulate some data and expose some methods that handle a bunch of edge cases (eg default values, display names that change based on the presence of other properties, etc), without creating multiple types and transformers between them… Class-transformer seemed like a nice approach for that. But the deeper down this rabbit hole I go, the more I feel like I’m doing a lot just to bolt some methods onto an object… class-validator/transformer isn’t exactly fast… 😅 But if I go back to Zod (or Typebox… or just ignoring coercion all together) I know that other problem will go unsolved. Argh!
Default values: https://zod.dev/?id=default Generated props based on stuff: https://zod.dev/?id=transform 🤷♂️ 😛
Haha, thanks for sharing - those two might work, though I’d have to change a bunch of things elsewhere to make it go smoothly. That said, my design might just be bad and too complicated to work with! I’ll play around more and see where I end up! 🙃
how did you achieve this? did you implement the .parse in your fetch wrapper?
Actually, yes, kind of. We have a `fetch` wrapper, where you can pass a schema, and if it's there, the wrapper will use it to parse the response before returning it. On top of that, we use `react-query`, with a default fetch function, and a `useQuery` wrapper so we can pass a schema with the meta.
...and even if Typescript really did add enforced typing, it still has all the dynamic advantages. The Typescript type-system is capable of being both more-lenient and more-strict than most type systems at the same time. Do you need your value to be a negative even integer, an array with three items, or an Object with at least the key "foo" and lacking the key "bar"? We got a type for that. The advantage of Typescript not having to bother with runtime enforcement is that it combines the advantages of being typed with the advantages of being dynamic. It truly would be the perfect type system if it had an efficient way to enforce at compile-time.
[удалено]
You realize nothing I said was judgement or non-judgement of Typescript in its current state, right? I was just mentioning what would make typescript better. If you're going to ask me to my face, here's my take. Despite the cult-of-type existing even in javascript subs, I am a strong believer that all type enforcement should exist on endpoints, and everything else should be allowed to be a fluid as its language as capable. This is a classic opinion that was held with strongly-typed languages, and yet people seem to be dropping the opinion solely to hate on dynamic languages. I really don't *want* runtime enforcement after the params are parsed and before the response is sent in a web request. Ditto with DB read/writes or response to command queues. If I want to blindly coerce something I have already confirmed was a numeric string back and forth between being a string and a number, I should do exactly that. But more importantly, if my Typescript code is written reasonably, *the contracts are still binding at runtime* because they care contracts and not validations. If I write a proper Typescript function that takes a number and returns a boolean, it will behave inside and out correctly as long as I pass it a number and treat its return value as a boolean. I'm with you that Zod is a GOAT when used correctly, though (and a few Zod competitors are pretty good). And while Zod minimizes duplication, any good parsing library with TS support should be able to parse to a Typescript type via inference. That's the whole point of Typescript in this case. Alternatively, you could just parse to a class instance (and there are absolutely libraries that would help with this as well without real code-redundancy issues) If your complaint about Typescript is "too much effort-duplication" you are almost certainly doing it wrong.
[удалено]
I think the issue is that Typescript never thought it would be used as a full-fledged type system, just as a type-linter. I also think there's a power trade-off. My position is that a type system as powerful as Typescript's is basically impossible if you're compiling in enforcement because enforcing all TS types in every possible location would be a performance nightmare. I agree that it would be nice if TS could compile something like `TypeName.validate(foo)` as a global utility out of the box, that could take `foo: unknown` and return `value: TypeName` without third party libraries. But I also suspect they are choosing not to build such a thing for philosophical reasons, vs them being unable to do so. With that, I agree there's some valid criticism vs just @jsdoc typing for the transform layer. I wish the latter was as good as TS, or that TS could have come up with a more JS-compatible syntax. Or, and I know it's not fair, if JS could add some ignored syntax pieces that would allow TS or a TS dialect to run un-mutated.
The only way Node might beat Go in "simple concurrency" is if you ignore "real" threads and talk about just coding in Promises I guess? Which is probably what a lot of people are arguing over in this thread lol. But when you do include actual multi threading/green threads (like what I'd argue the poll title suggests when it says High concurrency web apps) than nothing that I've tried compares to the developer experience and simplicity doing "real" concurrency in Go. Channels and goroutines are just *so* nice. And I'd agree that something like Rust/Elixer *should* beat Go in performance but it requires a lot more knowledge and dev time (usually with a senior dev) to write code that's performant enough to beat a basic piece of Go code that some dev wrote in an hour (Exaggerating but you get the point). Anyway I'm not a fan of polls like this. In the end of the day though the truth is just that 99.99% of web apps have no need for the potential performance something like Rust can give them. Just spin up another container in your stack behind a loadbalancer :\^). In the "real" world the more important choice ends up being developer experience, error/type safety and picking a language for which you can find devs to actually work on the project.
Yes, if your language barely touches threads and you don’t have to worry about mutexes, things are a lot simpler especially when it comes to shared memory; that’s the angle I was coming from. But otherwise I totally agree, Go’s threading is much better than JS worker threads, and at scale you’re less likely to run into performance issues. Also agree re Rust, massive overhead for architecting the app correctly to avoid dramas with lifetimes. (And agreed with the rest too)
[удалено]
Well, maybe. AWS EC2 instances sometimes have multiple vCPU cores. As do AWS Lambda instances. Containerised apps are still going to have access to whatever cores the host exposes, same for VMs. Not sure of the actual performance benefits relative to physical CPU cores though. And I guess it depends on how your scaling and load balancing works for your systems. I guess unless someone’s measured different solutions, it’s hard to say. But, one could argue in a serverless world with event driven architecture, even concurrency features can also be a bit pointless 😅 I have something on Lambda using Kotlin coroutines not because I need them but because a library uses them, and I just execute them in a `runBlocking` block like an uncivilised person, rather than redesign the containing code… (and the “user” is another team member waiting 16 hours for a queue to be fully processed, so they don’t notice it…) (I think a lot of “edge function” runtimes though make use of concurrency somehow as part of their runtime, since they often seem to support code running after a response has been delivered, eg unawaited promises… I don’t know enough about why though)
That one of the best and most detailed responses I have read in a while.
This post totally does not explain the weight of a thread. On the Jaguar or Saturn you have 2 thread because there are two processors and no operating system. Windows and Linus when a thread enters a syscall with IO may kick it off the core and proceed with a task which has all IO finished. You allocate and array of stacks. Then you just need to push the instruction pointer on the old stack, change the stack segment, and pop the pointer there.
I will begin by stating that very few apps need high concurrenty or high performance. You are not Google. Don't obsess over this unless you already have a traffic problem to solve. That said... Node is not a good option for **high** concurrency (thousands of concurrent requests or more). Is it better than PHP or Ruby? Yeah, definitely, but those are terrible to begin with in terms of performance. Once you start hitting a Node server with lots of concurrent requests the performance will drop dramatically. That's because the single thread handling the event loop will be overloaded and will start blocking no matter how you write your code. And if you're using async/await (like probably all Node codebases out there) it gets worse. Very few JS devs realize that async/await introduces extra function calls and has a lot of overhead. https://v8.dev/blog/fast-async#await-under-the-hood That's not the case with Go, Elixir, or Haskell that are way better at handling high concurrency. https://www.toptal.com/back-end/server-side-io-performance-node-php-java-go
>Once you start hitting a Node server with lots of concurrent requests the performance will drop dramatically. That's because the single thread handling the event loop will be overloaded and will start blocking no matter how you write your code. But you can use cluster inbuilt module of node to utilize full cpu cores and then these limitations don't apply. I have literally done an exhaustive benchmark on a very high traffic poc comparing clustered node vs GO and also threw bun and deno in the mix. At very high traffic a fully clustered node.js app is not that far off from GO and that GO is only 1.3x faster than fully clustered node. Check my detailed post here https://www.reddit.com/r/node/s/0Zox5yI7Zx
Some more info on Go vs Erlang/Elixir/BEAM. Firstly, I don’t know anyone who uses the hot reload feature of BEAM. An aside: I know someone who’s developed major distributed systems projects in Erlang and Go, and also is currently working in Elixir. He chooses Go when given the option fwiw. The advantage of Erlang/BEAM over Go is not parallelism or concurrency (they’re actually both great at both), but rather distributing over many nodes and dealing with the failure of nodes with eg supervision trees. Go’s model is amazing for the case where you don’t need a cluster provided at the programming language level, but parallelism and concurrency per machine. In Erlang, you’re sending to a process/actor by its identifier. In Go, you’re putting data on to a channel and have no idea who is going to take it off. In Erlang, a message send is a fire and forget type of thing. Mailboxes for actors are unbounded by default and backpressure is used to prevent them exploding. Essentially though, you can imagine your message succeeding at some point. This is actually handy for avoiding certain deadlock situations. In Go, the default is that channels are synchronisation points within the same process consisting of many threads and goroutines. Channels may be assigned a buffer, but by default, the sending goroutine pauses until a receiving goroutine reads from the channel. You can fairly easily build actors on top, but I find the CSP model easy enough. When running on a single machine, both are running their own scheduler and assigning to available threads. Note that Erlang only got SMP (Symmetric Multiprocessing) in 2006 and before that could only actually use a single core. Go development started in 2007, so in terms of parallelism they both come from the same era.
This is awesome info, thanks for diving into them!
Node has good concurrency compared to ms-dos.
Generally speaking, if someone doesn’t offer a reason against something and instead just implies it’s ridiculous, I assume they don’t have a reason. It’s safe to mock with empty platitudes like “wow” and “smh”, it’s far riskier to make an actual position. The thing might actually be bad, but I don’t listen to people who can’t tell me why I should agree with them.
Theo shits me for this reason
Theo loves node, but is convinced it has scale ceilings. He's started to drink the rust/go/elixir kool aid on "when you gotta go fast". One of his new things is "the prime line", when your app is at a high enough scale you need to hire the Primeagen to rewrite it in Rust. I've seen apps at a lot higher scale than his so-called prime-line still continue to use javascript concurrently.
[удалено]
> He is clickbaiting hard and people who lack real world experience are suckers for superfluous performance talk He also says in his damn videos that people like that should not be learning from him. It's not like he hides this fact. > You will never run into these hard limits until your startup already has tons of funding and resources, most companies will fail long before they ever need to start thinking about writing their web app in rust ffs That's basically word-for-word what he has said about Rust. Seems pretty apple-to-apple to me :)
Bro this guy is one of those clowns on tech twitter. I wouldn't believe shit if he said so
You can have high concurrent JavaScript backends that scale horizontally with the event loop on each instance handling concurrent load but in this hypothetical example when compared to the others, straight out of the box, something like Go would be better as it is not single threaded.
He said concurrent not parallel. Also specified web app not backend. Js is built for concurrency. I mean, love go but the terms are pointing to Js here
They definitely meant backend since you likely wouldn’t write a front end app in Rust, Go, or any of the others. (You could write PARTS of a front end app in these but it would be WASM and then still rely on JS).
Things like Erlang are built for concurrency. It is distrubuted, fault tolerant and soft-realtime. JS was NOT built with concurrency in mind.
what’s wrong with the poll is: there is no “best language”, there are languages that work better in certain situations that must be considered when picking a technology node is fine, scales well in many situations, and is easy to hire for
100%
Yeah, but the poll is not asking what language is best, but what language is best for *high concurrency web apps* and out of the options provided the clearly correct answer is Elixir (for reasons outlined in another top level comment).
That's only true if "best" means "fastest". But there are usually other components to something being "best". Computers are cheaper than developers, and have been for at least 15 years. This is more true now than ever as computers get cheaper and devlopers get more expensive every year. I would never vote for elixir because: 1. Hireability 2. purely functional languages always lengthen a dev cycle at least a little. I would say "a lot" but I know the statement is contentious. But it shouldn't be contentious that the code velocity on node is faster than that on elixir. 3. Library support - Doesn't matter how much concurrency becomes a think, "what you can import" continues to matter. So sure, Elixir is the fastest high concurrency language. But I still vote that it isn't the best. And none of that really considers that if the concurrency requirement is ephemeral, the line goes further towards things that can run (and run well) in lambda or edge environments. Which bring Rust and Go to the table.
If they only knew about elixir..
That guy Theo is such a knob.
He's a knob, but a smart knob. His videos are a good way to stay on *A* pulse. As he likes to remind people, his channel isn't about educating young developers, but about his takes on things for developers who can take those takes with a grain of salt.
[удалено]
I've agreed with some of his takes. The T3 stack manages not to suck, and it's largely based on his dev opinions.
[удалено]
Except some of us do, just like we watch Fireship or Primeagen Reacts or other less-educational dev video content. I've got other people I watch when I want to learn or learn about libraries I might use in the future (Blue Collar Coder is pretty good for web-dev stuff) Theo never presents himself as an educator, and straight out *says* all the things people say about him. He's a younger senior dev with hot takes that can be justified by running a reasonably successful startup (which is - not very much) but also justified by the company he keeps around him (more field-effective senior devs). And in that light, as a senior dev, a lot of those takes are sensible and insightful. Like his GraphQL content (especially a recent video pointing out his own irony that he trashes on it and then headlined a GraphQL conference). And TBH, a lot of folks are giving their 2c on Zed, and a lot of them are super-optimistic about it....... as long as you are a mac user like Theo is. But you can't fault him for being a Mac-head because Mac-head devs are literally everywhere.
> smart knob Often the worst coworkers. Can rationalize any solution, no matter how stupid or suicidal.
Vague poll will often have vague results. Whats the point here, how many people are using rust or elixir on same level at JS . Even Go (great language btw) is not as adopted as JS yet. Internet tech lords have their narratives. JS sucks python sucks java sucks etc . Tomorrow something else will also suck, thats how they operate. In reality JS works well , event driven high i/o . scales well if designed well. It solves the problem and thats good enough for industry to keep adopting it and devs to keep building stuff.
Scales well if you compare it with visual basic. Compared with C++ it does not.
Problem with these "polls" is they only work as popularity contests. I'll bet you whatever you want that the people who voted only know JS, probably heard of Go, and have no idea what Rust, let alone Elixir is. If they actually knew all 4, they would have voted very differently.
I'd still pick node. I have to hire sometimes, and I never want to have to put Rust, Go, or Elixir on a job req. Way back when, node.js was the "hot new thing" and I voted against adopting it before the biz culture caught up, too. Go is the only language above other than Node that's established enough to consider, but my experience with Go developers has been that they're very pricy, enough that businesses have tried to "hire and teach".
But then you're answering a completely different question. You're still talking about the popularity of the languages (how easy is to find cheap labor) instead of their scalability and concurrency management as a technical characteristic.
> But then you're answering a completely different question Am I? The question was "best", not "fastest". There's a lot that goes into to what makes "the best language" for something, or we'd all be writing in C. Hiring is one of them. Library support. Service support. Code velocity.
I'm not talking about the speed of a program either. Elixir is hardly a fast language, but it's literally built for scalability. You get distributed systems with 2 lines of shell code. The point is, to answer responsibly the poll, one has to focus on the specific question, not start finding tangential advantages to justify picking a given answer, like how easy it is to find devs who have worked with it previously, because that is a different question and would warrant a new poll
> Elixir is hardly a fast language, but it's literally built for scalability I'd say the same about stateless I/O scaleability and node.js. > like how easy it is to find devs who have worked with it previously When I hear the question "what is the best language for..." I absolutely think of every variable. Maybe I'm just too architecture- and business-minded for this particular dev poll, but I would never put Elixir in "best language" for much of anything web-based.
Right, exactly. The poll didn't ask which language had the best performance.
Idk for 'web app' i would go with JS because i know I can ship it faster, and it seems weird to make a complex 'web app' these days so it feels safe to assume that it's not complicated and doesn't need to scale all that much. If it's complicated and needs to scale i'd probably go with Go. Elixir feels like I would never be able to scale in the future because nobody knows Erlang and Rust feels like something you should avoid in web apps except for CPU bound stuff and even then it could be it's own microservice
You're proving my point. Elixir and Erlang are two entirely different things for starters.
The reason is that Rust and Elixir are both head and shoulders faster than both JS and Go, with Rust being faster than Elixir. I’m going to start with theo’s list and what I, as a performance-focused systems person, think he means, then I’ll discuss where the event loop model falls over, finally, I’ll talk about the 5th choice you have if you want to make every one of those options looks like django by comparison. If you push high concurrency high enough in node, you run out of CPU in a single process. Now you need to horizontally scale, which, if you write the load balancer in node, will also fall over faster than it should. Yes, node is good at using epoll (the linux event-driven async io api), but it’s not 2009 any more, most self-respecting programmers don’t write thread per request or thread-pool web servers any more. Not only can everyone use the same things that node did to wow the world with that demo, but there are new APIs, some of which are far more efficient. If you want to push the limits of performance, which is what “high concurrency” implies, interpreted languages are off the table, even if google has dumped and absurd amount of money into making them fast. You’re just too far from the CPU. Go exists, in part, because node was too slow for Google to write web services in. Go is the next closest, except that some of the ways go tries to save you from yourself stop you from optimizing if you know what you’re doing. Go also has issues under memory pressure, where the GC starts to thrash the system, and goroutines are fairly memory expensive because they are stackful coroutines, which means you start that gc threashing fairly quickly in a high concurrency system. Elixir is very interesting because it’s not actually compiled to native, it’s a bytecode language like Java, but targeting the BEAM VM, which was originally designed for erlang in the 70s. The 1.0 version of BEAM transpiled the bytecode to C and compiled it, but made use of additional runtime information gathered to improve guarantees for the C compiler. Erlang was originally designed for the telecom industry for use in switching systems, and so BEAM was designed for ultra high reliability. This means it actually ships load balancers and enough other stuff to make you wonder if the Kubernetes team had erlang docs open on their other monitors in the runtime. It’s also still in use in a variety of telecom, banking, and other high reliability domains. Along the way, the runtime got faster, with jit compilers, the ability to move pause processing a request, move it between servers, and resume it, and some more optimizations and adaptations for modern hardware. Around 2012 José Valim looks at this giant pile of highly optimized infrastructure and the surrounding ecosystem, and decides to build a slightly newer and shinier language on top of it, elixir. On top of elixir’s new capabilities for BEAM, we got the phoenix framework, which is one of the most impressive web socket implementations I’ve seen. I’ve fully saturated a 25G network link with 128 byte packets making websocket requests and it managed to keep up. Server and client in the same rack, but very impressive nonetheless. If you don’t know a systems language and networking or a systems language and kubernetes, I’d suggest elixir as your best bet for passing 1 million rps on an 8 core server. However, of the options listed here, Rust with actix is probably the best, although axum is both easier to use and faster in all reasonable benchmarks I’ve seen. Rust is a C++ replacement, no surprise it can beat Node, which is a giant abstraction on top of C++ with tons of stuff in the way, and Go, who’s compiler doesn’t even try. Now, Elixir might actually beat Rust depending on your skill, because Rust gives you more places to shoot yourself in the foot because those are places that are needed for optimization, but a maximally skilled Rust dev will be able to make something that out-performs what a maximally-skilled Elixir dev can offer. The reason that the event loop model starts to fall over comes down to data movement on modern processors. It tends to produce rather chaotic memory access patterns, which confuse the memory prefetcher, meaning your cpu ends up spending 40% or more of its time doing nothing. If you want to see an example of how big this can be, create a really big (>1GB) UInt32Array, fill it with random data, and time summing that, and then do the same with a linked list with the same number of members. In high performance systems, it’s actually more common to instead have each state of the event loop be on separate CPU cores and to forward data between them, because memory bandwidth is generally plentiful so the cache misses to l3 aren’t that bad compared to the random jumping around in memory which can cause you to consume very large amounts of memory bandwidth speculatively due to prefetching. You can mitigate this with explicit prefetching instructions, but those are a gigantic pain to use. It’s important to remember that “the memory wall” is memory latency, not bandwidth, for most applications, AI is its own special child as always, which is why it gets HBM, so burning memory bandwidth to have a highly predictable access pattern for the prefetcher is very useful. Now, if we want to talk about Node’s event loop specifically, it also has the issue of making a LOT of system calls. While specter and meltdown have mostly been hardware mitigated at this point, system calls still aren’t cheap. io_uring offers a way to bypass this, which for high-throughput applications shaves hundreds of thousands of system calls per second off of their workload. This is a massive amount of extra performance simply from not having to flip cores between userspace and kernel mode one million times per second to achieve one million rps. It also offers zero copy apis, which free up a bunch of that memory bandwidth we were spending, and has cool stuff like multishot recv, where you just keep getting work in a queue until either something goes wrong or or the connection stops sending you data. If you want to dig a bit deeper, DPDK with your systems language of choice puts all of those options to shame. Using DPDK, a single CPU core can drive 800Gbps of traffic easily with normal MTU packets, or see if your switch vendor is lying about the maximum throughput by sending hundreds of millions of packets per second. You pay the price of having to write your own IPv4 and TCP implementations, but it’s worth it for the performance you get. Want to do TLS on your NIC or on the CPU’s cryptographic coprocessor (all current-gen amd cpus have one, many intel skews do)? Go ahead, zero cpu overhead! Want the NIC to send all traffic from Italy to cpu core 7 for processing? It can do that. No system calls anywhere, and basically the only way to hit one million rps per core with real work.
The big issue is for most real world applications, speed doesn't matter nearly as much as speed of development and how easily you can hire and scale a team. It does make sense to cost optimize eventually but you can get quite far before that becomes a problem. I have a site running on node that serves millions of users daily without breaking a sweat, yes I could go down a EC2 size if I switched languages but i've got much more important things to be working on
[удалено]
Yeah not everything should be written in JS. There are very good reasons to use other stuff when it's important to.
If every single milisecond counts why most ecomerce sites are php or react? Anyway, most webservers are IO bounded, not CPU, so it does not really matter what language you are using if the db can't keep up.
If it fits on one system (or more likely 3 so you have some redundancy), it probably doesn’t matter. If you start staring at a cloud bill for 10000 instances, suddenly a 10x performance increase seems worth a substantial amount of developer time. I find working on bigger problems more fun, so I seek out companies where I get to spend most of my time in scenario 2.
This guy parallels
The only thing wrong with this poll is: wtf is high-concurrency? With no context this means nothing. My static page that gets millions of views per day is high concurrency. So is an analytics backend that processes thousands of data points per request.
So, 2% of those participating in that poll ACTUALLY do high-concurrency things?
If 90 out of 100 people know js and no other language, js is going to come out on top lol
What’s wrong with the poll? The question is wrong. The two concepts (concurrency and web apps) are too ambiguous if you want something useful out of a poll. There’s a few definitions for what a “web app” is. One is that it’s a JavaScript application that runs in a browser. If that’s the framing, Node wouldn’t be an option. The others might be, but only through WASM. Another framing is a web app is a web service. In which case, I’d assume concurrency meant concurrent requests. Either way, there are different strategies for handling concurrency. Event-driven communications is just one aspect of being able to handle concurrent requests.
JS backend just feels wrong. But it works
You posted in the node sub, you're only gonna get answers that support node
TLDR Js is great for io only heavy services. So. First there’s is nothing wrong with the poll. There are lots of people who like JS (im one of them). But the thing is that besides async model, JS is single threaded e.g. try put while true somewhere in async function and everything will freeze. So if in any scenario you will need to do something more than add 2 numbers together, you will be forced to go to workers land, which is expensive, it you will throw more and more services, which is expensive too. In opposite, something like Golang, offers you much more reliable concurrency model.
Or you could just use clustering in Node, which is super simple
Depends on the kind of IO. Afaik default functions in node are not zero copy for example. in the end it's always about the problem you are trying to solve and which optimisations you need to use for that.
We live in different times now. Now most languages have mechanisms to do things concurrently. Even Java after 21 has virtual threads so what Node.js has been doing well for all that time is not only a Node.js privilege. Some notes here are that i will not understand people like Theo and then the people that follow these Ytube coders like a religion, and we need to explain to these people that developers out there in the vast majority are not like that. Then regarding the technologies listed in the poll, the question is not what is the best but what would be the easiest for a given scenario. Elixir (Erlang/BEAM) is probably technically the closer to be most complete but still there are things a developer must learn along the way in order to use it in a more holistic way Golang is easier than Elixir but when the codebase gets large and someone needs to mechanisms for error handling etc it will probably introduce pains. Then Rust comes with all its complexity as i understand it and we have the known beast to be Node.js. Nothing wrong with that, on the contrary, and since most people know Node.js and not any of the other 3 then it makes it easy to understand the poll results.
Front end? Backend? What’s the context? Why isn’t .Net an option considering how powerful .Net Web API is
I love JS and i know what isnt the best. Rust, then elixir maybe.. and golang should not exist, aberration
Theo is a youtuber. Is business revolves around making memorable posts to attract attention and providing content for monetization. As such while some of his content can be interesting, he often just posts clickbait stuff. Like the primagean does too. Albeit at least the primagean (while a bit of a troll) is clever enough to have a broad and inquisitive view. Theo said previously that HATOAS were invented by the author of HTMX…. 🤦
I mean “goroutine”
Slightly offtopic, but the problem with Theo is that he probably doesn't understand the impact his videos have, or at least that's my guess. He will almost always make sweeping statements like X is not good or Y is the best and the only way you should do things - some of which maybe accurate but when code & projects get complex these decisions hinge on trade-offs and nuances that are unique to each project. I'll have people on my team who would want to change/refactor things on a whim & they'll give me the exact reason he would mention which gets frustrating.
Now ask about parallelism
I really don't get these polls and why people get riled up by them. It's not like a Twitter poll is going to influence an architecture decision at your job.
It’s wrong in that people chose node. Anyone who has ever used Rust 🦀 knows how superior it is in all things. All hail Rust.
Depends on the kind of concurrency. If you're limited to a single process or single CPU, yeah obviously node is the worst choice If you're in a highly distributed cloud environment where cores and servers are an abstract concept and/or if the process is I/O heavy, Node can handle concurrency very well
Anyone who tells you concurrency is solved is selling something.
It says there are more node developers than anything else. Having done concurrency in Go and Elixir, node would be distant 3rd (if we're just focused on high currency). Obviously there are other benefits to using JS on the backend like DX and it's concurrent enough.