4 ms·
Another interesting thing is that the farther you go from the CPU cache, the more copies of data and the more extra processing you have to do. Think of how man
by Xeoncross 4y ago
Another interesting thing is that the farther you go from the CPU cache, the more copies of data and the more extra processing you have to do.
Think of how many copies of the data you need (and how much processing it takes) to use:
- a L3 CPU cache.
- a 16GB RAM cache.
- an embedded C/Rust/Go SQLite database.
- a distributed, fault tolerant Cassandra/elastic cache cluster.
You can literally solve the same typeahead/autocomplete/user lookup/session management/etc.. features using the last three of these - but the CPU cycle, memory usage and latency costs (plus complexity) explodes.
I'm always impressed by people that handle 1 million connections on a single box while I'm watching teams trying to handle a thousand connections with a whole fleet of infrastructure and caching layers.
Then again, part of the issue is the wrong language and wrong designs patterns. Highly optimized Rust and Go someone obsessed on all weekend is going to shred your team's unoptimized vanilla Ruby or Java install you didn't even have time to write tests for and don't honestly care about because you're too worried about being laid off.
- hot_gril 4y agoFor use cases with simple business logic and high throughput, yeah the optimized Rust, maybe on your own hardware, makes sense. Tons of cloud customers running NodeJS or Java stuff don't fit this. Maybe they have a few optimized pieces with high throughput and majority unoptimized where resource usage is low either way. Or they might be ok spending 10X compute resources even on something high-throughput because landing new features/products matters way more than optimizing a small part of their budget. Like, there are businesses renting big 8-socket servers with TBs of RAM to support some monstrous corporate DB that can only run on a single machine.
- Xeoncross 4y agoYeah its kind of sad that we still have to use node and java with better options out there. Don't get me wrong, Typescript, Deno, JVM, etc.. are all doing their best to right those ships, but it's would still be better to just scrap that stuff for a better foundation. That is what everyone knows, so that is what's taught, so that is what everyone knows, so that is what's taught. I'd gladly onboard projects to Erlang, Rust, Zig, Go, or anything modern. Would save our planet so much wasted energy.
- moomoo11 4y agoThe problem is that our industry democratized to the point that people want to hire the cheapest resources who can ship something. A mediocre node or ruby developer costs peanuts to hire compared to one who is mediocre at Go or Erlang. Btw.. If you hire a mediocre go or Erlang developer you’re fucked. For IO bound work there’s not much difference between a service built with Go or Node. It’s really when you need services that have soft/hard real-time requirements or continuous processing requirements that imo it’s necessary to hire the right people for the right stuff. For anyone else who is making a web platform that doesn’t have much complex backend processing, they can just use ruby or node. Personally I use Go for all backend tasks and node for any one off scripting work. Go spits out a binary I can run on any Linux based system. Node scripts are easy to write and I use them for fixing issues or for simple single responsibility tasks.
- hot_gril 4y ago> The problem is that our industry democratized to the point that people want to hire the cheapest resources who can ship something This doesn't sound like a problem to me.
- hot_gril 4y agoDoing high-level stuff in those languages takes longer even if you know what you're doing, though.
- invalidname 4y agoJVM can do 1M concurrent on a single machine. Don't lump it with Ruby please. This will be even easier with Loom as we won't need asynchronous APIs.