mrdoops

It's very nice updating Elixir, having no breaking changes across my many projects and it then the compiler just finds bugs for free. I'm so spoiled.

Solar is great but the bottleneck is on battery capacity to carry those noon hours into evening for peak usage. Last I checked we had plenty of lithium and are mostly held back on refinement.

Thanks, I might hit you up when I'm in the weeds of that feature.

Any takeaways on using Fly APIs for provisioning isolated environments? I'm looking into doing something similar to Phoenix.new but for a low-code server-less workflow system.

Manufactured consensus is everywhere there is enough attention to incentivize such an effort. The worst by far is Reddit.

The important thing is to know fundamentally "why" a rule exists and what goal / organizational objective it's existence and constraints provides. Then breaking it can be productive if it meets the same ends. This usually puts the rule breaker at conflict with people in the organization who put adherence to process higher in priority than the actual organizational goals.

Main limitation of these kinds of products is that the graph/workflow itself is not very expressive of dataflow options. Eventually you need map, reduce, and state machines and likewise concurrency and durable execution. It's not easy to have a high level declarative tool but also expose powerful programming primitives; at some point technical need-to-knows cross the point where you might as well have the user write code.

Most expensive part of the typical web app is the coordination cost between front and backend devs. Thus the rational to have 1 dev implement full stack. But the trade-off for coordination costs are heavy context switching and knowledge costs to know both ends. Neither option is very ideal and most companies have accepted the coordination costs.

But LiveView just ignores these problems and does full stack without the heavy costs. Elixir/Phoenix/LiveView is a tool-set for maximizing how far one dev can go.

You'd think this would be a selling point in many companies: to have less devs ship more features but those heavy SPA stacks let middle managers rationalize hiring bigger teams. LiveView is for shipping - not stalling.

The canonical paper on handling software failures: https://erlang.org/download/armstrong_thesis_2003.pdf

IMO the big win for Elixir/Nx/Bumblebee/etc is that you can do batched distributed inference out of the box without deploying anything separate to your app or hitting an API. Massive complexity reduction and you can more easily scale up or down. https://hexdocs.pm/nx/Nx.Serving.html#content

And there's also a scale to 0 story for when you're not using that GPU at all: https://github.com/phoenixframework/flame

1 language/toolchain. 1 deployable app. Real time and distributed machine learning baked in. 1 dev can go really far.

Yeah modern ML is not really at all comparable and they're more complementary than modern approaches replacing rules. All these agent frameworks and platforms cropping up will be using things like rules, workflow DAG models and so on as the execution engine with LLMs embedded as steps and/or to construct a workflow.

Likewise either with knowledge graphs or using LLMs to generate possible predicates and constraints to run against a rule engine or backwards chain through facts is a way to minimize hallucinations of generative models.

My research went in similar directions although I was looking at RETE for rule evaluation as part of a general purpose workflow engine with rules as just one part.

Incremental view maintenance is different enough from rule composition and evaluation that the model diverges to be more optimal. Collections of tuples and instead of DAGs lots of cyclical loops to continue computation of the diffs.

There are deep and intrinsic space or time trade offs so many of the modern approaches moved toward natural dataflow concurrency, and streaming semantics where space or time trade offs can be chosen at runtime through batching and data context opposed to early RETE variations which were very OOP and eagerly evaluated instead of lazy (all in memory in the same place instantiated and mutated).

It'll be interesting to see where these differential dataflow approaches go as we head into local-first constraints where central authority on data isn't possible and long divergence of synchronization occurs. Lots of CRDTs in this future for sure. E.g. https://github.com/RhizomeDB/rs-rhizome / https://fission.codes/blog/fission-reactor-dialog-first-look...

Yeah 100% the root pain is from low agency/trust dynamics of a large org.

Jira is just the tool management chooses because nobody-got-fired-for-buying-jira.

It shipped with a slide out that we can't figure out how remove in the AWS console which is already a dumpster fire of a UX.

Every single developer in our org already hates it for just that reason. I'm sure it will be very successful.

This is a great resource to map "what library/thing should I use for x situation" which can sometimes be daunting to someone new to an ecosystem.

The "niche" label cast at Elixir and its ecosystem hasn't been relevant for years; it can do what you need it to and with massive reduction in complexity.

If or when you do need to write your own library: you'll find that straightforward as well.

