9 ms·

The Human Side of Elixir

186 points by feross 5y ago

japhib 5y ago
1. What's funny about the photo at the top of this blog post is that it scales with the width of the window you're using to view it. That normally would seem like a bug but it actually works with this photo, to the point that I can't tell what the original width of the photo is! 2. This quote is kinda funny to me: > Many of the engineers whom I work with, actively seek out Elixir specific opportunities because they enjoy the language and the run-time that much (I’ll be diving into specifically why a bit later in the post ). This is also supported by a recent StackOverflow developer survey where 68.2% of people working with Elixir, wanted to continue working with Elixir. For some comparisons, Go received a 67.9% rating and Javascript received a 66.8% rating. It seems like OP is trying to make the point that Elixir is so special that engineers will actively seek out Elixir jobs ... and then cites stats that show that's true only 1% more than Go and Javascript. Maybe I'm reading it wrong and OP is just trying to show that Elixir is only as loved as Go/JS, not better, but in any case the stat cited does not show Elixir is any more special than either of those other super popular languages. (I'm currently an Elixir dev, btw. I like it well enough but I personally don't think it's enough better than Go or JS to justify switching when the community is still so small.)
- lostcolony 5y ago
  I think the case was more intended to point out it's no different than choosing Go or Javascript, in terms of developer affinity (the size of community is part of what the article is intending to address). Personally, I find Stackoverflow's surveys pretty useless. Python has 73% "loved", which tells me...what? That 73% of Python developers like Python. But what else do they have experience with? Is this just objectively "I like Python", or "I like Python more than X"? What is X? For those who don't "love" their language (which really just translates to "they have not expressed interest in continuing to develop with it", based on what SO gives us), is it because of another language capturing their imagination more? What languages are those, have they actually used it in the past in production, etc.
  - carlmr 5y ago
    >For those who don't "love" their language (which really just translates to "they have not expressed interest in continuing to develop with it", based on what SO gives us), is it because of another language capturing their imagination more? As a C++ dev, definitely Rust. It got almost everything right that is horrible with C++, while still maintaining similar power.
- akoutmos 5y ago
  Author here. Glad you like the banner image and the zooming effect :). Perhaps I miscommunicated what I took away from the StackOverflow survey. The point that I was trying to make was that in relation to other programming languages in the survey, Elixir ranked high with regards to how loved it is. The StackOverflow survey is just one data point in addition to the others that I bring up and like many surveys has it's own issues (like WebAssembly being a compilation target as opposed to a programming language the people program in).
eric4smith 5y ago
Well echoing what the author wrote - it’s quite easy to learn Elixir. We have a new guy who started a bit less than a month ago. He’s now already writing functional Elixir (no pun intended) and contributing to big code base. One of the first things I told him is that “there is no magic in elixir”. What you see is what you get. If you understand that everything is literally a function - life is easy and using the language becomes fun.
- Kototama 5y ago
  > If you understand that everything is literally a function Except when it's a macro :-D
  - ashton314 5y ago
    Come now, macros are just functions over syntax. ;-P But yes, the only headaches I’ve had have been with hard-to-follow macros. That said, the Phoenix Framework has some well-chosen macros that are a delight to work with. Furthermore, all these macros are defined in your source when you create a new Phoenix project—I feel that over all there is remarkably little magic in Phoenix, and what magic there is is easily inspectable.
    - ketzo 5y ago
      Macros are extremely powerful, and like all really powerful things, they’re very easy to shoot yourself in the foot with… we’re lucky that the Phoenix team are some very capable wizards!
    - dnautics 5y ago
      I wouldn't say "remarkably little". There's "relatively little", esp. compared to Rails. I'd even say there's little magic compared to Django. But try to peek under the hood of Phoenix.Helpers someday... And also, don't ask too many questions about how Ecto drivers work... I tried writing an ecto driver once and gave up. Props to the people who made the Sqlite3 driver.
- hinkley 5y ago
sergiotapia 5y ago
This is kind of a puff-piece highly upvoted by Elixir fanboys. I'm a fanboy too lol fwiw.
- sodapopcan 5y ago
  Ehn, the more pro-Elixir search results out there the better. I feel the same way as the author and really want to find a job where I can work with it full time, but my current work situation is too good to give up.
