6 ms·

I resonate with this. The churn I find most demoralizing is in the library/module/component space. I’ve been pushing myself to learn elixir these last few mont

I resonate with this. The churn I find most demoralizing is in the library/module/component space. I’ve been pushing myself to learn elixir these last few months. This is, by the comments of many, more of a niche language. I like the language’s novelty and it has caused me to think in new ways. So Paul is righ in this pint. But when I want to send an http request, there must be at least 10 choices on hex to choose from. The one that is a hit this year will be passe’ next year. When I watch the traffic in the Phoenix slack channel, the “stack” of libraries combined seems overwhelming. The same goes for people talking about front end apps.

coding123 5y ago
You hit a nerve there - our company has gone through 4 "choice" http client libraries in the past 4 years. (We're a JS/TS environment). axios, request, superagent, fetch.
yawaramin 5y ago
Just curious, why not use OTP's built-in httpc? https://erlang.org/doc/man/httpc.html https://erlang.org/doc/man/httpc.html
- ramchip 5y ago
  Not OP, but httpc isn't secure by default. It works fine if you hold it correctly but I wouldn't recommend it to someone really new to the language. https://erlef.github.io/security-wg/secure_coding_and_deployment_hardening/inets https://erlef.github.io/security-wg/secure_coding_and_deploy...
- olikas 5y ago
  httpc is good for a one off request, but it is not very up-to-date with the latest features of the web. So building application logic on top of it is not ideal.
nickjj 5y ago
Churn and choice are what keeps me on the fence with Elixir too. Over the last few years I went from very excited and built a few things with it to "maybe try again later". It's just not fun to be in a constant state of package fatigue, especially when a lot of semi-popular libraries are maintained by 1 person. If that 1 person leaves that entire bit of functionality becomes a liability to your application because it's unrealistically demanding to be a solo developer or small team and be responsible to maintain a bunch of libraries that become unmaintained but then also build your application. This is IMO especially true with a language as powerful as Elixir with macros. Picking up and reading someone else's code can either feel natural or be really hard, to the point where looking at it doesn't feel like the language you know. This makes it doubly hard to read 3rd party library code because you're learning the other person's code and have to mentally deconstruct a lot of advanced patterns if they use them. I don't consider myself that good of a programmer but there's a lot of times where in Elixir, phrases like "this is impossible for me to understand" come up when I've written hundreds of thousands of lines of code in Python but never thought this. I sometimes had the "what am I looking at?" feeling with Ruby too btw. As for library availability, this is a problem that doesn't come up as often with more main stream web frameworks, at least not in the Python and Ruby eco-system. Sure things go in and out of fashion but both languages have frameworks that include more batteries included or the community has gotten so big that there's a bunch of independently developed libraries that most of the community got behind and supports it so well that it becomes a no-brainer to use it. So that's what keeps me on the fence and I think some of these problems can be solved with time, but time is a scary thing because waiting a few years feels like an eternity and the outcome after waiting a few years might be waiting a few more years. At some point you need to build whatever you're building and run with it without looking back. But I think this really comes down to personal preference. I used to think I wanted unlimited choice and an endless world of possibilities. I don't. I want to build web applications quickly using the most straight forward code I can think of and get as many batteries as included as possible while leaning on / contributing back to a massive eco-system. I don't want to be on the front lines of building a new eco-system. I still do think in the very long term (5+ years maybe) Elixir could be a good match for me once there's a lot of libraries that have hit critical mass. There's plenty of people using it successfully now, and I'm happy there are people who like being closer to early adopters and setting up the initial ground work for an eco-system.
travisgriggs 5y ago
It’s not just how many variations of a given component there are, it’s all the many components I have to become aware of to use, each written by a different author with possibly diffeeent idioms, with varying degrees of interoperability. One has to have an http package, an auth package, a json package, a structure modeling package, the list just goes on and on and on. And so many are often derivative dependencies. It’s not just elixir. When I look for help in the Kotlin slack, the responses are just a firehouse of “you need Zanzibar, no Algolly, try Firetruck, do Conduct, you might want xWyze…”
ramchip 5y ago
All the passé options still work fine :) But yes. It's true http clients have churned quite a bit. Other things are settling better, for instance Ecto, Phoenix, Jason are very popular and stable.

