3 ms·
> Moving web sockets elsewhere are pretty simple regardless of whether you're using Erlang/OTP or not because it's a frontal layer. It is supposed to be easy.
by majidazimi 9y ago
> Moving web sockets elsewhere are pretty simple regardless of whether you're using Erlang/OTP or not because it's a frontal layer.
It is supposed to be easy. But they are not using language agnostic messaging. Instead they rely on Erlang distribution protocol. This is what makes it difficult to integrate.
> what would be the purpose behind that decision?
1. To achieve composability. I can replace one web socket server with a C++ implementation to see if I can handle 10 million connections per server. If I fucked it up return back to Erlang implementation otherwise fuck BEAM. I'm moving to native code. The beauty of it is that I can do it one step at a time. Even I can implement web socket layer in multiple languages and experiment all possible options in production and no one even notices it.
2. I don't have to pay for 20 Erlang guys who are mostly senior devs. Get 5 of them to write the core and the rest of the team NodeJS guys.
- mononcqc 9y agoYou're acting like the distribution and serialization formats of Erlang are not open or documented. If you're going for your C++ layer, try https://github.com/saleyn/eixx https://github.com/saleyn/eixx for example.
- majidazimi 9y agoA typical answer from open source guys on HN. The last commit was somewhere around Oct 12, 2016 and the developer didn't have time to fix an issue from Nov 9, 2014. Grow up man. We are talking about seamless/painless integration.
- mononcqc 9y agoyou're talking about undoing an architecture that lifts the benefits of an entire platform having done the work for you, in order to pick one that is probably easier to migrate to in the future. You prefer doing all the work mostly from scratch, upfront and straight away, instead of having to maybe adapt a library later if you actually need to migrate. I think your cost analysis is off.