Comment by rdtsc
> This is the question I was answering and I gave you an example then you proceeded to say there is no overhead Erlangs process model, which now you admit exists
But that's not what NodeRed-Erlang does. The author is confirming it one one of the sibling comments. You invented some new type of workload, were all clients have to access the same heap concurrently and telling the author to rewrite everything in Rust. But that's your use-case, not the the one we're discussion. My use case is not that either.
> Geez this is tough crowd, first Erlang has no overhead, then its well that nots whats its good at, which I said. Then its well those are specific workloads, yeah serving little messages to a million clients is a specific workload too.
The application in this case fits Erlang perfectly. You're the one who introduced a new type of a use case - when you need to concurrently process the same video or audio and arguing that Erlang is not good for it. Yeah, we agree, it's not good for that, use something else, Rust, C etc. It's like we're talking about trains and you're saying, don't use trains, they can't fly, what if you have to cross the ocean or something like.
> You invented some new type of workload, were all clients have to access the same heap concurrently and telling the author to rewrite everything in Rust. But that's your use-case, not the the one we're discussion. My use case is not that either.
Image processing or video or audio or parsing or working with large amount of data in a multithreaded way is not a new kind of workload its a very common one.
It was stated by the OP that they wished it would have been done in a more standard multithreaded language like rust. You asked why, I gave you an example, you said it wasn't true that there is no overhead to Erlang, I gave further details, you then pivoted to thats not the use case. How do you know what oersted's use case is?
>It's like we're talking about trains and you're saying, don't use trains, they can't fly, what if you have to cross the ocean or something like.
It's more like you asked when would you not use a train? I answered when you need to go across an ocean and planes can do both what trains and boats do just at higher cost but at greater speed.
Erlang is great at specific things, standard multithreaded shared heap runtimes are good at everything they just might take more effort and care to do the things Erlang can do, but they will perform better than Erlang. Erlang can technically do anything since its Turing complete but it will perform unacceptably at many standard workloads just like a train could go across an ocean if put on a barge and towed.