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.

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.

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.

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

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

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

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.

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.

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

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.

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.

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.