alberth 5y ago
Twitter considered migrating from Ruby on Rails to Erlang 11 years ago (but ultimately chose Scala due to the Java tie-in). https://news.ycombinator.com/item?id=2825689 https://news.ycombinator.com/item?id=2825689 I've always wonder how the Erlang ecosystem would be different today if a digital giant like a Twitter/FB/Google had used Erlang as part of their core business. Note: yes, I realize WhatsApp owned by FB is run on Erlang.
- dmitriid 5y ago
  Facebook chat was originally written in Erlang and then migrated to internal C/C++ framework. Giants use and experiment with a variety of languages.
  - bcrosby95 5y ago
    This is why I'm always skeptical when someone says "$bigco uses $language! It's on the map!" Yeah, well, somewhere, in some department, $bigco probably uses any random language you can think of.
    - joelbluminator 5y ago
      Yes, this. They buy companies all the time. Also counting Erlang and Elixir together seems a bit odd, are they the same thing? Is a Clojure company actually a Java company?
      - josevalim 5y ago
        If someone makes the Java GC 3x faster, that will most likely positively impact all Java and Clojure programmers. Similarly, if someone wants to invest on Clojure performance, they most likely need to do so by investing on the JVM and core libraries, which will benefit the overall ecosystem. Plus one main reasons people use to pick JVM languages is the access to the whole Java ecosystem and related packages. Therefore, if you are considering the performance of the platform, improvements to the runtime and virtual machine, package ecosystem, etc, lumping them together makes total sense. On the other hand, Clojure and Java are quite different languages, with complete different paradigms, so there is probably a ticker layer specifically dedicated to Clojure. Erlang and Elixir are much closer to each other than Clojure and Java or even Scala and Java. The data structures are the same, the language constructs are mostly the same (different syntax but the same semantics), etc. You can call each other with no performance cost whatsoever. All of the companies investing on Erlang will directly impact Elixir and, if you want to make the Elixir compiler or runtime faster, odds are that this efforts goes to Erlang - it is one of the reasons I have ~100 PRs merged upstream, mostly focused on the compiler and/or performance. So, once again, if your goal is to assess the healthy of the ecosystem or how many companies are investing on the platform, then they must be considered together. The contributions done by Ericsson, Whatsapp, Klarna, Erlang Solutions, etc. benefit all languages running on the Erlang VM. In fact, if someone asks me how they can financially contribute to Elixir, I will 100% direct them to the Erlang Ecosystem Foundation (https://erlef.org/ https://erlef.org/), which focuses on domain areas around the ecosystem, rather than languages. Since you seem to use Ruby as a reference, I don't expect the dynamics to be much different. Most companies and contributors are likely working directly on the Ruby VM and the runtime, rather than the language itself. However, because Ruby is the only (main?) language running on it, we don't tend to separate them. But in practice the language is only a small surface into the complexity that is its underlying platform and working on said platforms requires a completely different set of skills and technologies. EDIT: this applies to the ecosystem too. For example, every Phoenix application is running a web server written in... Erlang. :) All Ecto database adapters are using the tcp modules provided by Erlang. The package manager that powers all languages running on the Erlang VM is written in Elixir. And so on. You don't need to know Erlang in order to write Elixir but, if for some reason you need to pick up, it is straightforward because of all of the above.
hervature 5y ago
Not sure if this against the guidelines (it says no job ads as submissions), but on the note of hiring Elixir developers, if anyone is interested in being involved in an early stage Elixir (Phoenix) startup, we at Jinso are hiring a senior engineer with Elixir experience and would love to hear from you: https://www.jinso.com/ https://www.jinso.com/ Don't want to derail the conversation, but shoot us an email at admin [at] jinso.com. We are happy to tell you about us and get to know who you are!
Thaxll 5y ago
Do people actually enjoy FP on the long run? Most devs are used to OO.
- Zababa 5y ago
  I do, for some reason it fits my brain more than OO.
  - fish45 5y ago
    I think many people haven't realized that different paradigms fit different people's brains in different ways; there are better paradigms for a specific person and task but it's impossible to generalize.
- sodapopcan 5y ago
  Yep, FP is really nice. A lot of what people think is going to be different is actually not that different from OO. Elixir especially ends up looking a lot like OO with its pipe operator ("string" |> String.split() vs "string".split(), for eg). Some of the major wins are immutability (which is actually very easy to grasp and a lot of people write in an immutable style in OO) and the fact you can every functions dependencies right there. The latter is actually huge for me as I always hated jumping around files, trying to see where things are coming from. FP minimizes this. There are lots of other niceties (some language-specific) but those are some of my faves. Sometimes things take a little longer to write as you have to be slightly more verbose, but it's so much quicker to understand when coming back to it.
  - h0l0cube 5y ago
    What's better (and more flexible) than Object Oriented is Polymorphism. The pipe operator |> that you mention is great example because it does something in OO that is typically done using a 'fluent interface'[0] often used in 'Builder' classes (i.e., the class methods return the object so that it can be chained together). The great thing about the pipe operator is that it's much more simple and flexible, it simply passes the result of the prior function as the first argument to the second. This means, unlike with a fluent API, you can pipe together functions from completely different modules: :crypto.hash(:md5, some_binary) |> :base64.encode_to_string() Elixir also has protocols[1], which allow a function to be used across a variety of types (similar to obj-c/Swift). Which again is more flexible, as the functionality can extend a 'class' that you don't control. Elixir also has behaviors[2], which just guarantee that a module contains a number of functions, something akin to interfaces Java. Dialyzer can take advantage of behaviors and protocols to enforce typing constraints. [0] https://en.wikipedia.org/wiki/Fluent_interface https://en.wikipedia.org/wiki/Fluent_interface [1] https://hexdocs.pm/elixir/1.12/Protocol.html https://hexdocs.pm/elixir/1.12/Protocol.html [2] https://hexdocs.pm/elixir/1.12/Behaviour.html https://hexdocs.pm/elixir/1.12/Behaviour.html
dnautics 5y ago
I'm curious about the experience of having taught a senior dev GenServers so early on. I guess it depends on what they are working on, but I think for most people (senior devs included) GenServers are YAGNI -- I have not once written a genserver for my current job, the senior might be tempted to be clever and use GenServers as code organization or as a circumvention to write stateful code, a la "objects" because GenServers are rather close to Alan Kay's original objects. But I guess that's what code review is for!
- zinclozenge 5y ago
  The temptation is there, but AFAIK most learning materials are good to call out that processes are for concurrency needs, and a genserver is an abstraction on top of that to help with certain things, like synchronization.
- akoutmos 5y ago
  In my day to day work I don't write many GenServers either and I think that's a good thing. Like any tool, they can be overused and abused. It is best to stick to modules and pure functions until you really need to pull the stateful lever. To that point, GenServers as an abstraction are super powerful and when applicable, are an amazing tool. For example, being able to control the initialization of a supervision trees using :ignore in the init callback can be handy to run DB migrations as part of the application startup. Or when used in combination with a registry it can be useful to hold on to user data in a GenServer and access it atomically across your cluster.
- slezakattack 5y ago
  As a seasoned Erlang developer, it's really foreign to me that people can go so far as to never need a GenServer since they are everywhere in Erlang. Have you had any experience with ramping up an Erlang engineer to use Elixir? After interviewing an Elixir dev for an Erlang position, it was interesting that so much of what they used in their day-to-day abstracted away the components of OTP and the Beam. Didn't really have a firm grasp of supervision trees, process linking vs monitoring, etc.
  - 5y ago
vasergen 5y ago
What is not mentioned here, the lack of static typing in elixir. I think for some people it could be no go. That is one major downside for me as well. On the other side, totally agree with the developer experience, really love it. I work profecionally with nodejs/typescript and on my free time looking on other languages, especially functional ones. I tried clojure before, but found the ecosystem in Elixir way better, especially dev tooling. It feels like it all really stick to each other. Another part, because all structured around modules, it is easy to check documentation and find the function you are looking for.
- akoutmos 5y ago
  I personally don't miss statically typed languages having worked professionally with Java, C++, and Typescript in the past. But if static typing is your cup of tea and you want to run on the BEAM, be sure to check out the Gleam programming language https://gleam.run/ https://gleam.run/
- conradfr 5y ago
  I dont' care about static vs dynamic typing but if I could at least typehint function arguments my IDE intellisense and I would be so happy :) Maybe it could even be compiled to guard clauses or something? Writing specs is tedious and apparently not even encouraged for private functions.
  - OkayPhysicist 5y ago
    Pattern matching and guards handle that aspect quite well.
- shazzdeeds 5y ago
  We use the dialyzer and also heavy usage of the @spec function signature annotation on public module functions to work around this. It’s an nice compromise between some defensive safety while still enjoying the readability of the dynamic typing.
  - h0l0cube 5y ago
syspec 5y ago
> This post was sponsored by digital product consultancy DockYard to support the Elixir community and to encourage its members to share their stories Sponsored content

186 points by feross 5y ago

1. What's funny about the photo at the top of this blog post is that it scales with the width of the window you're using to view it. That normally would seem like a bug but it actually works with this photo, to the point that I can't tell what the original width of the photo is! 2. This quote is kinda funny to me: > Many of the engineers whom I work with, actively seek out Elixir specific opportunities because they enjoy the language and the run-time that much (I’ll be diving into specifically why a bit later in the post ). This is also supported by a recent StackOverflow developer survey where 68.2% of people working with Elixir, wanted to continue working with Elixir. For some comparisons, Go received a 67.9% rating and Javascript received a 66.8% rating. It seems like OP is trying to make the point that Elixir is so special that engineers will actively seek out Elixir jobs ... and then cites stats that show that's true only 1% more than Go and Javascript. Maybe I'm reading it wrong and OP is just trying to show that Elixir is only as loved as Go/JS, not better, but in any case the stat cited does not show Elixir is any more special than either of those other super popular languages. (I'm currently an Elixir dev, btw. I like it well enough but I personally don't think it's enough better than Go or JS to justify switching when the community is still so small.)

