4 ms·

A week with Elixir (2013)

50 points by behnamoh 2y ago

behnamoh 2y ago
[flagged]
- deleted 2y ago
  [deleted]
tombert 2y ago
I miss Joe, he was a super nice guy who always responded back to my dumb emails when I was first starting as an engineer asking for help with concurrent programming in elaborate detail. He didn't have to do that, but he did, and he was awesome for it. Even in this post, he was able to be polite and still critical of Elixir, pointing out parts that annoyed him, but still ended it with positive praise.
- deleted 2y ago
  [deleted]
- asa400 2y ago
  I can’t second this enough. I never knew him personally but hung out around him at a few Erlang conferences and he was always incredibly kind and giving. He never knew it but he had a huge impact on me as an engineer.
deleted 2y ago
[deleted]
sbuttgereit 2y ago
One thing that I don't think gets recognized enough is, at least in my experience, how supportive the different BEAM language communities are of each other. As someone that spends time with Elixir, I find it encouraging for the whole BEAM ecosystem when I see some key people involved with Erlang commenting in and being generally helpful to people in the Elixir community over at the Elixir Forums with some frequency. I know when I'm thinking of the ecosystem, I really think if it more in terms of the broader concept of the BEAM as being "the ecosystem", that common thread, rather than just Elixir, or Erlang, or LFE, of Gleam individually.
behnamoh 2y ago
What threw me off with Elixir was multiple inconsistencies, some of which documented in this article (btw, Elixir didn't fix the issue Joe mentioned about FORMS ≠ EXPRESSIONS). Another one is this: When you first learn Elixir, you start to like the idea of calling functions from their types, like Tuple.product({2, 4}). Now if you want to get the size of a tuple, what do you do? Probably Tuple.size(...), right? Wrong. You should use tuple_size(...)! Turns out sometimes you gotta use these "orphan" functions even though they logically belong to a certain type (in this case, why isn't tuple_size called like Tuple.size or something?)
- giraffe_lady 2y ago
  I didn't look it up for this one specifically but usually those are when elixir is just directly applying a function from the core erlang module (ie erlang global fns). As for why they do that, rather than wrap them into the appropriate module, I have no idea. There may be a valid reason: for a language that is otherwise so careful about naming, organization, and consistency it would be a bizarre unforced error. Some of them have nonstandard (for elixir) names and parameter order too so they are definitely one of the few unpleasant quirks of the language.
- gamache 2y ago
  > Turns out sometimes you gotta use these "orphan" functions even though they logically belong to a certain type (in this case, why isn't tuple_size called like Tuple.size or something?) tuple_size/1 is a guard, and guards are built-in. The compiler itself uses them. Unlike regular functions, you are allowed to use guards in a function head, like: def foo(my_tuple) when tuple_size(my_tuple) == 3 do ... Official docs: https://hexdocs.pm/elixir/1.16.3/patterns-and-guards.html#guards https://hexdocs.pm/elixir/1.16.3/patterns-and-guards.html#gu...
  - gamache 2y ago
    Oh yeah, FWIW a "built-in" function or macro just means it's a part of the Kernel module, which is automatically required+imported in Elixir modules. So it's not orphaned, it's just in the one special module that gets brought in by default.

50 points by behnamoh 2y ago

behnamoh 2y ago

[flagged]

deleted 2y ago
[deleted]

tombert 2y ago

I miss Joe, he was a super nice guy who always responded back to my dumb emails when I was first starting as an engineer asking for help with concurrent programming in elaborate detail. He didn't have to do that, but he did, and he was awesome for it. Even in this post, he was able to be polite and still critical of Elixir, pointing out parts that annoyed him, but still ended it with positive praise.

deleted 2y ago
[deleted]
asa400 2y ago
I can’t second this enough. I never knew him personally but hung out around him at a few Erlang conferences and he was always incredibly kind and giving. He never knew it but he had a huge impact on me as an engineer.

deleted 2y ago

[deleted]

sbuttgereit 2y ago

One thing that I don't think gets recognized enough is, at least in my experience, how supportive the different BEAM language communities are of each other. As someone that spends time with Elixir, I find it encouraging for the whole BEAM ecosystem when I see some key people involved with Erlang commenting in and being generally helpful to people in the Elixir community over at the Elixir Forums with some frequency. I know when I'm thinking of the ecosystem, I really think if it more in terms of the broader concept of the BEAM as being "the ecosystem", that common thread, rather than just Elixir, or Erlang, or LFE, of Gleam individually.

behnamoh 2y ago

What threw me off with Elixir was multiple inconsistencies, some of which documented in this article (btw, Elixir didn't fix the issue Joe mentioned about FORMS ≠ EXPRESSIONS). Another one is this: When you first learn Elixir, you start to like the idea of calling functions from their types, like Tuple.product({2, 4}). Now if you want to get the size of a tuple, what do you do? Probably Tuple.size(...), right? Wrong. You should use tuple_size(...)! Turns out sometimes you gotta use these "orphan" functions even though they logically belong to a certain type (in this case, why isn't tuple_size called like Tuple.size or something?)

giraffe_lady 2y ago
I didn't look it up for this one specifically but usually those are when elixir is just directly applying a function from the core erlang module (ie erlang global fns). As for why they do that, rather than wrap them into the appropriate module, I have no idea. There may be a valid reason: for a language that is otherwise so careful about naming, organization, and consistency it would be a bizarre unforced error. Some of them have nonstandard (for elixir) names and parameter order too so they are definitely one of the few unpleasant quirks of the language.
gamache 2y ago
> Turns out sometimes you gotta use these "orphan" functions even though they logically belong to a certain type (in this case, why isn't tuple_size called like Tuple.size or something?) tuple_size/1 is a guard, and guards are built-in. The compiler itself uses them. Unlike regular functions, you are allowed to use guards in a function head, like: def foo(my_tuple) when tuple_size(my_tuple) == 3 do ... Official docs: https://hexdocs.pm/elixir/1.16.3/patterns-and-guards.html#guards https://hexdocs.pm/elixir/1.16.3/patterns-and-guards.html#gu...
- gamache 2y ago
  Oh yeah, FWIW a "built-in" function or macro just means it's a part of the Kernel module, which is automatically required+imported in Elixir modules. So it's not orphaned, it's just in the one special module that gets brought in by default.