5 ms·

> Elixir is layered, making it easy to learn and master. You can get pretty far with Phoenix without ever understanding (or even knowing about) the more fundame

> Elixir is layered, making it easy to learn and master. You can get pretty far with Phoenix without ever understanding (or even knowing about) the more fundamental building blocks or the runtime. In large part, this is because of its ruby-inspired syntax. You'll have to adjust to immutability, but that's pretty much it. This is my main problem with elixir. Even for senior developers it's hard to know how the building blocks and runtime works and since all abstractions are leaky, you'll end up with mysterious issues that only make sense once you understand all the layers. And in case of elixir there are lots.

dynamite-ready 6y ago
Elixir's syntax is very nice, but at it's core, the Elixir/Erlang/OTP Actor model thing is quite different to other forms of programming.
emadb 6y ago
Actually Elixir and Erlang are at the same level: they both run on the BEAM. So you need to know the BEAM that it is like a virtual machine that act differently from what we are used to (JVM, .NET). Once you learn the BEAM everything become clear and easy to use. IMHO Process state isolation and message passing are the core, that's not so difficult to learn and apply.
- discordianfish 6y ago
  Yes, you need to learn the BEAM VM which makes it not easy to learn. It still might be worth it, but now you need to understand Elixir, Erlang, BEAM - additionally to your OS's API. All I can offer are anecdotes but I've worked at one company with a sizeable rabbitmq cluster where we were fortunate enough to have a guy in a different team who was a BEAM maintainer in his free time. He was the only one able to debug issues (mostly around unexpected memory usage). At another place, we had some in house elixir services. Developers were very happy and productive with it, but we also ran into unexpected memory usage and crashes due to that and to the day their root cause are unclear, even after adding detailed telemetry to monitor process counts and memory profiles. I guess I have a general issue with VM based languages, but that might be due to the fact that I spend more time debugging issues than writing software and I appreciate the common libc/syscall api used in VM-less languages.
  - dnautics 6y ago
    > unexpected memory usage Number one cause of hard-to-track memory usage in elixir, especially with services that parse JSON. Someone is ingesting JSON and caching a snippet of the JSON in an ets table, which means the entire JSON is never GC'd.
    - toast0 6y ago
      This is pretty easy to identify and fix once you know about it and how to look. To identify: erlang:memory() shows unexpectedly large word count for binaries. Crawl all your ets tables and look if referenced_byte_size(Binary) is significantly larger than size(Binary) (you need to check the keys as well as the values, and you'll need to write something to crawl through your complex values, of course) If you don't find it there, it's probably references held in processes. You can crawl processes with process_info(Pid, binary), but it's a little tricky because the value you get back is undocumented. If you find a lot of memory used by binaries, the solutions are all pretty simple: a) if it's binaries held in processes, and those processes really don't hang onto binaries, just receive and send them, and you're running older erlang (before 19?), try to upgrade --- there's a GC change around then to include refC binary size when checking to see if process GC should run. b) anywhere else, do StorableBinary = binary:copy(Binary) and store StoredableBinary instead of Binary. This gets you an exactly sized binary (heap or ref-counted), instead of a binary referenced into another. Parsing larger binaries (like JSON) is one way to get these overlarge binaries, but they're also pretty easy to get with idiomatic code like shown in the efficiency guide[1]; when the system builds a appendable refC binary, it makes appending efficient, but storage inefficient. [1] http://erlang.org/doc/efficiency_guide/binaryhandling.html#constructing-binaries http://erlang.org/doc/efficiency_guide/binaryhandling.html#c...
- rantwasp 6y ago
  Elixir and Erlang are not at the same level. Elixir compiles down to Erlang which is compiled down to BEAM code.
  - lobo_tuerto 6y ago
    No, it's not exactly like that. But in short, yes, Elixir and Erlang are more akin than they are not. As both compile to an intermediate form called Erlang Abstract Format. Here is the info: https://elixirforum.com/t/getting-each-stage-of-elixirs-compilation-all-the-way-to-the-beam-bytecode/1873/6 https://elixirforum.com/t/getting-each-stage-of-elixirs-comp...
    - rantwasp 6y ago
      yes there is a difference between erlang and the erlang abstract format but, given my limited understanding, for all intents and purposes erlang is equivalent to the abstract format (ie i can get one from the other). elixir does not stand on its own and it’s more like a thin veneer on top of erlang than a standalone language that targets the beam vm. that being said, the powed of elixir comes from how easy it is to learn and use it, the macro expansions (which in my opinion is the killer feature and is not talked enough) and the seamless way it managed to leverage and enhance the erlang ecosystem.
vendiddy 6y ago
Do you have some examples of abstractions that you found to be leaky? In my first 6 months of Elixir development, I got very far with just modules, structs, and functional programming. A common pitfall for new Elixir developers is to reach features that are overkill. Metaprogramming, gen servers, protocols, etc, are powerful, but you don't need to know them to start building apps with Phoenix.
- cultofmetatron 6y ago
  I second that. Been working on a startup with our core system in elixir for a year now. I only wrote my first genserver 2 months ago and I've yet to touch protocols. I got pretty far with what you can learn in the first 2 weeks + some ecto specific nuances.
  - dnautics 6y ago
    IMO, Protocols (and to a lesser extent GenServers) are really there for library writers to write; if you're not writing a library, you probably shouldn't be using it.
    - Grimm1 6y ago
      Heavy disagree, protocols are just an interface like solution and things that share a common set of functionality can probably benefit from utilizing a protocol. GenServers I disagree with you on even more so since they can handle arbitrary messages (handle_info) it makes it a lot easier to do things like run a continuous process that does an action every n seconds as an example and also to handle life cycle messages from other processes. Oh my downstream consumer says things are finished handle a message that cleans up the children processes and shuts down the supervisor so we don't keep polling. I use them to great effect in web crawling as a producer for things like Broadway and things like Agent or Task don't have the flexibility at the level I need it.
      - deleted 6y ago
        [deleted]

