31–40 of 58 posts
Earlier quoted context omitted.
You may be thinking of some recent round of publicity for BEAM, but BEAM is a bit older than JavaScript.
Haha. I guess the BEAM people can nod down at me with contempt and I nod down at the Elixir folks.
Earlier quoted context omitted.
I spreadsheeted out how many T424 die per Apple M2 (TSMC 3nm process) - that's 400,000 CPUs (about a 600x600 grid) at say 1GIPs each - so 400 PIPS per M2 die size. Thats for 32 bit integer math - Inmos also had a 16 bit datapath, but these days you would probably up the RAM per CPU (8k, 16k?) and stick with 32-bit datapath, but add 8-,16-bit FP support. Happy to help with any VC pitches!
David May and his various PhD students over the years have retried this pitch repeatedly. And Graphcore had a related architecture. Unfortunately, while it’s great in theory, in practice the performance overall is miles off existing systems running existing code. There is no commercially feasible way that we’ve yet found to build a software ecosystem where all-new code has to be written just for this special theoreti…
I think the practitioner angle is what makes interesting. Too many BEAM advocacy posts are theoretical. I would push back on the "shared state with locks vs isolated state with message passing" framing. Both approaches model concurrency as execution that needs coordination. Switching from locks to mailboxes changes the syntax of failure, not the structure. A mailbox is still a shared mutable queue between sender and…
In practice you'll likely push stuff through Oban, Phoenix PubSub or some other convenience library that gives you some opinions and best practices. It really lowers the bar for building concurrent systems.
I love the idea of Erlang (and by association Elixir), OTP, BEAM... In practice? Urgh. The live is all so cerebral and theoretical and I'm certain the right people know how to implement it for the right tasks in the right way and it screams along. But as yet no one has been able to give me an incling of how it would work well for me. I read learn you some Erlang for great good quite a while back and loved the idea. B…
Erlang is weird, it helps if you have some Lisp and Prolog background, but for a while it might get in the way of learning how OTP works.
Very interesting. Reading this made me think of occam on the transputer: concurrent lightweight processes, message passing, dedicated memory! I spent some happy years in that world. Perhaps I should look at BEAM and see what work comes along?
BEAM/OTP are great, but do impose an exotic language onto the user. Most programs and solutions of today aren't Erlang-based.
what would it look like if you didn't need concurrency at all - would simply having a step by step process enough e.g using DAGs
what would it look like if by not letting it crash - you can simply redo the process like a Traditional RDBMS does i.e ACID
they're domains where OTP / BEAM are useful - but for majority of business cases NO