20 ms·

Comments like this always confuse me as object oriented programs riddled with state are much harder to reason about to me.

sph 5mo ago
I'm working on a game engine right now (written in object oriented language, of course) and I keep itching to design a compiled functional language for games, because state spread in thousand of objects, eldritch class hierarchies, are complete hell. Once you taste Elixir/Erlang, there is no going back to the madness.
- isityettime 5mo ago
  > I keep itching to design a compiled functional language for games Jank wants to be this, right? IIRC its author and chief maintainer was a game dev before he dedicated himself to the language. https://jank-lang.org/ https://jank-lang.org/ Maybe porting your engine would be a great way to prove out Jank 1.0 when it arrives ;)
  - sph 5mo ago
    Thanks for the pointer, never heard of this!
    - isityettime 5mo ago
      Awesome! Maybe it's even a language you could enjoy contributing to. :D
sevenzero 5mo ago
The confusing state riddling here happens in the background as your whole app basically is a state. The thing that really throws me off with Elixir is having to handle (possibly) hundreds of thousands of processes. Doing this correctly seemed impossible to learn for me.
- sph 5mo ago
  It's not like you're dealing with hundreds of thousands of ad-hoc processes. If you're writing a web server, for example, each of these processes might simply be a client connection and they all operate the same. The fact that there are 2 or 100,000 is only a problem for the BEAM scheduler. Sounds like there is some foundational knowledge of Elixir that you miss and everything seems more confusing than it should be. To me writing a 'server' in Elixir is orders of magnitude easier than doing it in Python, Rust or C++. As someone else suggested, bring your concerns to the Elixir Forum and surely someone will clarify them for you
- jimbokun 5mo ago
  But would be even harder to wrap your head around if you tried to implement similar capabilities in Java.
- klibertp 5mo ago
  > Elixir is having to handle (possibly) hundreds of thousands of processes OMG, why? Why would you ever have so many processes? All of them at the same time? Are you going to animate a 3D scene and run a process for each vertex, or something? No, I mean, if you're WhatsApp - across all nodes - then somehow maybe yes? At scale. But in normal code, slicing workloads too thinly is counterproductive, and having even tens of thousands of processes is a sign that you're slicing it way too thin. Message passing between processes is cheap, but not free. Schedulers do a good job, but rarely have more than 16 cores to work with. And so on. You can have that many processes if you want, to be sure. But if you're struggling with it, why would you want it? Reading your comments in this thread, I have a feeling you just didn't spend enough time reflecting on how you want to use Elixir. In effect, you also failed to consider how exactly you should learn it. For example: Elixir is a perfectly capable procedural language. Start by writing CLI tools, without spawning any processes at all. Then try to parallelize their processing. If the tool accepts a list of files as arguments, use a `Task` to compute return values for each file. Tasks are processes, but with a particular contract that simplifies their usage. Later, you can experiment with error handling and supervision by putting the tasks under a supervisor. And so on. You go from the familiar to the less familiar, with a useful, working tool every step of the way.

sph 5mo ago

I'm working on a game engine right now (written in object oriented language, of course) and I keep itching to design a compiled functional language for games, because state spread in thousand of objects, eldritch class hierarchies, are complete hell. Once you taste Elixir/Erlang, there is no going back to the madness.

isityettime 5mo ago
> I keep itching to design a compiled functional language for games Jank wants to be this, right? IIRC its author and chief maintainer was a game dev before he dedicated himself to the language. https://jank-lang.org/ https://jank-lang.org/ Maybe porting your engine would be a great way to prove out Jank 1.0 when it arrives ;)
- sph 5mo ago
  Thanks for the pointer, never heard of this!
  - isityettime 5mo ago
    Awesome! Maybe it's even a language you could enjoy contributing to. :D

sevenzero 5mo ago

The confusing state riddling here happens in the background as your whole app basically is a state. The thing that really throws me off with Elixir is having to handle (possibly) hundreds of thousands of processes. Doing this correctly seemed impossible to learn for me.

sph 5mo ago
It's not like you're dealing with hundreds of thousands of ad-hoc processes. If you're writing a web server, for example, each of these processes might simply be a client connection and they all operate the same. The fact that there are 2 or 100,000 is only a problem for the BEAM scheduler. Sounds like there is some foundational knowledge of Elixir that you miss and everything seems more confusing than it should be. To me writing a 'server' in Elixir is orders of magnitude easier than doing it in Python, Rust or C++. As someone else suggested, bring your concerns to the Elixir Forum and surely someone will clarify them for you
jimbokun 5mo ago
But would be even harder to wrap your head around if you tried to implement similar capabilities in Java.
klibertp 5mo ago
> Elixir is having to handle (possibly) hundreds of thousands of processes OMG, why? Why would you ever have so many processes? All of them at the same time? Are you going to animate a 3D scene and run a process for each vertex, or something? No, I mean, if you're WhatsApp - across all nodes - then somehow maybe yes? At scale. But in normal code, slicing workloads too thinly is counterproductive, and having even tens of thousands of processes is a sign that you're slicing it way too thin. Message passing between processes is cheap, but not free. Schedulers do a good job, but rarely have more than 16 cores to work with. And so on. You can have that many processes if you want, to be sure. But if you're struggling with it, why would you want it? Reading your comments in this thread, I have a feeling you just didn't spend enough time reflecting on how you want to use Elixir. In effect, you also failed to consider how exactly you should learn it. For example: Elixir is a perfectly capable procedural language. Start by writing CLI tools, without spawning any processes at all. Then try to parallelize their processing. If the tool accepts a list of files as arguments, use a `Task` to compute return values for each file. Tasks are processes, but with a particular contract that simplifies their usage. Later, you can experiment with error handling and supervision by putting the tasks under a supervisor. And so on. You go from the familiar to the less familiar, with a useful, working tool every step of the way.