Hacker News Reader

In my experience, the churn is on the systems side, not languages side. The churn happens because someone makes a marginal improvement on some API and makes a nicer marketing copy, and boom, the new most popular JavaScript framework/bundler for this year is born.

Programming languages don't churn nearly as fast (and some degree of existing churn can be attributed to the business model of a PL funded by a company - they have every incentive to push it, no matter how little improvements or different concepts the language brings.)

I think this is also why a lot of older programmers (or even older workers in general) get mistakenly labelled as "resistant to change". It's not that we're unwilling to learn new things, quite the contrary. It's that we've been to enough rodeos to see that many "new" solutions are either pure hype or repackaged versions of stuff that was already tried and found lacking.

I believe this label is less likely to apply to an older programmer if instead of grumbling they were willing or able to clearly communicate problems and consequences of “new” solutions. They would be labeled “old wizards” instead :)

There's some truth to that, but I don't think better communication would really change anything, beyond a few minor victories here and there.

So much of the fetishization of everything "new" comes from a combination of wishful thinking and mental laziness. Especially in larger organizations where decisions are made far from where the work is actually done, there is a tendency to think we can solve problems simply by embracing the newest management fad, enterprise software, etc. It's kind of like the way people think they can get organized "if only they had the right trendy organizer or todo app".

I get the impulse, we desperately want to believe that our hard problems can easily be solved by just changing one thing or buying something. This is the crux of most modern marketing, in fact. Unhappy happy with something hard, just by product or service X.

Older workers tend to know better than others that hard things are hard and that layering some shiny new tool or framework on top of crappy process or a broken business model will not change anything. But saying that out loud, even tactfully, is a very inconvenient truth that will make most managers resent you, and probably label you "resistant to change".

In my experience more often than not, the people the people that accuse others of unclear communication are making an effort into not understanding the message.

But then, I'm not known for fighting against new solutions either, so that experience is probably in a disjoint population. Anyway, I imagine you say that from the position of an "old wizard", but that position is as dependent on a receptive audience as it is on a communicative "wizard".

IF there is a lot of churn you will need to do a lot of communicating, but obviously some times the new will succeed, as time goes by with all the churn and all the poor decisions you would get glum at the prospect at communicating yet again why you think a new solution is not preferable.

I don't actually care though, just I can see this possibility.

They do. It's the nature of new programmers to be prone to hype and marketing and not understand those "clearly communicated problems and consequences" as anything but grumbling.

They’re grumbling because they’ve been there done that, too — tried to communicate the ills of frivolous changes — and nobody was interested in paying attention.

I think we are on the same page that communications are a two-way street. There must be mutual desire to listen carefully and to speak clearly.

My comment above focuses on what the stoics advised to focus on - the things one is in control of changing. In our case, old wizards could control their attitude.

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.

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.

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

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_deploy...

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.

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.

As someone who just started learning Elixir, this comment makes me anxious. I don't think I am going to write some exotic web application or some unique functionality, but at the same time I also don't want to be constantly fighting with the limitations of the stack I choose.

Is it a mistake to spend time learning Elixir?

No. I'd say even if you don't end up using it in your day to day, learning elixir/Erlang and reading Armstrong's thesis are some of the best things you can do for yourself in terms of "system design/programming enlightenment".

Elixir is an involving platform and community. Think about the Ruby community from years ago, a lot of things are missing, but there is a lot of potentials as well. From my side, I started to see Elixir seriously 5 years ago when I need to maintain a big SaaS rails codebase, and in order to support the increasing quantity of users, I need to throw more powerful and expensive machines, and it was hurting us at that time, and after some POCs, we perceived that it would be really interesting to rewrite some parts of our application in Elixir with Phoenix. I think that it's an important tool to have at hand, something that you can reach if needed.

I wouldn't say it's limiting in the sense you can't create certain things with it. You just need to be very prepared to maybe make more choices and also write a lot more libraries that you could potentially find in Python or Ruby.

It also depends on the app you're building. For me I was building a very large app (a video course platform with multiple payment gateways). One limitation I came across with Elixir is there's no official SDKs for Stripe, PayPal, Braintree or Paddle but there are SDKs for most other popular languages. So if you plan to interface with a number of APIs, chances are you're not going to find an official client for Elixir unless the company happens to be using Elixir or are happy to support it (such as Mux).

It could be challenging and time consuming to have to write both your app level features and the underlying libraries. If your goal is to get a web app launched quickly to test it out and you already have experience with Python, Ruby, Node or PHP it's kind of a hard sell to use Elixir. It's mainly because other languages have way more community libraries and frameworks available that cover common web feature use cases. Plus there's a lot more community resources around blog posts, videos, books, courses, etc..

There's also an interesting divide right now in Phoenix around using Live View or not and if you go down the LV route there's very few resources beyond the docs, especially now with LV 0.16 coming out which completely changed the templating system and how components work. It still feels like it's in a pre-1.0 (because it is :D) semi-experimental state. As far as I know there's also no really big success stories with LV. I don't know of any big sites who are using it all-in to drive the entire navigation of their site and all routes.

The above continues to fall in line with my overall feeling of having choice fatigue with Elixir.

With that said if you're interested in it, maybe try to put together a proof concept that focuses on the hardest part of your app and if it works, make a judgment call based on your personal experience. It's possible you'll have better luck than I did. Programming language selection is a very personal choice, especially when you get past libraries choices and start writing code. If Elixir clicks enough for you at a fundamental level maybe it'll be a better choice even if it means having to write more libraries.

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…”

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.

Yup. The ugly truth is that there are too many programmers writing too much code. It's like the idea of too many lawyers (possibly true?) but way worse. Because, of course, we can produce infinite wood and steel and carbon fibre tables at will at the press of a button.

Re: 2nd sentence : How do you come to this conclusion?

Oh, I am a lawyer. I was more recognizing the cliche here, and maybe that was sort of flip. I would say it's probably more like, "a lot of good lawyer brains are wasted on generally pointless this-big-ass-company v. that-big-ass-company disputes."

I'd agree that it's a totally valid sentiment in our industry. In the specific context of an essay on pg's site though -- look at those graphics! :D This seems to me like a dude who is okay with wooden tables.

It is a fashion industry, and so it follows that when everyone has wooden tables you need to sell them a reason to stay in business, repairing wooden tables isn't enough.