Elixir-lang.org has a new design
elixir-lang.org
elixir-lang.org
And that’s awesome. We need people like that. But the vast majority of people want to get stuff done, and I have always admired that Jose Valim seems to be one of those people that just “gets” the mix of good technology with its PRACTICAL use rather than just debating programming languages endlessly.
Without elixir, outside of a handful of companies implementing it in their core systems, erlang probably would’ve mostly remained in the domain of the same guys at conferences that passionately debated tabs vs spaces or BDD vs TDD. In fact, I think that’s exactly where Haskell is. I barely hear about it, just like I used to barely hear about erlang.
The rest of us that focus on what we’re building with the technology or the dev UX, etc, would’ve stuck to ruby and other things, if not for elixir.
I say this as someone who has been writing elixir full time since early 2016 and absolutely love the beam. And I’ve yet to edit my first erlang file. It just hasn’t mattered in most of my real world use.
The history of Elixir has its roots in Jose learning Erlang, loving the properties BEAM, but wanting a different language.
All of the principles of the BEAM still exist in Elixir. And a lot of the Elixir semantics come from Erlang, precisely because Jose studied Erlang and the BEAM.
Elixir has some semantic "userspace"-level differences from Erlang (Elixir has protocols, macros, defaults to strings as binaries rather than strings as charlists, among other things) but they are much more similar than they are different. Both are on BEAM, both expression-based languages, both use processes for concurrency, have immutable data, use pattern matching for control flow, rely heavily on OTP, deploy with releases, share (or build on) the same datastructures, have the same performance characteristics, etc. If you know Elixir you pretty much already know Erlang modulo the time it takes to learn Erlang's syntax.
Elixir is a wonderful language and one of my favorite languages.
> Elixir was made by people who don't really understand Erlang
And this is definitely not true.
they made a bunch of tangible improvements
Elixir, if anything, really excels at communicating the intentions of the (occasionally esoteric) architectural demands that the Erlang originally fortified decades ago, often encountered when using OTP. This, alongside that tower of respected Elixir tooling, adhering to Erlang's norms which, once past "mere" interoperability within BEAM, is still supremely important when e.x. minimizing laborious/unusual syntax requirements when using Elixir modules from 'naive' Erlang code. This is part of a more wide-reaching feeling, one of common concerns being important to address in Elixir (and Erlang) for the health of the franchise, not just as grist for the mill of an ancient FP hyperwar, each warring cybergang being willing to die for their preferred juridical interpretation of a bug report.
OT: I wish more funding & development effort went into BEAM itself on making it more performant.
Note: I’m not talking concurrency. I’m talking pure raw performance.
Seems like it’s been a one person show for over a decade on making it faster.
You can get substantial performance improvements by using guards though. See what Wings3D does with is_float() everywhere in hot numeric-heavy code.
Other JITS like V8 will do things like speculative inlining and inserting its own type guards , but if this JIT is "Admittedly an extremely simple one" then it presumably doesn't do much of that.
I suspect once the Erlang/OTP team squeezes all performance in the JIT, they will look into optimizing across modules, which will probably open up many new possibilities, but it requires rethinking some runtime primitives.
You’re an inspiration for many. Thank you.
I’m curious to know what your top 3 hopes for BEAM itself are for the coming years (in any area that you think would make it better).
1. The cross module optimizations I mentioned above 2. Have a WASM target for the runtime itself 3. Make it easier to ship single file executables with the whole VM
But they are really “nice-to-have”s. I have been a happy user for 15+ years!
Knowing what I know now, I would’ve tried to push for a threaded interpreter to get rid of the runtime overhead of dispatching altogether. I don’t know if they’ve changed the architecture of that module much since I left :-)
Hoping Elixir continues to thrive. It is such a great language (and such a great language for AI coding too!)
New site looks great.
https://joearms.github.io/published/2013-05-31-a-week-with-e...
RIP Joe Armstrong you were brilliant.
Does rapid cross-platform deployments with single code-base ease, and with Phoenix channels is very economical =3
The only thing I believe the language's missing is it's own dedicated IDE.
I was involved, years ago, in using Erlang on these devices: https://www.icare-world.com/us/product/icare-eidon/
It was a lot of fun and there were some very interesting challenges for everyone involved.
My usecase is less independent though, that control plane is orchestrating like Lambda/fly.io style workloads on top of firecracker: https://jomcgi.dev/ember
It's super handy. There's no security barrier between nodes. It's a headache if your network is unreliable.
For a chat app, messaging someone becomes a series of steps:
a) look up if they're online (send a message to the presence database service)
b) if you got a process id back, that's the process connected to the user, so send it the message. The process could be on the same machine or not, but the sending api is the same. This is the special part: few other environments make arbitrary messaging between processes/threads/tasks/whathaveyou so pervasive.
c) if you don't get a process id back, the user is offline; send the message to the offline database.
I'm hoping to find a reason to use it soon.
(wip, no guarantees, this is the engine i use)
I first reached for Elixir when Ruby couldn't handle large amounts of websocket messages. It really shines in high-concurrency contexts. I also love Phoenix LiveView and have a couple of side-projects running on it.
For me as a long-term ruby user, though, elixir is not quite as elegant as it could or should have been. Even simple things such as "defmodule Xyz do" feels weird to me.
Do you have a program that doesn't need to run fast?
I eventually gave up because it’s a bit too difficult without a team.
I didn't mind the old one, but I understand that it helps adoption to keep the website shinier.
But, now with LLMs I don't have to fear a loosely typed language, I'd love to give it another go.
Minor nitpick: I believe Elixir and Erlang are strongly typed languages, but for a long time they have both been dynamically typed. With v1.20, Elixir is well on its way to transitioning to a gradually static typed language, and to-date has done so almost purely through inference (except for guards which can explicitly specify type information)
If you buy into the Elixir stack then you now have constraint you could've avoided entirely by avoiding it.
Also for devs there seems to be no premium offered for this talent pool scarcity. With LLMs I think language-specialists are redundant in a large scheme of things. ex) at one of my current remote jobs, I shipped an entire telecom infrastructure with barely knowing Elixir and we brought on contractors to audit the code and they found no issues.
> I shipped an entire telecom infrastructure with barely knowing Elixir and we brought on contractors to audit the code and they found no issues.
Erlang/Elixir experience is rare, because it's not widely used and the teams are small. It's not worth trying to hire for it. Hire for people who can figure it out on the go (amd are willing to give it a try).
You did it, hire other people who seem likely to be able to.
normal market dynamics suggest scarcity demand premiums but this is not the case with software developers it seems.
a) did you pay your Elixir contractors more than you would pay a Java contractor for similar work?
but also...
b) scarcity isn't the only factor in price. Erlang/Elixir developers are scarce, but Erlang/Elixir jobs are also scarce. You need both demand and scarcity to raise prices. Also, it doesn't cost much to turn a willing, good developer into an Erlang/Elixir developer; substitute goods reduce the impact of scarcity.
also c) if you found contractors, but not employees, maybe you weren't willing to pay enough... So maybe the price is higher than you thought?
b) true
c) i think we paid them $100/hr for two months which is fair
Congrats on being one of the mythical developers that manages to get AI to write perfect code consistently!
if you treat it like any architecture then there's all sorts of techniques and knobs to produce consistent output
Love how dedicated you all are to providing clear entrypoints and being thoughtful around documentation!
But it's blazing fast which is good to see.
EDIT: shipped!
If you must default to dark mode that’s your choice but I’d love to see a light mode toggle somewhere prominent.
Dark mode feels correct, but it is hostile. Now blue light on the other hand... you should get filters for your monitor/glasses.
For monochrome, light background and dark text work better.
One consequence of software recently supporting light and dark schemes is that UI designs end up committing to all white or all dark, rather than tastefully choosing a color scheme that best frames its content in context.
The only sloppy aspects that stand out to me are the needless animations/transitions.
>Might as well use LLMs for the whole thing next time, since we will be accused of doing so anyway! :D
Sorry, I meant the subjects (LLMs, ML, AI) are intertwined, not the people. But what I was getting at with my comment is that (IMO) most people see them as distinct things, even on HN where most know that LLMs use ML. As an analogy, it's like physics versus mathematics: separate subjects in most everyone's mind, and even separate academic departments, but physics is still math.
Minor typo in the Erlang card:
“Elixir also excels at IoT, distributed systems, and everything the Erlang is renowned for”
should probably be “everything the Erlang VM is known for” or “everything Erlang is known for.”
If i go full dynamic, why not use pure erlang instead?
Gleam on the other hand has a actual type system. It still young but i can see what it offers.
So syntax for me is totally pointless and just noise.
I hope you don't use discord or rely on pagerduty.