5 ms·

How is refactoring? I was considering moving from Node to Elixir, but now that I’m using TypeScript it does feel like I would be giving something up. It’s a br

How is refactoring? I was considering moving from Node to Elixir, but now that I’m using TypeScript it does feel like I would be giving something up. It’s a breeze to make broad changes knowing the compiler will prevent me from missing a code path, etc.

dnautics 6y ago
Write your tests, gradually make red go to green. Super rewarding. Code coverage reports are a thing. You should be writing your tests async (including tests that leave the VM) in elixir, that will give you a chance to catch and raise asserts on race conditions which will stress ouct timings in your vm, etc. https://youtu.be/hvgdWQuriB4 https://youtu.be/hvgdWQuriB4
- mcintyre1994 6y ago
  Thanks for sharing this, looks like a really useful series of videos :)
thdxr 6y ago
Having spent a lot of time in both it's hard to argue it's as easy in Elixir. You can do it reasonably with a lot of tests but it's nowhere near the same experience as TS
argvargc 6y ago
I'm only just starting with Elixir, but my impression so far is that I will be refactoring a lot less, due to the way Elixir encourages simple and elegant approaches to many of the common problems a programmer faces. In node for example, I'm refactoring constantly (or, at least, should be...) because I keep backing myself into cognitive and developmental corners by using a kind of brick-by-brick approach that is perhaps encouraged not only by the language but by the eco-system. I'm not finding this with Elixir, possibly because many of the more important architectural decisions have already been made for me at the language level, and apparently been made very well. The hurdle becomes more understanding how to best do something, rather than figuring out how to do something at all. A big part of this also may be Elixir's REPL. It has help for everything built-in. Whereas in node for example I find I'm constantly searching online and piecing together things from many different parts, in Elixir I almost never am, it's all just right there.
- ducharmdev 6y ago
  Do you have any concrete examples you can link to show these differences? I'm unsure what you mean by architectural decisions made at the language level.
  - jkhdigital 6y ago
    I am porting a cryptocurrency arbitrage trading platform from Node to Elixir and the difference is extremely refreshing. The actor model lends itself naturally to abstractions like producer, consumer, batcher, dispatcher, etc. which are like stations on an assembly line. “Pulling the chain” when problems occur at any point along the line is simple and clean since the actors are not tightly coupled in the first place. I think the key “architectural decision” here is that code and execution (i.e. the process) are bundled together by design.
  - argvargc 6y ago
    Maybe a good example could be the recursion pattern in Elixir. This is considered almost a base element of the language. Typically in Elixir recursion and "guards", are used instead of things like for-loops and if-else statements in other languages. Take a basic factorial function in Elixir: defmodule Math do def factorial(0), do: 1 def factorial(n), do: n * factorial(n - 1) end There is almost nothing there that isn't directly representative of the base math equation itself (which, by convention, treats the result of factorial(0) as equal to 1). The function order is important in this case, the first is a "guard" that prevents the second from being executed when the firsts case is met. At this point the module exits out of the second function by multiplying the (silently) accumulated result by 1 and returning it. Versus, in JS: function factorial(n) { if (n == 0) { return 1; } else { return (n * factorial(n - 1)); } } It's not too bad, but the if-else, comparison, multiple return statements and nested brackets at the second return are all done away with in the Elixir version. Further, recursion is not something many programmers reach for first when working in many other languages, perhaps out of habit, or maybe of the concern that extending such implementations later can become difficult. As such, most programmers might implement the above as more something like: function factorial(n) { if (n === 0 || n === 1) return 1; for (var i = (n - 1); i >= 1; i--) { n *= i; } return n; } Compared to the Elixir code, many steps are required to read and understand this. When this type of laboured patterning is expanded out into a larger project, with many interlocking parts, it may quickly become difficult to work with, and can become necessary, and necessarily difficult, to refactor into something simpler, which then may require rethinking the entire process.