lostcolony 5y ago
I think the case was more intended to point out it's no different than choosing Go or Javascript, in terms of developer affinity (the size of community is part of what the article is intending to address). Personally, I find Stackoverflow's surveys pretty useless. Python has 73% "loved", which tells me...what? That 73% of Python developers like Python. But what else do they have experience with? Is this just objectively "I like Python", or "I like Python more than X"? What is X? For those who don't "love" their language (which really just translates to "they have not expressed interest in continuing to develop with it", based on what SO gives us), is it because of another language capturing their imagination more? What languages are those, have they actually used it in the past in production, etc.
- carlmr 5y ago
  >For those who don't "love" their language (which really just translates to "they have not expressed interest in continuing to develop with it", based on what SO gives us), is it because of another language capturing their imagination more? As a C++ dev, definitely Rust. It got almost everything right that is horrible with C++, while still maintaining similar power.
akoutmos 5y ago
Author here. Glad you like the banner image and the zooming effect :). Perhaps I miscommunicated what I took away from the StackOverflow survey. The point that I was trying to make was that in relation to other programming languages in the survey, Elixir ranked high with regards to how loved it is. The StackOverflow survey is just one data point in addition to the others that I bring up and like many surveys has it's own issues (like WebAssembly being a compilation target as opposed to a programming language the people program in).

