Syntax aside, the final implementation of this feels like, okay, well, you have access to an in-memory store that's outside of the GC and which works well for your use case here. I'd actually be more interested in further optimizations of the first approach, in-GC, which seem like they'd be more generalizable to other tasks.
The server implementation [0], for example, is 25 lines and handles a lot behind the scenes. Those 25 lines are all you need to define a process that can leverage all of the supervision and hot code reloading benefits offered by OTP. There's a lot going on, but it's mostly just pattern matching tuples and maps, and it only takes a few hours of messing around with Erlang or Elixir before that kind of thing stops looking so scary.
[0] https://github.com/sasa1977/erlangelist/blob/master/examples...
%__MODULE__{buffer | size: buffer.size + 1, queue: :queue.in(item, buffer.queue)}
Or worse:
{:ok, {
:ets.lookup_element(buffer.ets, pull_index, 2),
%__MODULE__{buffer |
size: buffer.size - 1,
pull_index: rem(pull_index + 1, buffer.max_size)
}
}}
Would you care to elaborate which parts you consider to be "gobbledegook"? The code supplied is just a few lines of code.
I don't know how familiar are you with the language, but the magical aspect of it will quickly disappear once your learn a few OTP patterns.
I personally started initially with Erlang, but when I discovered Elixir, I switched, as I found it way more pleasurable.
Python and Elixir are actually the only two languages that make me happy when writing code, and I've tried quite a few of them, from C all the way to Haskell.
I thought the same thing once, until I actually sat down and tried to learn Erlang. It turns out that a lot of the decisions that I originally thought were asinine, actually make a lot of sense.
Line terminators for example (, ; .) tend to receive a lot of flak, but they really aren't as crazy as they first seem. Commas come after normal lines of code (you can read them as and), semicolons come at the end of clauses in if or case statements (and you can read them as or), and periods mark the end of a function. It's a little more verbose than something like Javascript or Ruby, but it really isn't as confusing as critics tend to claim!
thanks
The thing that seemed magical about Erlang was how efficient it's syntax managed to be without being ambiguous. In a weekend I picked up the syntax, and in days I was being productive with it.
I've heard Elixir described as "Rubyfied-Erlang" which would explain why I don't particularly love it, since I don't love Ruby syntax (and I secretly harbor a tiny bit of resentment for Elixir for taking off and essentially cementing Erlang's place outside the spotlight), but it's not bad either and doesn't add that much syntax.
And it's not like the syntax of C-like languages hasn't evolved towards something that looks "different" anyways. Lambdas + Rx/Promises + Streams practically looks like it's own language in most C-like languages...
It covers numerous things: from the basics, all the way to OTP, meta-programming, and even certain popular libraries such as Plug and Ecto.