141–150 of 297 posts
Earlier quoted context omitted.
"Also, I've read some comments where people mention "we don't need redis", "we don't need workers" everything is so much easier. That was our thinking at first. But then you realize on deployments you will lose your cache, or your background jobs, etc. So you have to persist them either in mnesia or in the database. At that point you're just reinventing your crappy undocumented and untested version of delayed_job...…
I'm confused by the extent to which you believe the things that Erlang/OTP and the BEAM do have been entirely replicated by other ecosystems. I think you're quite right that distributed systems engineering and threaded programming as a whole has moved in the direction of Erlang on a lot of fronts, but I don't really see the parallels (no pun intended) at the language level. Most popular languages still depend on coop…
One of the reasons I make a bit of an accusation that the people bedazzled by Erlang/Elixir may be not very experienced is that a common take away from the community I have repeatedly noticed is the belief that if another language doesn't have exactly what Erlang has, warts and all, it doesn't have what Erlang has. Thus, I see in many other languages various attempts to port the exact thing Erlang has out into that other language, when in fact the other language already has solutions to that problem, even if they aren't exactly how Erlang solves it. [1]
While I personally exceedingly strongly agree that the Erlang-like threaded approach is vastly superior to manually explaining the asynchronous-ness of your code to the compiler, it still remains the case that "async/await" largely solves the problem of handling millions of threads at a time in those languages that support it, and even if that particular element of it is inferior to Erlang, it will be compensated for by the wide variety of other things that are superior. Just because it isn't exactly like Erlang doesn't mean it's not decent solution. Moreover, my exceedingly strong agreement is also, like, my opinion, man, and there are plenty of people who disagree with me and consider async/await superior, and they would account this as simply being better than Erlang/Elixir.
In the 1990s and the 200Xs, Erlang had solutions to problems that no other language had solutions for, or where Erlang's solutions where clearly head and shoulders above. In 2020s, Erlang no longer has anything that it uniquely has the solution for, even if the exact Erlang solutions don't exist elsewhere.
[1]: I wrote about this recently at https://news.ycombinator.com/item?id=26833616
We’ve skipped so many additional things like Redis, Memcached, Sidekiq and tons of libraries because it’s so easy to write a module to replace stuff. Switched from ruby to elixir 4 years ago and the only time we touch ruby is to maintain some old system. It’s so darned easy to add functionality to an exiting app that you have to be careful of bloat. And the functional paradigm is like second nature now. It’s hard to…
My company is moving away from it. We built a few services but after a few years some of the original people that introduced it left the company and it became very difficult to hire for. New hires were either people wanting to learn (so we had to spend a good bunch of resources into teaching + end up with a system built by noobs to the language) or very expensive developers with a lot of experience in erlang and elix…
Earlier quoted context omitted.
I'm confused by the extent to which you believe the things that Erlang/OTP and the BEAM do have been entirely replicated by other ecosystems. I think you're quite right that distributed systems engineering and threaded programming as a whole has moved in the direction of Erlang on a lot of fronts, but I don't really see the parallels (no pun intended) at the language level. Most popular languages still depend on coop…
"I'm confused by the extent to which you believe the things that Erlang and OTP and the BEAM do have been entirely replicated by other ecosystems." One of the reasons I make a bit of an accusation that the people bedazzled by Erlang/Elixir may be not very experienced is that a common take away from the community I have repeatedly noticed is the belief that if another language doesn't have exactly what Erlang has, war…
My company is moving away from it. We built a few services but after a few years some of the original people that introduced it left the company and it became very difficult to hire for. New hires were either people wanting to learn (so we had to spend a good bunch of resources into teaching + end up with a system built by noobs to the language) or very expensive developers with a lot of experience in erlang and elix…
> Most of what you get from elixir in terms of redundancy, high availability, etc you can have that anyway from kubernetes, heroku or any PaaS.... you will need more than 1 server anyway, so... Yeah, last time I tried to get a hang in Erlang I felt it was trying to solve stuff that is already being solved by my infrastructure in a language agnostic way.
If you are a RoR dev, Elixir will feel like a breeze. As someone who does Haskell in their day job, I miss static, powerful type-systems. That being said, the ecosystem is wonderful. Plug, Phoenix and Ecto are exceptional libraries!!
Do day jobs in Haskell actually exist? Are you working in academia?
Several years after Yahoo! acquired Viaweb I was having lunch with the then-VP in charge of Stores and other business products, who was not from the original Viaweb team. The Yahoo! team was rewriting Stores in C++ (and Perl, apparently from a current Google search, although I only remember him mentioning C++). He kind of rolled his eyes when he said for some reason the original team wrote it in Lisp. He said it was hard to hire Lisp programmers to join the team.
PG was not well-known yet, so even if we could just search the web to find his reasoning for using Lisp (the article was written in 2001), we wouldn’t have thought of searching. But even if we had found it, I don’t think it would have mattered. There’s a different set of advantages and tradeoffs for a small team building a new product, when they are focused on fast development and growth and they come from a similar background, vs. a team in a larger company that has people coming and going and wants the ability to hire from the general developer pool without having to train everyone on a less-common language.
Disclaimers: this is a generalization, of course. You might be able to point to counterexamples. Some larger companies are more willing to hire language specialists and experts.
I’m just relaying what I was told. Please don’t angrily debate me on the benefits of languages like Elixir and Lisp. Your anger would be misplaced. Personally I absolutely love those kinds of languages and would much, much rather use them than something like Java [1]. That’s why I stayed a hacker my whole career and never became a manager.
Earlier quoted context omitted.
Don't focus on tooling, focus on their complaints about not having enough senior engineers familiar with the language. We're in a similar boat. I don't know the full history of how we came to use Elixir, but I would wager that early on in the company, someone really loved it and evangelized it. But now, we don't have that many senior people who know it well. I can count the ones I talk to regularly on one hand, and o…
What do you think has been the difficulty for people at your company learning it? I encounter a lot of devs, especially experienced devs who pick it up very rapidly compared to what I've ever seen with JavaScript, ObjC, Rust or other most other languages I've spent time with.
The language itself is very different from the C-like imperative languages most everyone knows, so there's a bit of a ramp-up from that, but for basics, people can be released into the codebase within a month.
But when things go wrong, or when you need to do something more complicated, things get difficult. It's much more difficult to google around for solutions. When Dialyzer is spitting out strange errors, hunting down their causes and solutions is challenging without someone who understands it around.
I feel like 99% of Typescript/Ruby problems have been encountered and enshrined in Stack Overflow and the like, but Elixir doesn't have that sort of volume.
It's a fun language, and worth learning, and I played around with it in a side project, but quickly started running into conceptual roadblocks when it came to (no surpise) the GenServer stuff, and how to actually spin up a stable service that does things in some given way. I probably could have stuck with it, but at that point it felt more like toil than joy, so I decided I'd rather do something else with my time. I'd be fine with going to work for another company working with Elixir, provided that there were people there who can swoop in from above and help me solve my problems.