Hacker News Reader

Comment by ipnon | Hacker News Reader

It's a windfall. Having written the same project in Phoenix and FastAPI/Expo, I assumed LLMs would be better at writing Python and React. But the amount of boilerplate and opportunities for harmful side effects in the code means I quickly generate large amounts of code that I then need to go back and manually grok to align my understanding. With Elixir this loop is much smaller. I generate a small amount of code, check for validity (much easier to verify in a functional language), and repeat this loop.

Until we get superhuman autonomous coding agents the human in the loop grokking the generated code is still the limiting factor. LLMs are marginally better at generating mainstream languages than Elixir, but the generated Elixir code is much easier to understand and modify, and because of the runtime, will practically never crash your system.

View on HN

I can't wait until we get LLMs bitching about being forced to write boring verbose Java code, and demanding to be allowed to write concise, robust, performant Elixir code as a better solution.

And then criticizing you for using vi over Emacs (or vice versa).

They should have plenty of training data. A slight nudge might be enough. They might have some "safety" measures in place to "protect" us from it.

They can already do that, it depends on the system prompt.

>I generate a small amount of code, check for validity (much easier to verify in a functional language), and repeat this loop.

This has been true before LLMs as well. Build small, testable functions and compose them together. That's basically it.

Lol exactly. "LLMs write good code if you make small changes and write tests!" Groundbreaking stuff

I haven't tried Elixir yet, but I've noticed this same effect with Rust or Go, as in what previously would have been syntactic hell without LLMs, becames tighter feedback loops with good errors and testing, and produces much better, cleaner code bases.

interesting how this will shift adoption of languages that are a bit harder to grok for humans, but not really for llms

This leads me to ask if we'll see not only frameworks and libraries, but entire languages created specifically for LLMs to use them well.

I think you missed their point: they prefer Elixir because they find the Elixir code is easier for them/humans to grok, validate, and fix.

I love Elixir, Erlang, and BEAM, but tbh, not crashing is a fairly well solved problem in the web world regardless of language and runtime, in large part due to the request/response nature of things.

Yes, it's true, but what I mean is that in Elixir I can just write the happy path and not crash the system. My Python code requires meticulous exception handling, sometimes taking up half of some functions. It's the design of the BEAM that allows you to focus on just the happy path, and this is really where most user value is derived, and it's the most fun code to write as well.

I am not the best Python programmer! I have crashed prod before, I will admit it. And this requires an alert, scurrying to the nearest terminal, an SSH console, some log spelunking, hopefully just a restart. But I have never had this experience deploying Elixir or Phoenix, and I am by no means the best Elixir programmer. Firefighting is to me the worst part of programming, and through a combination of interactive Elixir shells, process isolation, automatic process restarts, and a philosophy of "let it fail, it's no big deal," it has brought some joy back into my work. That alone is priceless!

I understand Elixir can seem overhyped, and I share that skepticism, but I keep coming back to it over the last half decade or so. This is the best endorsement I can give, I think.

In Elixir, it's almost free to isolate the user who caused them (keyword: "almost"... there are no bulletproof solutions). In most other popular languages used for web programming, it's easy for a crash to affect many users without careful thought to prevent it.

In my experience it isn't almost free. The "problem" being the overloaded nature of processes: their sole purpose isn't to isolate errors, its also to provide concurrency, a sort of access control (since a process goes through its mailbox 1 message at a time), and you also have to consider data access performance characteristics (since sending data across processes is copied).

So in an ideal world yes, you can isolate them, but I've never really achieved this panacea in practice, and its never been anywhere near free to try to suss out a design that optimally achieves all those differing design aspects at once.

Processes are only overloaded in that they are a primitive. I'm not sure if this is what you're implying, but a single process shouldn't be doing all those jobs at once. For example only supervisors should be dealing with error isolation. As for sending large amounts of data between processes, I can only speak really generally here, but one common way is to flip the script and send functions to the data instead of the other way around but ya, bigger topic! When I say for "free" I mean more like my sibling comment where you don't have to think about every possible way something can fail.

As much as people love to hate it, PHP is also really good here. Each request is isolated.