eric4smith 5y ago

Well echoing what the author wrote - it’s quite easy to learn Elixir. We have a new guy who started a bit less than a month ago. He’s now already writing functional Elixir (no pun intended) and contributing to big code base. One of the first things I told him is that “there is no magic in elixir”. What you see is what you get. If you understand that everything is literally a function - life is easy and using the language becomes fun.

Kototama 5y ago
> If you understand that everything is literally a function Except when it's a macro :-D
- ashton314 5y ago
  Come now, macros are just functions over syntax. ;-P But yes, the only headaches I’ve had have been with hard-to-follow macros. That said, the Phoenix Framework has some well-chosen macros that are a delight to work with. Furthermore, all these macros are defined in your source when you create a new Phoenix project—I feel that over all there is remarkably little magic in Phoenix, and what magic there is is easily inspectable.
  - ketzo 5y ago
    Macros are extremely powerful, and like all really powerful things, they’re very easy to shoot yourself in the foot with… we’re lucky that the Phoenix team are some very capable wizards!
  - dnautics 5y ago
    I wouldn't say "remarkably little". There's "relatively little", esp. compared to Rails. I'd even say there's little magic compared to Django. But try to peek under the hood of Phoenix.Helpers someday... And also, don't ask too many questions about how Ecto drivers work... I tried writing an ecto driver once and gave up. Props to the people who made the Sqlite3 driver.
hinkley 5y ago

sergiotapia 5y ago

This is kind of a puff-piece highly upvoted by Elixir fanboys. I'm a fanboy too lol fwiw.

sodapopcan 5y ago
Ehn, the more pro-Elixir search results out there the better. I feel the same way as the author and really want to find a job where I can work with it full time, but my current work situation is too good to give up.

alberth 5y ago

