ricketycricket

"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.

Looks like it is an external library[^1]. Readme states it is experimental and lists some limitations.

[^1]: https://github.com/gleam-lang/otp

You are wholesale calling people ignorant over a technology decision.

When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."

no error checking at all (I assume it just panics or exception?)

In Elixir, bang functions per convention will raise on error. `get/2` will return error tuples allowing you to handle errors. In fact, get!/2 just calls get/2 and raises for you[^1].

no mention of JSON at all

Req is the most "batteries included" Elixir HTTP lib out there. I can't speak for Wojtek, but I believe the goal was to make Req extremely easy to use in scripting or things like LiveBook without having to do much work. That being said, the automatic decoding is mentioned in the readme[^2] and the docs[^3].

if "body" is JSON, how do you even get the raw body, or can you?

Per the docs[^3], you can either skip with the `:decode_body` option, or just build your own request using only the steps you want.

just seems over engineered/over fitted whatever you want to call it.

Fair, but again, this library is designed to be on that end of the spectrum. There are plenty of other libraries further down the stack that you can use. I am partial to Finch[^4], upon which Req is built.

To address the sibling comment about "Let it Crash", the language allows you to easily recover from crashes, but that is for resiliency, not error handling. In practice you would use the non-bang get/2, pattern match on the response, handle any errors, perhaps use Kernel.get_in/2 to safely traverse the map, etc. The example provided by the author is not "production ready".

[^1]: https://github.com/wojtekmach/req/blob/v0.3.11/lib/req.ex#L3...

[^2]: https://github.com/wojtekmach/req

[^3]: https://hexdocs.pm/req/Req.Steps.html#decode_body/1

[^4]: https://github.com/sneako/finch

Recommendation seconded. I'm only to chapter three due to time constraints, but it is well written and approachable for someone lacking ML experience.

davidw is right that ports are somewhat limited, but I haven't had much trouble doing what I need with FFmpeg in particular. I used the bash wrapper from the docs for Port [^1] and it has worked well.

When a stream starts I start a supervisor that then starts a GenServer to manage the port. On init a port is started for FFmpeg (using the above bash wrapper) with args that sends 16-bit PCM audio back to the port through the `handle_info/2` callback.

When a new live HLS segment is downloaded by FFmpeg the entire segment's audio is sent to the GenServer all at once (could be a few handle_info/2 calls, but it happens quickly). Since I want to work in small fixed chunks, I send the segment's audio to an AudioBuffer GenServer (started as a sibling under the same supervisor). This buffer uses binary pattern matching to segment the audio in chunks exactly 2 seconds long while keeping any remainder in the GenServer's state for the next buffer event. I then send the chunks to another ChunkBuffer GenServer that pops chunks at 2-second intervals for processing.

Since everything is supervised, if (when...) FFmpeg crashes the supervisor just restarts it. Meanwhile, the audio in the buffer is still processing and nothing goes down. There might be a duplicate word or two in the transcription if the restarted port processes a segment again, but everything keeps running smoothly.

For even more reliability, I have the application running clustered across four locations in the US, EMEA, and APAC using libcluster[^2]. The stream supervisor is started under a Horde.DynamicSupervisor[^3] with a custom distribution strategy. The strategy prefers the region closest to the company HQ, but if it goes down, the processes will be restarted in another region.

[^1]: https://hexdocs.pm/elixir/1.13.4/Port.html#module-zombie-ope...

[^2}: https://github.com/bitwalker/libcluster

[^3]: https://github.com/derekkraan/horde