Earlier quoted context omitted.
Yep, modern embedded (e.g. rPi and other Intel-based devices). I suppose there would be limited connections from each device, but many devices.
It’s nice in that the actor model provides good concurrency. One great benefit is that each "device" or connection essentially runs as a single sequential process. That makes data stream processing pretty nice on embedded. Like processing serial port data. Though it sounds like you almost just want a job queue, which would be pretty easy but not really benefit from actor model. One example where a Nerves setup would…
Which companies are using Erlang, and why?
201–204 of 204 posts
Re: Which companies are using Erlang, and why?
#202Earlier quoted context omitted.
That system was the backend of the functionality currently known as Facebook Messenger, not WhatsApp. One might note, snidely [1], that three-four years after freezing development of an Erlang-based messaging system, starving maintenance work on that system of engineering effort, devoting massive engineering resources to a from-scratch C++ rewrite, and in the meantime blaming the language for relatively minor system…
> after freezing development of an Erlang-based messaging system... > Facebook plowed $19B into the acquisition of an Erlang-based messaging system. They didn't care what it was written in. They would've spent it on Whatsapp even it was written in PHP (like Slack). They paid for users and market penetration.
Re: Which companies are using Erlang, and why?
#203Earlier quoted context omitted.
why wouldn't you just use rabbit rpms that depend on the exact correct versions of erlang? aka els-erlang https://www.erlang-solutions.com/resources/download.html Linux distros have always been terrible places to find reliable packages.
He he. And then you have people complaining that you're a "bad OSS citizen"...
Re: Which companies are using Erlang, and why?
#204Earlier quoted context omitted.
It’s nice in that the actor model provides good concurrency. One great benefit is that each "device" or connection essentially runs as a single sequential process. That makes data stream processing pretty nice on embedded. Like processing serial port data. Though it sounds like you almost just want a job queue, which would be pretty easy but not really benefit from actor model. One example where a Nerves setup would…
For sure, serial data is a factor. I need to dig into the support of GPIO and other serial interfaces (e.g. USB) - but that's a great point. The image distro model is really cool, and need to evaluate that further as well.
PS: I enjoy writing streaming code in Elixir (vs more procedural or OO methods). This is a snippet I use to decode a SLIP encoded binary UART stream with an CRC check:
Stream.repeatedly(fn -> receive_data_packet(timeout) end)
|> Stream.transform(>, &frame_splitter(&1, &2, {separator, max_buffer}))
|> Stream.map(&decode_slip(&1))
|> Stream.map(&frame_header(&1))
|> Stream.reject(&( &1[:code] == -1))
|> Stream.each(fn x -> if !x[:crc_check] do Logger.error("parser crc error: #{inspect x}") end end)
|> Stream.reject(&( &1[:crc_check] == false))
...