If you must default to dark mode that’s your choice but I’d love to see a light mode toggle somewhere prominent.
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.
Dark mode feels correct, but it is hostile. Now blue light on the other hand... you should get filters for your monitor/glasses.
Love how dedicated you all are to providing clear entrypoints and being thoughtful around documentation!
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.”
I'm hoping to find a reason to use it soon.
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.
Do you have a program that doesn't need to run fast?
(wip, no guarantees, this is the engine i use)
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.
But it's blazing fast which is good to see.
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.
>Might as well use LLMs for the whole thing next time, since we will be accused of doing so anyway! :D
The only sloppy aspects that stand out to me are the needless animations/transitions.
Hoping Elixir continues to thrive. It is such a great language (and such a great language for AI coding too!)
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.
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.
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 :-)
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!
You can get substantial performance improvements by using guards though. See what Wings3D does with is_float() everywhere in hot numeric-heavy code.
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.
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
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.
EDIT: shipped!
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?
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
If i go full dynamic, why not use pure erlang instead?
I hope you don't use discord or rely on pagerduty.
I also worked on all of the copy myself, collecting feedback from core maintainers as I went. The new tagline was a suggestion from Theo which we iterated on. I did use LLMs as an assistant, but I did not ask it to generate the content.
Might as well use LLMs for the whole thing next time, since we will be accused of doing so anyway! :D
FWIW, I don't think the site fits the LLM template. The scroll through the use cases is particularly nice.
And thanks for Elixir. I love it, and the agent + tidewave loop is a joy to use!