searchableguy 6y ago
You can use @typespec and @behavior to type parts of elixir. https://elixir-lang.org/getting-started/typespecs-and-behaviours.html https://elixir-lang.org/getting-started/typespecs-and-behavi...

dnautics 6y ago

Write your tests, gradually make red go to green. Super rewarding. Code coverage reports are a thing. You should be writing your tests async (including tests that leave the VM) in elixir, that will give you a chance to catch and raise asserts on race conditions which will stress ouct timings in your vm, etc. https://youtu.be/hvgdWQuriB4 https://youtu.be/hvgdWQuriB4

mcintyre1994 6y ago
Thanks for sharing this, looks like a really useful series of videos :)

thdxr 6y ago

Having spent a lot of time in both it's hard to argue it's as easy in Elixir. You can do it reasonably with a lot of tests but it's nowhere near the same experience as TS

argvargc 6y ago

I'm only just starting with Elixir, but my impression so far is that I will be refactoring a lot less, due to the way Elixir encourages simple and elegant approaches to many of the common problems a programmer faces. In node for example, I'm refactoring constantly (or, at least, should be...) because I keep backing myself into cognitive and developmental corners by using a kind of brick-by-brick approach that is perhaps encouraged not only by the language but by the eco-system. I'm not finding this with Elixir, possibly because many of the more important architectural decisions have already been made for me at the language level, and apparently been made very well. The hurdle becomes more understanding how to best do something, rather than figuring out how to do something at all. A big part of this also may be Elixir's REPL. It has help for everything built-in. Whereas in node for example I find I'm constantly searching online and piecing together things from many different parts, in Elixir I almost never am, it's all just right there.

ducharmdev 6y ago
Do you have any concrete examples you can link to show these differences? I'm unsure what you mean by architectural decisions made at the language level.
- jkhdigital 6y ago
  I am porting a cryptocurrency arbitrage trading platform from Node to Elixir and the difference is extremely refreshing. The actor model lends itself naturally to abstractions like producer, consumer, batcher, dispatcher, etc. which are like stations on an assembly line. “Pulling the chain” when problems occur at any point along the line is simple and clean since the actors are not tightly coupled in the first place. I think the key “architectural decision” here is that code and execution (i.e. the process) are bundled together by design.
- argvargc 6y ago
  Maybe a good example could be the recursion pattern in Elixir. This is considered almost a base element of the language. Typically in Elixir recursion and "guards", are used instead of things like for-loops and if-else statements in other languages. Take a basic factorial function in Elixir: defmodule Math do def factorial(0), do: 1 def factorial(n), do: n * factorial(n - 1) end There is almost nothing there that isn't directly representative of the base math equation itself (which, by convention, treats the result of factorial(0) as equal to 1). The function order is important in this case, the first is a "guard" that prevents the second from being executed when the firsts case is met. At this point the module exits out of the second function by multiplying the (silently) accumulated result by 1 and returning it. Versus, in JS: function factorial(n) { if (n == 0) { return 1; } else { return (n * factorial(n - 1)); } } It's not too bad, but the if-else, comparison, multiple return statements and nested brackets at the second return are all done away with in the Elixir version. Further, recursion is not something many programmers reach for first when working in many other languages, perhaps out of habit, or maybe of the concern that extending such implementations later can become difficult. As such, most programmers might implement the above as more something like: function factorial(n) { if (n === 0 || n === 1) return 1; for (var i = (n - 1); i >= 1; i--) { n *= i; } return n; } Compared to the Elixir code, many steps are required to read and understand this. When this type of laboured patterning is expanded out into a larger project, with many interlocking parts, it may quickly become difficult to work with, and can become necessary, and necessarily difficult, to refactor into something simpler, which then may require rethinking the entire process.

searchableguy 6y ago

You can use @typespec and @behavior to type parts of elixir. https://elixir-lang.org/getting-started/typespecs-and-behaviours.html https://elixir-lang.org/getting-started/typespecs-and-behavi...