I don’t disagree but this is mostly a fixable problem. Doesn’t have to be Elixir per se. Have you seen how insanely fast Rust channels are, for example? You can send 20000 messages and the user would not have started blinking yet.
dimitarvp
derek-zhou
If speed/efficiency is not a concern then it might be simpler to give up on the whole idea of having GUI widgets with a life cycle, and go with a full immediate mode style of GUI programming. Many games are done this way.
0
LostKobrakai
It’s weird that with all the speed ups in tech we get all this GPU stuff still happens to be a huge leaky abstraction in so far that it even leaks into decisions about programming paradime. I recently watched https://www.youtube.com/watch?v=TAQ7yBLRZ3U which was quite an interesting talk on that topic by someone having built a react like system for GPU rendering.
3
gregvaughn
This subject makes me think of BeOS. Granted, it never was mainstream, however, it was using an actor model on 90’s hardware. It was quite impressive for its resilience and concurrency. I didn’t know BEAM at the time, but now I see huge parallels. I’m sure Erlang was an inspiration.
2
derek-zhou
Really? Did it use green threads with per-thread heaps, like Erlang? I thought it was using some kind of co-routine backed by c macros.
0
gregvaughn
Now that you ask for the details, I’m not certain. I was a novice programmer working in interpreted languages at the time. I bought a PowerPC Mac Clone and could dual boot classic MacOS and BeOS. I read articles about the BeOS architecture, and firsthand experienced how much it could do with the same hardware than MacOS could.
1
a-maze-d
derek-zhou
From what I can see here:
Seems to be implemented with green threads sharing a heap. Every window is a separate thread running its own run loop waiting for messages. So, it is using the actor model on the per-window level, not on a per-widget level. Very neat.
2
Taun
I find this a very baffling topic in that, on the one hand I have written responsive (in the old “responds quickly” sense rather than responsive web page sense) GUIs on computers with only 1MB of RAM and a 16 MHz i386. Smalltalk also had a very responsive GUI for this platform. I think one could definitely implement a responsive BEAM based GUI for a modern machine. It should even be possible with a lowly SBC.
The baffling part is again, why would you want to? Apple has amazingly well thought out, easy to use desktop GUI libraries that have been tested and improved for 40 years. They started life as NextStep and were based on Smalltalk. Meanwhile, Linux desktops have yet to become popular. It might be interesting for an SBC. But there is already Phoenix.
I understand it’s frequently the things where everyone goes “why would you do that” which “surprisingly” become really successful. I like the concept. But I am blind to the value.
Now, what about the BEAM on GPUs?? Not ML but the actual BEAM? And able to use the separate GPU cores for separate processes just like a multi-core CPU? Sort of like k8s but the fabric is the GPU cores.?
1
d-led
this seems to not have been mentioned but Wings3D is a desktop app written mostly in Erlang. See a post from 2009.
6