Sounds like a big issue, better make a Jira ticket for it to get prioritized later.

Elixir is good at doing a lot of things at once on - scaling to lots of machines - and not exploding catastrophically while doing so.

Turns out this is really helpful for machine learning where you want to coordinate big data pipelines and do things like batching requests to a GPU resource (because GPUs want to be parallelized).

You can do batched ML inference pretty much out of the box with Nx.Serving https://hexdocs.pm/nx/Nx.Serving.html where you'd have to spin up a separate third party service like https://developer.nvidia.com/triton-inference-server otherwise.

* Elixir-lang Intro: https://elixir-lang.org/getting-started/introduction.html

* Exercism track: https://exercism.org/tracks/elixir

* Sasa Juric's book: https://www.manning.com/books/elixir-in-action-third-edition

* Dave Thomas's Elixir Course: https://codestool.coding-gnome.com/courses/elixir-for-progra...

* Phoenix Guides: https://hexdocs.pm/phoenix/overview.html

* Ecto Guides: https://hexdocs.pm/ecto/getting-started.html

The above covers the language basics/ideas/concepts and the main tooling (Phoenix/Ecto) if you're looking to build apps or get an Elixir job. I definitely recommend the Phoenix Guides or similar - they're very high quality and kept up to date with any new releases or changes while books can sometimes get out of date.

Mojo is pretty cool but its a difficult road to take - especially to implement the breadth of accrued functionality of a 20 year old language like Python.

Elixir & Python are not an apples to apples comparison - there are fundamental differences in the programming model (functional, immutability, etc) and runtime (preemptive scheduling + OTP) that is the reason it has distinct advantages not available without heavy cost trade-offs elsewhere.

Either way once Mojo is production ready Elixir will be able to use it as well like it does Rust, Zig, or Python.

It's a weird mental block too - learning a language like Elixir, being so well designed and documented, is as comfortable as it gets.

Devs we hire without direct Elixir experience pick it up really quick (within a couple weeks). The energy needed to "get good" with Elixir is really not much considering it provides veritable super powers on the backend and introduces a whole category of concurrency concepts that are not easy to grasp elsewhere.

Liveview v1.0 is the next step with this release out; 1.0 will be the main target for tutorials, documentation, examples and libraries to build on.

Easiest way to get component usage examples ATM is to generate a phx project, and run a mix phx.gen.auth and phx.gen.live command.

I'd say its good for both.

Small sites because it is low-bandwidth to figure out how to use. Time is money and if I'm just tinkering on the weekend I don't really want to learn Kubernetes or the labyrinth that is AWS; I just want to ship an app.

Big sites because your users get routed to the node closest to them and again you can do this without a lot of time investment. For Elixir I just wire up Libcluster and my nodes can talk to each other.

I really want GPUs on Fly soon though. Just take my money Kurt. (I hear they're working on it)

Elixir does distribution and concurrency really well, so Fly making multi-region deployments easy makes it a good fit.

It is bonkers how little code and need-to-now is necessary to deploy cutting edge models in an Elixir app these days.

I didn't realize until a recent side project just how much progress had been made in Nx until I started implementing parts of Nx Serving myself only to find the Nx libraries already have distributed batched serving, faiss, pg_vector support and more.

Makes me want to quit all work obligations to hit the books and build product with Nx.

It's good, but these models are general purpose starting points - they expect and recommend fine tuning to get excellent results.

There almost surely will and Elixir/OTP is going to do it best.

Agreed Elixir/Phoenix + Tailwind is at the sweet spot of scalability, performance, and bonkers productivity.

Real time? Need to go distributed? Maximize # of features / developer bandwidth? Cutting edge machine learning training & model serving?

Mobile? JSON APIs and GraphQL tooling is great, but https://github.com/liveviewnative is moving fast so this stack almost has the exodia of full stack, one language, and distributed actor model based scalability.

The biggest $ cost I'd have on my radar WRT AWS vs Fly is complexity and need-to-know of employee time to do any given thing. Fly is way easier to navigate and use than AWS and its labyrinth of Cloud Scale™ horrors. The trade-off being you can do more given things with AWS.

Running into concurrency woes of that whole generation of languages (Ruby/Python/PHP/Java/JS) is how most Elixir developers happen I think ;)

Just make sure you're not genetically bad at Folic Acid in which case you want Methyl-Folate instead.