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