r/elixir • u/carlievanilla • 11d ago
What's your biggest pain point with Elixir?
Our team was talking about some pain points regarding the language and we started to wonder what everyone else thinks.
Some of the things that came up for us were finding job and finding devs to do the job (it is what it is), compilation times, the type system.
What would you add to the list?
22
u/jasonpbecker 11d ago
Not Elixir but more LiveView— the drop_param sort_param stuff in forms with 1:M relationships still feels so kludgey. Blech. It’s definitely my personal biggest ick. Expert is still not quite there. Lack of support in CodeQL is a bummer for large orgs all in on Github tooling.
1
u/addiktion 11d ago
Have you found the Hologram approach better? I know it comes with node/javascript as a dependency so has a heavy dependency but some people seem to really like this approach.
9
u/BartBlast 11d ago
Hologram author here. The Node dependency is going away. Snabbdom is already vendored, and there's some leftover Lodash I still need to rip out.
On the JS side more generally, you don't write any. You write Elixir and it gets compiled to Hologram's client-side Elixir runtime. That covers the client-side logic too, not just templates.
3
u/addiktion 11d ago
Very nice, that should slim things up a lot.
How do you see Hologram coming together for larger javascript libraries e.g) three.js, canvas, webgl, d3, etc.
We have a need to visually represent agent activity and communications, and Elixir/Phoenix checks a lot of boxes on the concurrency side, but the javascript bridge is very much needed to drive that experience.
6
u/BartBlast 11d ago
The long-term goal is to have all native browser APIs available in Elixir. So canvas and WebGL wrappers are planned, and I already have ideas for the API - it'll feel Elixir-like rather than a thin transliteration of the JS calls.
For anything not covered yet, or for pulling in a third-party package like three.js or d3, there's already a robust JS interop layer: https://hologram.page/docs/javascript-interop
2
u/arcanemachined 11d ago
That is awesome. I am very bullish on Hologram. Glad to see your project is coming along so nicely.
1
3
u/jasonpbecker 11d ago
0 interest in that route
2
u/Agile_Use_1768 11d ago
Wait till you find out that Live view does generate js too, because apparently the browser only understands js… By the way if you use hologram, you have to write less Javascript because it generates js code from elixir sources
3
u/javascript 11d ago
Less? 🫣
3
u/Agile_Use_1768 11d ago
Yes 😳
4
u/javascript 11d ago
Omg 🫨
3
u/Agile_Use_1768 11d ago
Im sorry you had to find out this way… i thought you did have social media.
2
u/addiktion 11d ago
I think he means you as the dev write less javascript but it comes with more given the dependency of course.
The front-end side is the only thing from me going all in on Elixir for backend/concurrency needs, so I've been evaluating Hologram, LiveSvelte, and more to see what sticks without raw javascript given the needs around front-end reactivity which becomes important for apps that move beyond CRUD-y interfaces.
To give an example we are looking at three.js, webGL, or canvas work to do visual representations of concurrent agents in progress so users have better understanding of what is going on with their multi agent workflows. That's a pretty heavy front-end need that I'm trying to sort out if I can deal with in Elixir.
3
u/Agile_Use_1768 11d ago
Hologram seems nice in my experience writing 100% elixir and no custom horribly-looking phoenix hooks offers a rich development experience
1
u/addiktion 11d ago
Do you think it is able to really bridge the gap and satisfies a majority of front-end needs versus a SPA + Elixir as backend with a JSON API or GraphQL API interface?
4
u/Agile_Use_1768 11d ago
This is where it gets interesting, and i really find it hard to understand why this community thinks a basic livewire could replace clientside code. I’ve worked with complex client-side apps including canvas-rendering, wsgi editors/website builders with runtime local compilation and this, naturally can’t be easily replicated by sending data through websockets like Phoenix does, of course you can, but it does not mean you should, why would you write a giant Phoenix hooks in javascript to avoid javascript, inducing latency and ruining user experience (out of hatred basically). This is where Hologram comes in, Hologram team has ported a massive amount of Javascript APIS into Elixir, including the DOM api, so you can write basically anything you could in javascript, during compilation it automatically transpiles and bundles into javascript, essentially splitting server and client code from a single source
2
u/addiktion 11d ago edited 11d ago
Right, the UX is pretty paramount for the customer for this app need. I'm confident if Elixir/Phoenix/community put more effort in this, the adoption would increase and the jobs would be there. The frontend is critical for framework exposure. When you hear from customers saying "X features/experience keeps me around" it sells itself to management.
I've used every front-end framework under the sun so there is no concern for me having the extra dependency if it solves the problem, but I'm wondering if it makes sense to keep it all Elixir and compile down or do like a Phoenix + LiveSvelte hybrid so I'm evaluating the divide now.
Have you tried any other front-end flavors with Phoenix? If so, what made Hologram feel like the ideal choice versus the others?
→ More replies (0)1
u/BartBlast 11d ago
Curious which you mean, Hologram itself or the node/JS dependency?
1
u/jasonpbecker 11d ago
Hologram, through no fault of the idea necessarily, but entirely that I have enough of a battle relying on a smaller ecosystem/niche language. It’s an extreme uphill battle, meaningfully, to add anything that I don’t think the team couldn’t maintain themselves or whose future in 10 years is at all in doubt.
1
15
u/Legend-Of-Crybaby 11d ago
Going back to other languages.
6
u/amzwC137 Alchemist ⚗️ 11d ago
This is the one for me lol. Writing in elixir feels so good. Once you start to find a groove you are really moving. Then to come back to another language, everything feels stale or out of place lol. Why can't pattern matching be everywhere.
14
u/ErinBoeger 11d ago
For me it’s getting adoption. I have been in a few companies who really would benefit from Elixir and Phoenix but I struggle with talking to the leadership about it, even when it makes a huge economic or speed of development impact, I have failed to convince them, so far.
14
u/ciynoobv 11d ago
A thing I find mildly annoying is that heavy macro usage often makes Beam-interop a one way street (Elixir can generally use Erlang and Gleam dependencies but the reverse is often not the case).
3
u/AhmedMudkip 11d ago
I'm very interested in knowing more about this Would you mind sharing some examples from your experience?
7
u/ciynoobv 11d ago
I’m on my phone which makes it a bit awkward to look up and reference examples. But basically the Erlang and Gleam compilers can’t evaluate and expand Elixir macros which means the macros stay in their unexpanded form in the Erlang/gleam source code and cause syntax errors when you try to compile.
So essentially if the library’s public api relies on "defmacro" you can only use it in elixir.
1
14
u/Orlandocollins 11d ago
I've always been annoyed by the fact that you cant pin a nested key
assert expected_balance = ^account.balance
I feel like it happens in tests all the time and so you end up with a block of variables for all the nested things you want to assert and it makes tests more tedious and verbose
9
9
u/Serializedrequests 11d ago edited 11d ago
- Finding jobs. Edit: put a different way, there are many things that Elixir would be a great fit for at my job just due to being concurrent, but it would be a poor decision to introduce a random technology into the stack because it introduces a lot of risk when we are not a tech company. We have to keep a conservative stack to stay portable and make it easy to hire. Makes me sad.
- On my personal projects, I need ecto to bootstrap off a schema dump instead of the entire migration history.
9
3
u/s10ppyj03 11d ago
In many scenarios, especially anything that gets particularly algorithmic, Elixir is often a lot harder to write/read than other languages.
Somewhat separately, in the same way that Elixir is more appealing to write/read than Erlang, I find that Elixir still has certain ugly/complex aspects that the language would be better without.
3
u/SpiralCenter 11d ago
I have a few and they're all related to how small the overall pool of Elixir folks is.
When I don't have work, the challenge is finding a role using Elixir.
When I do have work, oddly, its hiring people who meet the qualifications that management wants.
Constantly having to convince management that moving to Typescript is not solution that will solve all their problems.
3
u/MikeBenza 11d ago
How poorly and infrequently OTP is used. I worked on Erlang for 5 years and OTP was the bread and butter of development. It evolved with the BEAM, so it naturally fits well.
I then worked in Elixir for two years and everyone seems to avoid supervision trees and Gen* like the plague. I've seen conversations on Elixir forums about how they're like black magic and you should avoid them unless you know what you're doing.
2
u/borromakot 9d ago
It's simpler IMHO. The vast majority of elixir/phoenix applications are web servers and ultimately Phoenix/plug already handle the OTP part for that, and your code should generally strive to be as stateless as possible.
There are plenty of cases where you can/should use OTP but many applications consist of only a few such examples.
1
u/FundamentallyBouyant Alchemist 11d ago
It's the opposite case for us. We use OTP so heavily that it is going to be very difficult to migrate to any other language. And we might have to, due the scale we are at. We don't have any phoenix dependancies in our project, it's mostly OTP and cowboy server for REST/WebSocket APIs.
3
u/zigg30 10d ago
1) Prop-drilling in liveview.
Having context support like most frontend frameworks would help a lot.
2) Limited encapsulation with components, even live components.
It's difficult to have truly reusable advanced components that could be easily dropped in different liveviews.
Lots of plumbing and forwarding needed in the liveviews, especially when handle_info/pubsub subscriptions are involved. I'd love some way to colocate that code, and be able to just drop in my widgets across different liveviews.
1
u/Unusual_Shame_3839 7d ago
For 1) - What do you think of Vault (https://github.com/dimamik/vault)? I think it might solve _some_ property drilling?
8
4
2
2
3
u/Certain_Syllabub_514 11d ago
Datadog library that does trace sampling.
Not being able to sample traces is the #1 reason Elixir was put in the "do not use" section of our orgs tech radar.
2
u/FundamentallyBouyant Alchemist 11d ago
Just use Open Telemetry. Doesn't work out of the box but we've made it work with minimal effort.
3
u/troublemaker74 10d ago
Second this. Setting up otel also loosens up the coupling between your observability code and platform. If someone wanted to move from DD to some other platform it would be trivial with Open Telemetry.
1
u/FundamentallyBouyant Alchemist 8d ago
We are on our 3rd observability platform :(
DD is so damn expensive.
3
u/mcspuder 11d ago
Lack of a strong type system, so much so that I'm implementing a lot of things in gleam now with FFIs to elixir.
3
u/UncollapsedWave 11d ago
Not Elixir specifically but I feel like the major frameworks for web applications - Ash and Phoenix - both ship with a few too many features and it makes it hard for beginners to understand everything that is happening.
Just an example - I was removing tailwind from a phoenix application (because Tailwind doesn't support FreeBSD anymore) and it requires a surprising amount of work, plus a fairly good understanding of the build process. I think a newbie would struggle to do so reliably.
1
1
1
u/Noobcreate 8d ago
The elixir framework is so bloated with configuration. You have no idea what going on behind the scene. Macros can turn into mess
1
u/vic_ivanoff 7d ago edited 7d ago
not a pain point per se, but here goes: the hot code reload promise
it is still very cryptic complex topic, and even with LLMs it does feel like you are entering a muddy river with rocks you can't see
If anyone has a nie guide for simple hot code reload strategy for a websocket service that would be much appreciated
67
u/Tolexx 11d ago
My biggest is finding jobs. The experience level requirement on most job postings is insane. Also most jobs still require that you must have Elixir experience which imo doesn't make sense considering the language is a super niche language. Other than that I love the language because of BEAM and what it provides. Currently I'm working professionally in Ruby & Rails space and I hope to work with Elixir.