And I say this having been an AI skeptic. I understand the way they work, that it’s an average machines producing average output. But the ability to iterate and problem solve in code has only improved. It doesn’t matter if you understand the code if the AI is the only one reading and writing.

Just a year ago coding assistants were a little better than garbage. Now, with improved models and agents I can see a world where we’re just prompting and reviewing. Who knows how long we’ll even have to review.

I’ve experienced some nasty text encoding errors when using DomDocument are those issues inherited by HTMLDocument?

Would love to hear how it goes either way. I have a couple projects that offer an erpc API to establish a contract between nodes, but have had my eye on this module for the same reasons. Started with plain erpc, moved to the API. This would be the next step in the maturation process.

Is this similar to what you are looking for? Alternative to :erpc that limits calls to a single module associated with the rpc server. hexdocs.pm/meshx_rpc/Me...

I suppose it’s either get better at communicating _why_, or if that fails recognize that you’re applying your efforts in fallow fields.

I’m on board with the job. I do the job. I love the job. I am become the job. But to be in a position to do that job, one still has to work with others who may have a different idea of what doing a good job looks and feels like.

How far can you push that before you are perceived as uncooperative and not a good partner?

I’ve been thinking a lot about Winter on Fire

There might be a bit of a bystander effect to overcome. I’ve had the most success saying something to the effect of “hey you 👉, document this” but that has been neither scalable or self-sustaining.

As someone who has been (is?) in that position, I look forward to the outcome, and I hope to learn from how you get others to pitch in.

Maybe an elixir running in a local node using wasm?

I didn’t write my first GenServer until almost a year after shipping a production API in Phoenix! Possible to be very productive in Elixir without using OTP directly.

Yes, separate FE and BE apps. My point was that if you have dedicated FE engineers, dedicating them to FE the Elixir way is hard to sell.

So I and my org are examples from the masses where whether it’s clicking or not isn’t the issue. We face a harder problem of changing perception of Elixir from exotic to boring and safe enough for large enterprise. If that changes, Saša’s reply becomes obvious to all; LV is just a boring GenServer

What I mean is we’re not gonna see critical mass adoption of Elixir/Erlang in enterprise because the LV API got better. We don’t use LV; everything is BE where ergonomics are great and performance is ⚡️. I’ve still had mgmt and sr engs tell me we shouldn’t adopt Elixir because it’s not widely adopted

Not sure it’s the lang itself. We’ve managed to adopt and train our team on it. Training covered GenServer on day 1. Team pretty much got it. Engs don’t struggle. Mgmt struggles, and that stifles adoption. Been on the same Why Elixir? convo for 3 yrs. Always about staffing and transferrable skill.

This is what has held us back from pushing for _any_ FE work in Elixir. It is great if you are a small team of full stack Elixir engineers. If your team has a BE/FE guild model, anything Elixir FE (esp LV) is too foreign for most, and not transferrable to anywhere that is not an Elixir shop.

He has updates his Elixir For Programmers course on Coding Gnome. How I learned Elixir! Will second (fifth?) Pragmatic Studio, though. Still using the patterns from their Absinthe course.