Twitter considered migrating from Ruby on Rails to Erlang 11 years ago (but ultimately chose Scala due to the Java tie-in). https://news.ycombinator.com/item?id=2825689 https://news.ycombinator.com/item?id=2825689 I've always wonder how the Erlang ecosystem would be different today if a digital giant like a Twitter/FB/Google had used Erlang as part of their core business. Note: yes, I realize WhatsApp owned by FB is run on Erlang.

dmitriid 5y ago
Facebook chat was originally written in Erlang and then migrated to internal C/C++ framework. Giants use and experiment with a variety of languages.
- bcrosby95 5y ago
  This is why I'm always skeptical when someone says "$bigco uses $language! It's on the map!" Yeah, well, somewhere, in some department, $bigco probably uses any random language you can think of.
  - joelbluminator 5y ago
    Yes, this. They buy companies all the time. Also counting Erlang and Elixir together seems a bit odd, are they the same thing? Is a Clojure company actually a Java company?
    - josevalim 5y ago
      If someone makes the Java GC 3x faster, that will most likely positively impact all Java and Clojure programmers. Similarly, if someone wants to invest on Clojure performance, they most likely need to do so by investing on the JVM and core libraries, which will benefit the overall ecosystem. Plus one main reasons people use to pick JVM languages is the access to the whole Java ecosystem and related packages. Therefore, if you are considering the performance of the platform, improvements to the runtime and virtual machine, package ecosystem, etc, lumping them together makes total sense. On the other hand, Clojure and Java are quite different languages, with complete different paradigms, so there is probably a ticker layer specifically dedicated to Clojure. Erlang and Elixir are much closer to each other than Clojure and Java or even Scala and Java. The data structures are the same, the language constructs are mostly the same (different syntax but the same semantics), etc. You can call each other with no performance cost whatsoever. All of the companies investing on Erlang will directly impact Elixir and, if you want to make the Elixir compiler or runtime faster, odds are that this efforts goes to Erlang - it is one of the reasons I have ~100 PRs merged upstream, mostly focused on the compiler and/or performance. So, once again, if your goal is to assess the healthy of the ecosystem or how many companies are investing on the platform, then they must be considered together. The contributions done by Ericsson, Whatsapp, Klarna, Erlang Solutions, etc. benefit all languages running on the Erlang VM. In fact, if someone asks me how they can financially contribute to Elixir, I will 100% direct them to the Erlang Ecosystem Foundation (https://erlef.org/ https://erlef.org/), which focuses on domain areas around the ecosystem, rather than languages. Since you seem to use Ruby as a reference, I don't expect the dynamics to be much different. Most companies and contributors are likely working directly on the Ruby VM and the runtime, rather than the language itself. However, because Ruby is the only (main?) language running on it, we don't tend to separate them. But in practice the language is only a small surface into the complexity that is its underlying platform and working on said platforms requires a completely different set of skills and technologies. EDIT: this applies to the ecosystem too. For example, every Phoenix application is running a web server written in... Erlang. :) All Ecto database adapters are using the tcp modules provided by Erlang. The package manager that powers all languages running on the Erlang VM is written in Elixir. And so on. You don't need to know Erlang in order to write Elixir but, if for some reason you need to pick up, it is straightforward because of all of the above.

hervature 5y ago

Not sure if this against the guidelines (it says no job ads as submissions), but on the note of hiring Elixir developers, if anyone is interested in being involved in an early stage Elixir (Phoenix) startup, we at Jinso are hiring a senior engineer with Elixir experience and would love to hear from you: https://www.jinso.com/ https://www.jinso.com/ Don't want to derail the conversation, but shoot us an email at admin [at] jinso.com. We are happy to tell you about us and get to know who you are!

Thaxll 5y ago

Do people actually enjoy FP on the long run? Most devs are used to OO.

Zababa 5y ago
I do, for some reason it fits my brain more than OO.
- fish45 5y ago
  I think many people haven't realized that different paradigms fit different people's brains in different ways; there are better paradigms for a specific person and task but it's impossible to generalize.
sodapopcan 5y ago
Yep, FP is really nice. A lot of what people think is going to be different is actually not that different from OO. Elixir especially ends up looking a lot like OO with its pipe operator ("string" |> String.split() vs "string".split(), for eg). Some of the major wins are immutability (which is actually very easy to grasp and a lot of people write in an immutable style in OO) and the fact you can every functions dependencies right there. The latter is actually huge for me as I always hated jumping around files, trying to see where things are coming from. FP minimizes this. There are lots of other niceties (some language-specific) but those are some of my faves. Sometimes things take a little longer to write as you have to be slightly more verbose, but it's so much quicker to understand when coming back to it.
- h0l0cube 5y ago
  What's better (and more flexible) than Object Oriented is Polymorphism. The pipe operator |> that you mention is great example because it does something in OO that is typically done using a 'fluent interface'[0] often used in 'Builder' classes (i.e., the class methods return the object so that it can be chained together). The great thing about the pipe operator is that it's much more simple and flexible, it simply passes the result of the prior function as the first argument to the second. This means, unlike with a fluent API, you can pipe together functions from completely different modules: :crypto.hash(:md5, some_binary) |> :base64.encode_to_string() Elixir also has protocols[1], which allow a function to be used across a variety of types (similar to obj-c/Swift). Which again is more flexible, as the functionality can extend a 'class' that you don't control. Elixir also has behaviors[2], which just guarantee that a module contains a number of functions, something akin to interfaces Java. Dialyzer can take advantage of behaviors and protocols to enforce typing constraints. [0] https://en.wikipedia.org/wiki/Fluent_interface https://en.wikipedia.org/wiki/Fluent_interface [1] https://hexdocs.pm/elixir/1.12/Protocol.html https://hexdocs.pm/elixir/1.12/Protocol.html [2] https://hexdocs.pm/elixir/1.12/Behaviour.html https://hexdocs.pm/elixir/1.12/Behaviour.html

dnautics 5y ago

I'm curious about the experience of having taught a senior dev GenServers so early on. I guess it depends on what they are working on, but I think for most people (senior devs included) GenServers are YAGNI -- I have not once written a genserver for my current job, the senior might be tempted to be clever and use GenServers as code organization or as a circumvention to write stateful code, a la "objects" because GenServers are rather close to Alan Kay's original objects. But I guess that's what code review is for!

zinclozenge 5y ago
The temptation is there, but AFAIK most learning materials are good to call out that processes are for concurrency needs, and a genserver is an abstraction on top of that to help with certain things, like synchronization.
akoutmos 5y ago
In my day to day work I don't write many GenServers either and I think that's a good thing. Like any tool, they can be overused and abused. It is best to stick to modules and pure functions until you really need to pull the stateful lever. To that point, GenServers as an abstraction are super powerful and when applicable, are an amazing tool. For example, being able to control the initialization of a supervision trees using :ignore in the init callback can be handy to run DB migrations as part of the application startup. Or when used in combination with a registry it can be useful to hold on to user data in a GenServer and access it atomically across your cluster.
slezakattack 5y ago
As a seasoned Erlang developer, it's really foreign to me that people can go so far as to never need a GenServer since they are everywhere in Erlang. Have you had any experience with ramping up an Erlang engineer to use Elixir? After interviewing an Elixir dev for an Erlang position, it was interesting that so much of what they used in their day-to-day abstracted away the components of OTP and the Beam. Didn't really have a firm grasp of supervision trees, process linking vs monitoring, etc.
- 5y ago

vasergen 5y ago

What is not mentioned here, the lack of static typing in elixir. I think for some people it could be no go. That is one major downside for me as well. On the other side, totally agree with the developer experience, really love it. I work profecionally with nodejs/typescript and on my free time looking on other languages, especially functional ones. I tried clojure before, but found the ecosystem in Elixir way better, especially dev tooling. It feels like it all really stick to each other. Another part, because all structured around modules, it is easy to check documentation and find the function you are looking for.

akoutmos 5y ago
I personally don't miss statically typed languages having worked professionally with Java, C++, and Typescript in the past. But if static typing is your cup of tea and you want to run on the BEAM, be sure to check out the Gleam programming language https://gleam.run/ https://gleam.run/
conradfr 5y ago
I dont' care about static vs dynamic typing but if I could at least typehint function arguments my IDE intellisense and I would be so happy :) Maybe it could even be compiled to guard clauses or something? Writing specs is tedious and apparently not even encouraged for private functions.
- OkayPhysicist 5y ago
  Pattern matching and guards handle that aspect quite well.
shazzdeeds 5y ago
We use the dialyzer and also heavy usage of the @spec function signature annotation on public module functions to work around this. It’s an nice compromise between some defensive safety while still enjoying the readability of the dynamic typing.
- h0l0cube 5y ago

syspec 5y ago

> This post was sponsored by digital product consultancy DockYard to support the Elixir community and to encourage its members to share their stories Sponsored content