dynamite-ready 6y ago

Elixir's syntax is very nice, but at it's core, the Elixir/Erlang/OTP Actor model thing is quite different to other forms of programming.

emadb 6y ago

Actually Elixir and Erlang are at the same level: they both run on the BEAM. So you need to know the BEAM that it is like a virtual machine that act differently from what we are used to (JVM, .NET). Once you learn the BEAM everything become clear and easy to use. IMHO Process state isolation and message passing are the core, that's not so difficult to learn and apply.

discordianfish 6y ago
Yes, you need to learn the BEAM VM which makes it not easy to learn. It still might be worth it, but now you need to understand Elixir, Erlang, BEAM - additionally to your OS's API. All I can offer are anecdotes but I've worked at one company with a sizeable rabbitmq cluster where we were fortunate enough to have a guy in a different team who was a BEAM maintainer in his free time. He was the only one able to debug issues (mostly around unexpected memory usage). At another place, we had some in house elixir services. Developers were very happy and productive with it, but we also ran into unexpected memory usage and crashes due to that and to the day their root cause are unclear, even after adding detailed telemetry to monitor process counts and memory profiles. I guess I have a general issue with VM based languages, but that might be due to the fact that I spend more time debugging issues than writing software and I appreciate the common libc/syscall api used in VM-less languages.
- dnautics 6y ago
  > unexpected memory usage Number one cause of hard-to-track memory usage in elixir, especially with services that parse JSON. Someone is ingesting JSON and caching a snippet of the JSON in an ets table, which means the entire JSON is never GC'd.
  - toast0 6y ago
    This is pretty easy to identify and fix once you know about it and how to look. To identify: erlang:memory() shows unexpectedly large word count for binaries. Crawl all your ets tables and look if referenced_byte_size(Binary) is significantly larger than size(Binary) (you need to check the keys as well as the values, and you'll need to write something to crawl through your complex values, of course) If you don't find it there, it's probably references held in processes. You can crawl processes with process_info(Pid, binary), but it's a little tricky because the value you get back is undocumented. If you find a lot of memory used by binaries, the solutions are all pretty simple: a) if it's binaries held in processes, and those processes really don't hang onto binaries, just receive and send them, and you're running older erlang (before 19?), try to upgrade --- there's a GC change around then to include refC binary size when checking to see if process GC should run. b) anywhere else, do StorableBinary = binary:copy(Binary) and store StoredableBinary instead of Binary. This gets you an exactly sized binary (heap or ref-counted), instead of a binary referenced into another. Parsing larger binaries (like JSON) is one way to get these overlarge binaries, but they're also pretty easy to get with idiomatic code like shown in the efficiency guide[1]; when the system builds a appendable refC binary, it makes appending efficient, but storage inefficient. [1] http://erlang.org/doc/efficiency_guide/binaryhandling.html#constructing-binaries http://erlang.org/doc/efficiency_guide/binaryhandling.html#c...
rantwasp 6y ago
Elixir and Erlang are not at the same level. Elixir compiles down to Erlang which is compiled down to BEAM code.
- lobo_tuerto 6y ago
  No, it's not exactly like that. But in short, yes, Elixir and Erlang are more akin than they are not. As both compile to an intermediate form called Erlang Abstract Format. Here is the info: https://elixirforum.com/t/getting-each-stage-of-elixirs-compilation-all-the-way-to-the-beam-bytecode/1873/6 https://elixirforum.com/t/getting-each-stage-of-elixirs-comp...
  - rantwasp 6y ago
    yes there is a difference between erlang and the erlang abstract format but, given my limited understanding, for all intents and purposes erlang is equivalent to the abstract format (ie i can get one from the other). elixir does not stand on its own and it’s more like a thin veneer on top of erlang than a standalone language that targets the beam vm. that being said, the powed of elixir comes from how easy it is to learn and use it, the macro expansions (which in my opinion is the killer feature and is not talked enough) and the seamless way it managed to leverage and enhance the erlang ecosystem.

vendiddy 6y ago

Do you have some examples of abstractions that you found to be leaky? In my first 6 months of Elixir development, I got very far with just modules, structs, and functional programming. A common pitfall for new Elixir developers is to reach features that are overkill. Metaprogramming, gen servers, protocols, etc, are powerful, but you don't need to know them to start building apps with Phoenix.

cultofmetatron 6y ago
I second that. Been working on a startup with our core system in elixir for a year now. I only wrote my first genserver 2 months ago and I've yet to touch protocols. I got pretty far with what you can learn in the first 2 weeks + some ecto specific nuances.
- dnautics 6y ago
  IMO, Protocols (and to a lesser extent GenServers) are really there for library writers to write; if you're not writing a library, you probably shouldn't be using it.
  - Grimm1 6y ago
    Heavy disagree, protocols are just an interface like solution and things that share a common set of functionality can probably benefit from utilizing a protocol. GenServers I disagree with you on even more so since they can handle arbitrary messages (handle_info) it makes it a lot easier to do things like run a continuous process that does an action every n seconds as an example and also to handle life cycle messages from other processes. Oh my downstream consumer says things are finished handle a message that cleans up the children processes and shuts down the supervisor so we don't keep polling. I use them to great effect in web crawling as a producer for things like Broadway and things like Agent or Task don't have the flexibility at the level I need it.
    - deleted 6y ago
      [deleted]