ricketycricket

I maintain Elixir and Rails applications. In my opinion, almost all LLMs handle Elixir better. I suspect, though do not know, being an immutable functional language and composing applications in a functional style makes it easier for the models to "reason" about the code and state. I learned very quickly that this is my preferred language for that very reason.

Additionally, the features available in the BEAM and OTP mean the agents have built-in tools for many things that would require reaching for 3rd-party libraries or even additional services. This means less variability in design as the models will happily use all the language features human developers would have to learn about and understand over time to use effectively. Not that this isn't important, but I believe models do a better job steering you to obvious and optimal solutions with Elixir.

The new type system is only going to make it better.

I had a similar experience, but it worked just well enough that I wanted to try my own similar experiment, but using a functional API in Elixir and giving the agent some introspection tools. I'm very much a novice to this space and learning as I go, but I've been able to make some interesting projects with the library so far, which is all I really want to do: https://smith.hexdocs.pm

If you want to build by hand, there is a Kino renderer to build your projects interactively in Livebook, which is actually surprisingly helpful for learning.

It legally wasn't harassment. If it was, he would have not been let go. That word means a real thing and this was not it.

There’s absolutely nothing existential about a tiny powder that just combusts very quickly.

Said the man with 6 fingers.

"Hey Claude, did Claude do a good job?"

Just build Mac apps then. Claude Code can help you whip up real native apps without any Glaze dependencies just fine. I’ve built 4 Mac and iOS apps in the last 6 months for my own use. I even have my own HN app for iOS and Mac.

Here are some thoughts on it from José Valim: https://dashbit.co/blog/why-elixir-best-language-for-ai

LLMs absolutely understand and write good Elixir. I've done complex OTP and distributed work in tandem with Sonnet/Opus and they understand it well and happily keep up. All the Elixir constructs distinct from ruby are well applied: pipes, multiple function clauses, pattern matching, etc.

I can say that anecdotally, CC/Codex are significantly more accurate and faster working with our 250K lines of Elixir than our 25K lines of JS (though not typescript).

I have a `codex-review` skill with a shell script that uses the Codex CLI with a prompt. It tells Claude to use Codex as a review partner and to push back if it disagrees. They will go through 3 or 4 back-and-forth iterations some times before they find consensus. It's not perfect, but it does help because Claude will point out the things Codex found and give it credit.

I've been using a development server for about 9 years and the best thing I ever did was move to a machine with a low-power Xeon D for a time. It made development painful enough that I quickly fixed the performance issues I was able to overlook on more powerful hardware. I recommend it, even just as an exercise.

> I've been coding for decades already, but if I need to put something together in an unfamiliar language? I can just ask AI about any stupid noob mistake I make.

So you aren’t still learning foundational concepts or how to think about problems, you are using it as a translation tool. Very different, in my opinion.

It's not though. Processes can be supervised and crashes can just lead to "restart with good state" behavior. It's not that you don't try handling any errors at all, you just can be confident that anything you missed won't bring the system down.

And Elixir is strongly typed by most definitions. Perhaps you mean static?

Twitter clone in 15 minutes: https://www.youtube.com/watch?v=MZvmYaFkNJI

LiveView uploads are baked in, previews and all. Everything else you list is included in the Flop library, if you want something off the shelf. In rails you are still including Kaminari or whatever other gems for all this too, so this is really no different.

That's so disappointing to hear. I have an intern who hadn't touched Elixir 4 weeks ago who is already making meaningful PRs. She's done the PragProg courses and leans a bit on Copilot/Claude, but she's proving how quickly one can get up to speed on the language and contribute. To hear that a major company couldn't bring resources up to speed, to me, shows a failure of the organization, not the language or ecosystem.

From the example: "Oh no, I'm really sorry to hear you're having trouble with your new device. That sounds frustrating."

Being patronized by a machine when you just want help is going to feel absolutely terrible. Not looking forward to this future.

Performance of what, exactly? Hard to beat the concurrency model and performance under load of elixir.

Elixir is gaining set theoretic type system, so you are showing up at the right time. https://hexdocs.pm/elixir/main/gradual-set-theoretic-types.h...

You mean like Typescript, an add-on that transpiles to Javascript?

Elixir/Phoenix is compiled.

Bandit is now the default in Phoenix.

> The comment I responded to hand waved away consuming almost 50% of your pps on heartbeats every 30 seconds as "no big deal".

> The network saturation is just a necessary cost of running such a massive cluster.

I think this actually answers it perfectly.

1. If you are running 1K distributed nodes, you have to understand that means you have some overhead for running such a large cluster. No one is hand waving this away, it's just being acknowledged that this level of complexity has a cost.

2. If heartbeats are almost 50% of your pps, you are trying to use 1Gbe to run a 1K-node cluster. No one would do this in production and no one is claiming you should.

3. If your system can tolerate it, change the heartbeat interval to whatever you want.

4. Don't use distributed Erlang if you don't have to. Erlang/Elixir/Gleam work perfectly fine for non-distributed workloads as do most languages that can't distribute in the first place. But if you do need a distributed system, you are unlikely to find a better way to do it than the BEAM.

Basically, it seems you are taking issue with something that 1) is that way because that's how things work, and 2) is not how anyone would actually use it.

Do you though? M4 is what is on the market now and this chip is just coming out. Maybe they are on different processes, but you still have to compare things at a given point in time.

That's one reason I like the stainless (now Titanium) models. They have sapphire crystal instead of glass and I haven't had scratches in years. Scratches on the body are just patina.

Sorry you are having so many issues. That has not been my experience with elixir-ls either locally or in Codespaces. Just want to say that when you do get it working, it does indeed have that and many more features. If you are interested, the Elixir slack is very active and helpful and there is a #language-server channel.

May not answer all your questions, but this may be a good starting point: https://hexdocs.pm/nx/Nx.Defn.html

> except if the tokenizer or whatever doesn't follow a particular format but in that case you just upload it to some free web service and make a PR with the result and reference that version hash specifically and it'll work.

May I ask to which service you are referring?

Out of the box, Phoenix applications respond to simple http requests in times measured in microseconds. What appreciable improvements from that do you get with Python? And considering how much of your total request time is not processing by the language (db calls, network latency, etc.), why would you decide on a language purely on the minor speed improvement of a small part of the overall picture? I’ll gladly trade what might amount to a few ms of request time for the concurrency model, scalability, and latency characteristics of Elixir and the BEAM.

To each their own, I suppose.

Ortex exists to run ONNX models: https://github.com/elixir-nx/ortex

I built this last March. It captures audio from a live HLS stream and transcribes and translates into 18 languages on the fly. Used by a customer with about 25K international employees for their internal events. Works surprisingly well.

I haven't been able to bring up a clustered Elixir server in hkg without experiencing netsplits every 5-10 minutes. ewr, ord, and cdg have been totally reliable.