>> and because of the runtime, will practically never crash your system.

"Practically never crash" ignores software bugs, resource exhaustion, or bad architecture

Have you written/deployed Elixir before?

Have you deployed critical systems where human lives depend on?

"BEAM crashes with segmentation fault #7683" - https://github.com/erlang/otp/issues/7683

You dont use NIFs ?

"A native function that crashes will crash the whole VM." - https://www.erlang.org/doc/apps/erts/erl_nif.html

"Who Supervises The Supervisors?" - https://learnyousomeerlang.com/supervisors

1. Yes 2. You didn't answer my question? Your answer ""Practically never crash" ignores software bugs, resource exhaustion, or bad architecture" indicates I think ignorance of actually deploying BEAM applications, and instead just making statements based on things you've heard. Isolating failures in software systems is not a bad thing. The developer can choose the boundaries between the elements of their system up to and including "stopping the entire application if things go wrong".

Instead of answering on the technical merits of an argument, you went for an ad hominem so...? I ask again...do you use NIFs ?

"If the entire computer crashes, you're screwed. you can't really do fault tolerant computation from one machine."

      - Joe Armstrong

And the reason for the quote above is to remind you Erlang/BEAM gives you tools for fault containment and recovery, but not immunity from failure.

Say: Well-designed Erlang systems can fail gracefully and self-heal locally...but they’re only as fault-tolerant as their distributed architecture and ops discipline allows...And we will conclude in a nice agreement. :-)

> Well-designed Erlang systems can fail gracefully and self-heal locally...but they’re only as fault-tolerant as their distributed architecture and ops discipline allows

Correct.

> you went for an ad hominem

Not my intention. I asked a simple question, and you answered a question with a question, effectively gish galloping me with "but there are ways it can crash" except nobody said there wasn't. It stopped feeling like a technical debate at that point.

FWIW, I didn't make the original comment you replied to, I just pointed out that this statement:

> "Practically never crash" ignores software bugs, resource exhaustion, or bad architecture

felt like a surface response to the OPs sentiment of localized failures not tanking an entire software system.

If perfection is your bar, you're going to be looking for a stack for a very long time.

I am not aiming for perfection, just correcting Erlang mythology :-)

I can guarantee you Erlang wont save you from an Ericsson AXD301 switch with a full storage...

What languages/frameworks/runtimes will save you from full storage on a single system?

Apparently Erlang....

The code can crash but it won't often crash your system (unless you use lots of badly tested NIFs, which most people don't), and that's all GP is saying. BEAM isn't magic but it is pretty robust by now.

Tbh I feel like this is not very unique these days, so I'm not sure how this point means a lot, esp in the context of using LLMs for coding. Eg most NodeJS code won't crash your system either (it'll only crash NodeJS).

memory exhaustion is a real thing though. be careful running BEAM applications that do lots of transformations on binary content... PDFs come to mind!

> Until we get superhuman autonomous coding agents the human in the loop grokking the generated code is still the limiting factor.

They never get tired, work for pennies, can search the internet and your code base, follow rules, and iterate on test cases. This is better than I can do, so by my reference point as a human, the coding agents are superhuman already.

Then why do they often produce garbage for me and get stuck in a state where it either “fixes” type errors by casting to any or just straight up getting stuck?

They suck at react-native man god damn.

None of what you're saying really addresses the comment, which is a human needs to review all this or it likely won't work. Maybe they will get that work done faster.

But you have shared your experience, this is my experience.

- They get tired when the context is too big. They also can't be reliably run by themselves, so it doesn't really matter if they can be run at 3AM when I'm asleep, I wouldn't do that.

- Searching the internet with LLMs is ass because it combines the worst of both worlds (remember people have been using LLMs to NOT search the internet).

- It's a toss up whether "iterating on test cases" means follow the rules or get stuck in an infinite loop. I have had the latest and most expensive models ping pong themselves between the same two broken lines of code because they are just LLMs.

I'm enjoying Cursor for now, but I am also working on a string of really basic Laravel apps for a few clients and it still gets things wrong. They are useless for novel problems or niche tech.

Reply on news.ycombinator.com