coding123 5y ago

You hit a nerve there - our company has gone through 4 "choice" http client libraries in the past 4 years. (We're a JS/TS environment). axios, request, superagent, fetch.

yawaramin 5y ago

Just curious, why not use OTP's built-in httpc? https://erlang.org/doc/man/httpc.html https://erlang.org/doc/man/httpc.html

ramchip 5y ago
Not OP, but httpc isn't secure by default. It works fine if you hold it correctly but I wouldn't recommend it to someone really new to the language. https://erlef.github.io/security-wg/secure_coding_and_deployment_hardening/inets https://erlef.github.io/security-wg/secure_coding_and_deploy...
olikas 5y ago
httpc is good for a one off request, but it is not very up-to-date with the latest features of the web. So building application logic on top of it is not ideal.

nickjj 5y ago

Churn and choice are what keeps me on the fence with Elixir too. Over the last few years I went from very excited and built a few things with it to "maybe try again later". It's just not fun to be in a constant state of package fatigue, especially when a lot of semi-popular libraries are maintained by 1 person. If that 1 person leaves that entire bit of functionality becomes a liability to your application because it's unrealistically demanding to be a solo developer or small team and be responsible to maintain a bunch of libraries that become unmaintained but then also build your application. This is IMO especially true with a language as powerful as Elixir with macros. Picking up and reading someone else's code can either feel natural or be really hard, to the point where looking at it doesn't feel like the language you know. This makes it doubly hard to read 3rd party library code because you're learning the other person's code and have to mentally deconstruct a lot of advanced patterns if they use them. I don't consider myself that good of a programmer but there's a lot of times where in Elixir, phrases like "this is impossible for me to understand" come up when I've written hundreds of thousands of lines of code in Python but never thought this. I sometimes had the "what am I looking at?" feeling with Ruby too btw. As for library availability, this is a problem that doesn't come up as often with more main stream web frameworks, at least not in the Python and Ruby eco-system. Sure things go in and out of fashion but both languages have frameworks that include more batteries included or the community has gotten so big that there's a bunch of independently developed libraries that most of the community got behind and supports it so well that it becomes a no-brainer to use it. So that's what keeps me on the fence and I think some of these problems can be solved with time, but time is a scary thing because waiting a few years feels like an eternity and the outcome after waiting a few years might be waiting a few more years. At some point you need to build whatever you're building and run with it without looking back. But I think this really comes down to personal preference. I used to think I wanted unlimited choice and an endless world of possibilities. I don't. I want to build web applications quickly using the most straight forward code I can think of and get as many batteries as included as possible while leaning on / contributing back to a massive eco-system. I don't want to be on the front lines of building a new eco-system. I still do think in the very long term (5+ years maybe) Elixir could be a good match for me once there's a lot of libraries that have hit critical mass. There's plenty of people using it successfully now, and I'm happy there are people who like being closer to early adopters and setting up the initial ground work for an eco-system.

travisgriggs 5y ago

It’s not just how many variations of a given component there are, it’s all the many components I have to become aware of to use, each written by a different author with possibly diffeeent idioms, with varying degrees of interoperability. One has to have an http package, an auth package, a json package, a structure modeling package, the list just goes on and on and on. And so many are often derivative dependencies. It’s not just elixir. When I look for help in the Kotlin slack, the responses are just a firehouse of “you need Zanzibar, no Algolly, try Firetruck, do Conduct, you might want xWyze…”

ramchip 5y ago

All the passé options still work fine :) But yes. It's true http clients have churned quite a bit. Other things are settling better, for instance Ecto, Phoenix, Jason are very popular and stable.