3 ms·

now you have two languages in your codebase that your team has to maintain :/

linkdd 6y ago
The external binary serves only one purpose (UNIX style), therefore its source code is almost 50 LOC. This is not a problem.
- kgraves 6y ago
  until you need to change something in that binary.
  - linkdd 6y ago
    How is that a problem? The source code for that binary is in the same repository. I expect developers to know more than one language, especially if one of them is Erlang/Elixir. It's not a stretch to expect a backend/fullstack dev to know Go, Javascript, and/or Python on top of Elixir. It would be more common for them to not know Elixir than the previous 3. Also 50 LOC is small enough so there is not much complexity. Making that binary grow more than needed should not be validated during code review. My use case is as follow: I need an implementation of the iCalendar RFC. The current Elixir implementation does not implement the full RFC, especially features that I need. Implementing this myself would be far more complex than 50 LOC in another language, relying on a fully implemented and well tested library.
    - kgraves 6y ago
      > How is that a problem? The source code for that binary is in the same repository. OS upgrades, deprecations, maintenance are a thing that makes your binary stop working all of a sudden. > Also 50 LOC is small enough so there is not much complexity. Making that binary grow more than needed should not be validated during code review. I've seen bigger lines that makes the binary + Elixir approach not worth the huge maintenance effort. It's like choosing prolog in production, finding out that there is no libraries for it and then hacking together Go binary together with it. Doesn't make sense.
      - linkdd 6y ago
        > OS upgrades, deprecations, maintenance are a thing that makes your binary stop working all of a sudden. Good thing I deploy with Docker/Kubernetes and I have a CI/CD pipeline that will warn me about such cases. > It's like choosing prolog in production, finding out that there is no libraries for it and then hacking together Go binary together with it. Hence this thread. Erlang/Elixir brings so much to the table when it comes to distributed computing. Kubernetes + Elixir + libcluster + horde, I don't know any other language that gets better than this. And yet, there are still some librairies I would need, that I don't want to implement myself, because I don't trust myself to implement them properly (see other comments where I talk about iCalendar). So yeah, I need a "hack", and it makes sense to me to delegate the complexity wherever I can. You could argue that I need to create a microservice, and make an HTTP call. But why make an HTTP call when I can just call the binary without the network layer in between?

The external binary serves only one purpose (UNIX style), therefore its source code is almost 50 LOC. This is not a problem.

kgraves 6y ago
until you need to change something in that binary.
- linkdd 6y ago
  How is that a problem? The source code for that binary is in the same repository. I expect developers to know more than one language, especially if one of them is Erlang/Elixir. It's not a stretch to expect a backend/fullstack dev to know Go, Javascript, and/or Python on top of Elixir. It would be more common for them to not know Elixir than the previous 3. Also 50 LOC is small enough so there is not much complexity. Making that binary grow more than needed should not be validated during code review. My use case is as follow: I need an implementation of the iCalendar RFC. The current Elixir implementation does not implement the full RFC, especially features that I need. Implementing this myself would be far more complex than 50 LOC in another language, relying on a fully implemented and well tested library.
  - kgraves 6y ago
    > How is that a problem? The source code for that binary is in the same repository. OS upgrades, deprecations, maintenance are a thing that makes your binary stop working all of a sudden. > Also 50 LOC is small enough so there is not much complexity. Making that binary grow more than needed should not be validated during code review. I've seen bigger lines that makes the binary + Elixir approach not worth the huge maintenance effort. It's like choosing prolog in production, finding out that there is no libraries for it and then hacking together Go binary together with it. Doesn't make sense.
    - linkdd 6y ago
      > OS upgrades, deprecations, maintenance are a thing that makes your binary stop working all of a sudden. Good thing I deploy with Docker/Kubernetes and I have a CI/CD pipeline that will warn me about such cases. > It's like choosing prolog in production, finding out that there is no libraries for it and then hacking together Go binary together with it. Hence this thread. Erlang/Elixir brings so much to the table when it comes to distributed computing. Kubernetes + Elixir + libcluster + horde, I don't know any other language that gets better than this. And yet, there are still some librairies I would need, that I don't want to implement myself, because I don't trust myself to implement them properly (see other comments where I talk about iCalendar). So yeah, I need a "hack", and it makes sense to me to delegate the complexity wherever I can. You could argue that I need to create a microservice, and make an HTTP call. But why make an HTTP call when I can just call the binary without the network layer in between?