> Rewriting it in Rust doesn't magically make it use no CPU!
obviously, but it does'r mean certain HEAVY algorithms wont benefit from judicious use of mutability and getting closer to the metal. you can't always fan out your computation and sometimes you need to get the result out to the user fast. even if you dont NEED to, the user appreciates an experience that feels snappy.
> CPU usage becomes an architectural concern at a certain point,
depends what you're trying to do and the value of getting it done fast. Otherwise we'd never use lower level languges. python calls out to c for certain things for a reason.
> Even the fastest languages can't make e.g. a game server scale the way a CRUD app does.
true a slow language isn't going to be much worse than fast language for io, but a high performance system might be able to update that game state faster and passit back to the controller in a slow language that can take care of sending teh data out.
> CPU usage becomes an architectural concern at a certain point, not a language concern
thats a blunt assertion. I can think of plenty of use cases where its just as much a language concern. There's a reason dropbox and figma wrote performance critical parts of their system in rust.
for reference: I built my entire startup in elixir and have managed to get by using just elixir, judicious use of architecture and writing really tight sql queries. Yes, there are certain performance bottlenecks that can be addressed with architecture but to say that applies to all cases is foolish.
Luckily, our roadmap won't need any of these high cpu demands for ahwile. at some point, we want to use some sort of machine learning. There is just no way you're going to scale up large scale matrix operations over large data sets in pure elixir. elixir is copy om wrote and evaluate by value. Great ergonomics for day to day work but they have an overhead that is unacceptable under certain contexts. One being matrix operations. Luckily we have Nx which calls out to low level c code. Otheriwse we'd be using rust or python calling out to tensor-flow on a separate microservice.
Right, but what would happen if you started to saturate your servers' CPU processing spending all your time in highly-optimised Nx routines? You'd start looking to solutions like the OP in order to scale that CPU-bound work.
I think we might be arguing past each other in more-or-less-agreement so I might bow out at this point.
obviously, but it does'r mean certain HEAVY algorithms wont benefit from judicious use of mutability and getting closer to the metal. you can't always fan out your computation and sometimes you need to get the result out to the user fast. even if you dont NEED to, the user appreciates an experience that feels snappy.
> CPU usage becomes an architectural concern at a certain point,
depends what you're trying to do and the value of getting it done fast. Otherwise we'd never use lower level languges. python calls out to c for certain things for a reason.
> Even the fastest languages can't make e.g. a game server scale the way a CRUD app does.
true a slow language isn't going to be much worse than fast language for io, but a high performance system might be able to update that game state faster and passit back to the controller in a slow language that can take care of sending teh data out.
> CPU usage becomes an architectural concern at a certain point, not a language concern
thats a blunt assertion. I can think of plenty of use cases where its just as much a language concern. There's a reason dropbox and figma wrote performance critical parts of their system in rust.
for reference: I built my entire startup in elixir and have managed to get by using just elixir, judicious use of architecture and writing really tight sql queries. Yes, there are certain performance bottlenecks that can be addressed with architecture but to say that applies to all cases is foolish.
Luckily, our roadmap won't need any of these high cpu demands for ahwile. at some point, we want to use some sort of machine learning. There is just no way you're going to scale up large scale matrix operations over large data sets in pure elixir. elixir is copy om wrote and evaluate by value. Great ergonomics for day to day work but they have an overhead that is unacceptable under certain contexts. One being matrix operations. Luckily we have Nx which calls out to low level c code. Otheriwse we'd be using rust or python calling out to tensor-flow on a separate microservice.