I am the author of the tutorial. I created a tool that captures keystrokes and file operations in a popular editor and allows them to be played back in a browser. The author can then add a narrative as the code evolves with text, pictures, and videos.
I have more 'books' on C++, python, SQL, web dev, dart/flutter, clojure, ruby, and more:
I use these for the programming-focused cs courses that I teach instead of having the students buy bloated textbooks. The students prefer them to books (no surprise) and videos (somewhat surprising). The code is searchable and copy/pasteable so the students actually use it.
Phoenix with LiveView is an antidote to the pernicious Web we weave. Massive concurrency, hydration, and that ever elusive stateful single page app experience, are all handled at the framework level instead of in the application. You write the app and it Just Works. If React or the JavaScript du jour isn’t already your horse in the race, Elixir is well worth a weekend test drive.
It doesn’t just work in my experience. Once its working it is fine, better than fine in fact. But I am going through a process of upgrading a Phoenix LiveView hobby site and its been miserable.
For some reason LiveView has changed between versions, and the documentation isn’t the greatest on explaining why or what to do to remedy it, but its broke my app. I’ve managed to fix the majority of it but then the third party libraries used have not kept up (for authentication of all things). There is so little people using Elixir/Phoenix/LiveView that libraries are often poor quality and maintained by one person or very few people. It makes me miss Django for the batteries included completeness, quality of documentation and eco system.
Phoenix also feels a little bit magical in the way Rails is, and I hated Rails for that. Give me configuration over convention and stop with the damn macros.
I am also not convinced with Elixir as a language, I miss types, I miss C# and Typescripts documentation or the fact they feel well designed, I want something to replace Python as my goto and Elixir just feels like a dead end that happens to have a web framework with some excellent ideas.
So I am currently thinking of rewriting the whole damn thing and leaving Elixir.
I am obviously biased but I would stick around. :) I assume you started with LiveView early on, which means the documentation was sprouting and best practices still evolving.
Nowadays it is still pre-1.0 but much closer to its vision, so you should find better docs on the current practices. We now support components too, which declare each attribute, alongside their docs and types. So assuming you go through the update, I am hoping you will have a good time once it is done. And don’t hesitate to reach out in ElixirForum.com if you have questions.
The docs (or lack there of) were the reason I stopped playing with Phoenix and Liveview. As an Elixir n00b, source diving to figure out how things work isn't an option for me right now.
I'm sure you've been linked these a thousand times, but the docs for Laravel are imo, the gold standard for developer documentation. I love the idea of Hex being a built in solution for documentation, but a hodgepodge short guides supplemented by the Hex docs isn't enough.
I also realize you're not Chris, but I figured it was worth mentioning. I do really like Elixir and hope I can come back to it when these ideas mature a little more!
I'm incredibly surprised by this. I personally use the Phoenix documentation as the gold standard for good developer documentation!
There is an excellent, clear and practical set of guides that take you through the increasing complexity of a Phoenix app. I find them very clear, and surprisingly complete. They start here: https://hexdocs.pm/phoenix/up_and_running.html
The 'reference level' documentation is also excellent. I picked this example randomly, but it has an extensive guide at the top and then good description of each of the functions: https://hexdocs.pm/phoenix/Phoenix.Channel.html
I think what Phoenix is missing is a way to search all of the included packages from one place. The one thing I struggle with is having to figure out what module a function is in so I can find the docs for it.
As a Developer I don’t necessarily think I should have to bounce around between docs for Phoenix, Phoenix.HTML, Phoenix.PubSub etc. The docs can be separate for sure but at least give me a single central search for them.
Thanks Jose! I know writing docs/guides is really hard and 1st class search can make a huge difference. Another thing I love about the Laravel docs, is searching via a keyword that I know may exist on a specific page; the list of available methods on a `Collection` is one I use all of the time.
I see in the Github issue you specifically call out _not_ searching text content from related modules, but I think if you can make it performant, it's worth the extra effort to allow full text search. I suppose the harder part might be ranking if you're not using a system that is built for that use case, but I think it would be helpful.
I've made the switch from PHP/Laravel to Elixir/Phoenix and I've found the documentation in Elixir land far more superior and complete. I've yet to find something better anywhere else. What's the equivalent of Hexdocs in PHP land?
The docs themselves are fine, but when I'm building an app and focused on using the tools available by the framework, I had trouble finding what I needed. Perhaps it was even discovery of not knowing what I needed to even look for. I might know a concept under a different name for example. I don't expect anyone to cater to my exact needs, but I want to find everything in the same place.
Someone else left a sibling comment talking about the documentation for different modules not being colocated (Phoenix.PubSub vs Phoenix.HTML, etc) and maybe that was my issue. If literally every module is new to me, that could be a lot of jumping back and forth just to try and reason about what a couple of Plug modules are doing. Granted, it's been at least 6 months since I've tried to play with Elixir and Phoenix so maybe I'll have some time to try again over the holidays.
To go back to your original point though, yes Hexdocs is a great tool and the ecosystem encourages documentation, but maybe in this case I'm looking for a more curated guide and I should have been explicit rather than lump it all under "docs".
I don't know about Laravel but I think the Symfony documentation has more practical and extensive documentation and guides (the framework does way more than Phoenix so there's probably a correlation there).
There's no equivalent to Hexdocs in PPH land but I think the PHP documentation itself is quite good, once again by usually providing examples for all types/arguments variation for every functions, which the Elixir std lib does not (the REPL allows you to quickly try things though).
Thanks for the reply. I go through great days with Elixir/Phoenix and bad days, yesterday happened to be a bad day.
I really like the promise of Phoenix, it really is one of the most forward thinking projects I have come across - hence continuing using it, though I don't have all the time in the world to invest in it so just jumping in and out can be painful.
Want this project to work though, I have tried commercial products, IOS apps, and nothing matches upto my vision or indeed my old working prototype.
> Phoenix also feels a little bit magical in the way Rails is
I've felt this about every backend web framework I've encountered, Django included. There's a tension between reducing boiler-plate, and not having directory structures/symbol names/etc. have some implicit order to them. If you want explicitness, don't use a framework and maybe use something like Flask/Werkzeug
> I miss types
Most frameworks have typespecs defined which are enforced by dialyzer, using a much richer type system than most. e.g. Without creating some explicit enum you can make a function signature like:
And then you can a caller can just pattern match on that with a 'case' statement, and dialyzer will complain if all paths aren't handled.
> I miss C# and Typescripts documentation
hexdocs.pm is pretty amazing. Elixir as a language encourages documentation and has iterated heavily on its documentation tooling. I love that I can just fire up an iex console and go `h Module.some_command` and I'll get great docs back. And then `@doctests` that both work as inline unit tests as well as low-cost documentation for the library author. I think the incentives to make good documentation are there, and that has inspired the community to document well. And then there's elixirforum.com if I get stuck. In constrast, many times a Django extension has left me wanting in its description about intended behaviours.
>> Phoenix also feels a little bit magical in the way Rails is
>
> I've felt this about every backend web framework I've encountered, Django included. There's a tension between reducing boiler-plate, and not having directory structures/symbol names/etc. have some implicit order to them. If you want explicitness, don't use a framework and maybe use something like Flask/Werkzeug
One of the things I love about phoenix is how little magic there is. Not directed at you, but I agree there is always some amount of "it just works" with a framework but Elixir/Phoenix felt immeasurably more "the code is here" vs "well that particular thing is method_missing'd a few layers down into this which routes into that and then kaboom, here's your entire app."
This is helped by Ecto, which is the perfect mix of helpful and not helpful to me. It gets what I ask for and only what I ask for. It tells me when I've mucked up and generally it feels like a nice API to SQL vs its own thing (and dropping custom SQL is super easy). The data layer is most often the most hidden magic layer in frameworks IMO as routing some HTTP GET to some controller/function/whatever is pretty simple and easy to reckon.
Agreed, Ecto is the perfect balance of helpful and explicit. It allows people to avoid the performance footguns of typical ORMs, while still providing a friendly way to do that relation mapping, pluggable way to do validation, etc. and there are just things you can do with joins + select that an ORM can’t do, but Ecto can.
The magical parts of Elixir/Phoenix, would be the naming conventions of Controller/View/Template (which I think can be overridden), and `use` which brings a lot of useful functions but it isn’t obvious to a new user how to source docs for that.
That makes me really happy :) And if you prefer docs in web-form, just look up any module in hexdocs.pm . Also can't overstate how helpful elixirforums.com is - a lot of smart + helpful people on there.
It is one of my favorite things about the Elixir REPL, and the ease of using them is a great incentive to write docstrings for your own code. The way examples integrate into the docs and test suites is really cool too.
The transitions from about half of the versions between 0.3 and 0.10 were worse for me. From 0.10 to 0.15 were smooth. 0.16 was tied to phx 1.6, which made it worse again, but I didn’t find it that bad.
0.16 to 0.18 has been mostly okay again, but I’ve seen bugs introduced into an app just by adding IDs to HTML elements with a phx-hook on them. This is a problem since heex templates enforce that each hook does have an ID. It’s also strange that a totally new ID never used elsewhere in the app would break existing JS interop, but it does and it’s what I’ll be working on this week so we can continue upgrading…
Not sure what it’s going to be like upgrading to Phoenix 1.7, but I think it’s going to be a major undertaking and unfortunately most my Phoenix-related screencasts will become obsolete. Elixir itself and Ecto have been really stable, though.
Right, Phoenix LiveView has been pre 1.0. We try to keep things deprecated for a while but we need to balance getting to 1.0 and supporting existing code. Now that it is getting closer, we can make it as a default in new Phoenix apps. :)
phx-hook always required IDs. They would misbehave (and warn) if you forgot the IDs, so could it be that you were relying on broken behavior? In any case the IDs can be enforced now, so it should be consistent, please file bugs if it does not work.
Upgrade to Phoenix v1.7 should be painless, because it only really changed generated code. Screencasts that use generators will be out of date though. In other words, best practices evolved (as they should) but code still works.
I don’t see reliance on broken behavior around the hook, but it’s absolutely possible. It’s a large app with a lot of technical debt and was on Elixir 1.9, OTP 22, LiveView 0.4 and Webpack 4.x when I joined on this summer.
The existing team had encountered a lot of pain dealing with LiveView and made heavy use of jQuery as an escape hatch. They were seriously considering a rewrite in another language not long before I joined.
It’s been a long, painful slog upgrading, but the app is now working with current Elixir and Erlang versions and runs on my M1 Mac now at least. LV 0.16.4 runs on prod and 0.17.5 is working on an upgrade branch (as long certain phx-hooks don’t have an ID).
I’ll get to the bottom of the various issues and get the heex migration finished. Ultimately, I’ll remove the currently hooks and related JS entirely and replace the modals that rely on them with pure LV versions. Just reporting the dev experience.
IMO Phoenix upgrades were pretty trivial since I started around 1.2, until LiveView. Now, due to the increasing LV integration, it feels like Phoenix itself is no longer 1.0.
FWIW, if an element does not have an ID, then it is hard for morphdom to track when it moves around on the page. This will lead the hook to consider it is has been destroyed and mounted instead of updated.
About Phoenix, the generated apps definitely evolved a lot, but updating your Phoenix dependency should just work. If it doesn’t, please file a bug report!
Well, I did make a conscious decision to hold off on videos about LiveView (and part of my book) due to the frequent breaking changes in the LiveView series I did back in 2019.
My job has been giving me a lot of ideas for new content, though.
I guess that's heex. I don't like JSX style but the it's not as crazy as javascript. It's okay. With first-class function, passing a thunk that returns template (not in plain string) around is also extensible. But slot is also okay to me. The trade-off of compile time construct is it's harder to do thing in dynamic way.
Elixir docs is top-notch, well-organized. Typescript docs is a mess category-wise. Believe it or not Typescript code is going to be buggy than dynamic typed elixir code because it has better defensive mechanism (pattern match + guard + immutability). The only thing I agree is macro, it's designed for human DX .. good though is hard to do interop (programmable).
What's "magical" about Rails...I really dislike that criticism because it's an inaccurate cliche. Rails has great documentation and common sense (for the most part) conventions.
Try doing something in Spring and tell me your experience ... it can easily be described as "magic" unless you read a massive amount of Spring documentation.
I admit it's a long time since I used Rails and Ruby, and it was around the same time I was learning Python and Django back when Rails was the hot thing - but Django seemed to be more straight forward and less of "So why is this working". If you read the PEP20 Zen of Python that resonates much more soundly with me particularly "Explicit is better than implicit."
This drives me nuts for example: https://guides.rubyonrails.org/layouts_and_rendering.html#re... - ok it's automatically parsing and rendering that template, based on that route and controller and it's less code but less explicit. And it assumes that we have written all the filenames correctly.
Which it's a pretty fair assumption: you would create all of those files through generators, eliminating the need for writing boilerplate. And make the name explicit if, for any reason, your template is located somewhere else.
I am not a huge Rails fan, but in this particular case I see zero issues with how Rails does things.
Your assessment is similar to mine, set aside any cool features of the language, maintaining an Elixir app is the problem. The constant API shift with each LiveView release, not enough people maintaining hex packages, not a large amount of hex packages available forcing some things to be built, etc. Adoption in our organization was halted because of the messiness of upgrade path in Elixir as a whole. Projects that were built on earlier versions suffer the most pain where developers will spend like a week sorting through code changes needed to update. There are some neat aspects of Elixir but the maintenance trade-offs aren't worth it in management's eyes.
LiveView's growing pains were definitely pretty bad (the early days of it had some pretty obnoxious breaking changes), and I can see while still disagreeing about the magic comment, but what's wrong with Elixir's docs? They are, hands-down, the best language docs I've ever interacted with, and that very much includes C#, so I'm a little baffled as to where that complaint comes from.
I agree with your assessment. You have to know what you’re signing up for. Remaining in the JavaScript ecosystem still maintains many tangible benefits.
> If React or the JavaScript du jour isn’t already your horse in the race,
If only it were up to us simple devs who actually do the work.
But its not. CTOs make the decisions and they bring in tech that "everyone else" is using. That means Java/Node/Python/C#/ and Angular/React is probably 90% of web code out there.
I can try fighting the trend and specifically apply to niche tech jobs but its no fun...been doing that with Ruby for awhile until jobs literally dried up where I live.
If you live in a remote friendly area (big parts of Europe) you can get by .. but I don't.
As someone completely new to js world, I've started learning nextjs and for hobby projects atleast I've come to the conclusion that negative opinions about js are overblown - yes theres not one dominating framework, but that's how innovation is born. Plus they're all about dev experience - you don't have to migrate if you're happy with what you've got.
Controversially I'm also pleased about breaking changes if it means things get significantly better and there's less legacy to deal with.
All in all a fast-paced ecosystem for a fast-paced world.
I did seriously give it a try with elixir but felt I wouldn't appreciate it without dealing with js first, so it'll be something if I ever outraged with js, but between typescript, nextjs, jsx templates and all the excellent vscode tooling I'm happy. Infact much happier than dealing with Django's black magic.
Not as straight forward as the massive languages as the pool of developers and work are both smaller. But remote EU or US is not very hard if you have some experience (Elixir or in general).
Junior positions are quite uncommon and seem to require some hustle on the networking side.
Market seems to be cooling a bit for consulting (I do that) as the economy makes companies more careful.
None of the highly motivated Elixir devs I know are struggling to find work. Consulting/contract clients has been trickier lately but not impossible.
Source: I help companies connect with Elixir devs as a specialist recruiter. And I do contracting/consulting.
Feel free to ask questions here or via contact through underjord.io
One of them gave an elixir conf talk about how they built an elixir team[1] and this one from 2022 which isn't online yet[2]. I know a little more about it from talking to them, but couldn't accurately describe the transition from memory.
Tangential, but what's the best way to get Elixir dev environment with database on Windows?
A friend and I have been trying it for a project and for a NixOS dweller like me it was less than 2 minutes of work. But for her it has been never ending troubles.
Otherwise, Elixir and Phoenix are fantastic! No explicit JavaScript is necessary and that alone sells it for me, but the concurrency story is so easy to grok that I'm amazed nobody else managed to recreate it in so many years..
For running directly on Windows you can simply run the Elixir installer, which will install Erlang and Elixir. After that, I highly recommend using the ElixirLS extension for Visual Studio Code. Note that on Windows, you need to use `iex.bat` and `mix.bat` instead of just `iex` and `mix` when running the commands. For example, `iex.bat -S mix.bat`. (I have it setup where I can leave off `.bat` for `mix`, but I can't remember what I did off the top of my head, if anything, to get that. `iex` conflicts with a PowerShell thing, so `iex.bat` is required.)
The other option is to install WSL2, install Erlang and Elixir there (I recommend using the asdf package manager (https://asdf-vm.com/). Once installed, use the Remote - SSH extension in Visual Studio Code on the Windows side to remote into the WSL2 instance. You could also download an official Elixir Docker container and again use Visual Studio Code (https://code.visualstudio.com/docs/devcontainers/containers).
My company has a lot of Windows users due to its industry.
I’ve made a doc for setting up Windows machines that I’ve been planning to share online but haven’t gotten around to yet. I’ll try to tonight and update this thread with a link.
Tldr; use WSL2 and Ubuntu stable. Use ASDF. Put your app on the Linux part of the filesystem and if your Postgres installation is also on the Linux side, then have bash start it for you.
Just put a Debian or Alpine install in a minimum disk image file, and mount a host machine path as a samba share from inside the VM (i.e. the user can edit the VM code without having to import/export constantly).
kvm/Hypervisor support on windows is patchy, but there are a lot of lower performance virtual machines that can work.
First, part of my confusion was that the installer effectively asks your OTP path but I think it used to actually install OTP? So I didn't read the dialog carefully and didn't realized it changed, my bad :)
But, after installing Elixir and pointing it to the otp 25.0.4 folder.
> elixir -v
> Cannot find file at 'c:\program files\erl-24.0\erts-12.0\bin\erl.exe' c:\program files\erl-24.0\erts-12.0\bin\erl.exe). This usually indicates a missing or moved file.
I install erl-24.0
> elixir -v
> Could not load module C:\Program Files\erl-24.2.2\erts-12.2.1\bin\erlexec.dll.
I install erl-24.2.2
> elixir -v
> {"init terminating in do_boot",{undef,[{elixir,start_cli,[],[]},{init,start_em,1,[{file,"init.erl"},{line,1191}]},{init,do_boot,3,[{file,"init.erl"},{line,889}]}]}} init terminating in do_boot ({undef,[{elixir,start_cli,[],[]},{init,start_em,1,[{_},{_}]},{init,do_boot,3,[{_},{_}]}]})
All the while erl-25.0.4 doesn't seem used (while being in the PATH env), I guess that's the problem but how do you enforce the OTP version?
----
edit:
So I kinda made it work. First I noticed that I had erl-24.0 installed by Chocolatey (which I don't remember using ahah) so I uninstalled that.
To make it clear, I'm on Windows 7 so the problems may come from that, but maybe it will help somebody else.
But then the elixir-websetup.exe (2.2) would not actually complete any longer (while doing so when erl-24 was installed by Chocolatey?), it could not find the actual elixir downloaded installer in C:\<Me>\etc (not the valid user path in Windows 7 but maybe in 10+ ?)
I then used elixir-websetup.exe 2.1 and got almost the same error but this time it complained about "elixir-v1.14.1 (Erlang/OTP 25)-setup.exe" while it actually downloaded "elixir-v1.14.1-setup.exe", which I was able to launch myself and finish the setup.
What does your environment look like on NixOS? I had trouble connecting Phoenix to Postgres and ended up using SQLite for my test project. Do you have a database configured in shell.nix somehow?
Does anyone have detailed instructions on how to get Erlang Observer up and running on WSL/Win10? This has been my biggest gripe since I started learning Elixir. I love everything about it expect why isn't there a web-based observer for folks not using MacOS? Having to install all this JVM stuff to make it work gives me a severe headache. I've already looked on Google and didn't find anything with the level of detail that I was looking for. Someone please help!
Practical question here. How are Elixir/Erlang apps being deployed nowadays?
My understanding is that BEAM is designed for long running setups where hot reload of the code makes sense, and reboots are not happening that often thanks to the supervision trees.
But practically speaking how does it work under k8s env? When pod is being destroyed, what happens to all the messages sitting there?
Pushing state out of actors is a possibility, but isn’t it ruin the whole idea of stateful actors ?
Just to make it clear: you don't have to write stateful apps, just because you can. It's still possible to have the more traditional stateless model like Rails.
If you do write a stateful app, and run it in k8s, you can have state handover to a newly created pod. It works pretty well.
Well, let’s assume we are talking about a webshop. Every user is represented as an actor, a cart might be a state.
So cart as a state should be stored somewhere else, let’s say redis.
And every single read/write operation would be a network hop. What are the benefits of using actor model then ?
As for state handover between pods - what are the keywords to look for ?
What you describe sounds more like Orleans grains. Erlang's lightweight processes serve a different purpose than actors or objects, they're really about fault tolerance.
A typical Phoenix app spawns one process for every HTTP request, websocket channel, or DB connection, for example. All these things have a lifetime shorter or equal to the pod's.
The VM gives guarantees and tools to ensure one of these process crashing will not affect the others, unless you want it to. For instance, if a request crashes, its memory will be reclaimed, open files will be closed, DB connections will be re-opened, the exit reason will be logged, error metrics incremented, etc. This is possible with no defensive programming like try/catch and so on, because the processes are isolated. For example they don't share memory, so it's always safe to deallocate something if its owner process died.
This gives a two-layer safety net that allows for very reliable apps, where the VM protects you against bugs in your own code, and Kubernetes protects you against bugs in Erlang, or really catastrophic failures. There's a good blog post on this: http://blog.plataformatec.com.br/2019/10/kubernetes-and-the-...
What i had in mind is some kind of gen_fsm or gen_statemachine.
For stateless applications it is pretty obvious how supervision trees can improve the reliability. Essentially the only ‘state’ there is request itself. Worst case scenario client would just retry.
But with some state involved it becomes not as simple.
Essentially the answer to my question probably would be like : “you should store the state in the external system, and design your system in such a way that stored state is always consistent. In case of failure supervisor will respawn the process and it will recreate what it needs from the saved state”
> you should store the state in the external system
Disk works too, but if you're multi-node this means you now have a distributed database embedded in your system, which may or may not be your goal :)
RabbitMQ does this, they developed a library for "persistent, fault-tolerant and replicated state machines" based on Raft: https://github.com/rabbitmq/ra.
Ahh great. “On Erlang, State and Crashes” is exactly answering my question.
As for disks - in good old times when servers were pets, not cattle that was a good idea. But now when the servers are as ephemeral as actors, we need to approach it differently, hence my original question.
Sidenote - i have a strange relationship with Erlang. I first learned it in 2006, liked the idea and was hoping it will eat the world as scale increases. I even contacted Joe Armstrong in hope to translate his thesis. Zero Erlang books in the world at the time. Then i did some load tests using Tsung in 2012.
Then i used akka.net in 2018. But till this day i never had a chance to properly use in production.
> you should store the state in the external system
It's an old talk, but this one has a strategy for robustly persisting state across ephemeral containers. The example here is running a multiplayer game server while doing code updates etc. using Horde and CRDTs
Thank you, i was not aware of the Horde package. Definitely worth looking.
I was also thinking what should happen in case of ‘electricity disappears’ scenario, but came to a conclusion that it is good old ‘save the state you care about’
I think many modern applications aren't attempting the "long running, hot reload" model - they use a more conventional approach.
One thing that Elixir does well is handling faults - the relevant chunk of code 'crashes', and then restarts. The restart process does the appropriate recovery of any state. This turns all fault handling into a single code path (the startup path).
This approach also fits with the stateless style - the application should already be designed to start up properly and set up its state from scratch. Yes, in practice you design your application differently for a stateless deploy model, but Elixir helps you a lot in this model just as it does in the other one.
Very nice tutorial. But what I'm missing here and for many other similar ones isthe "why" question. Great that it is a functional language with immutability but what can I do with it? Please give me some example of what it does, how I can use it, how within a few minutes I can create something that works and is useful, ... Is it for web programming or a service or a backend or ...
Don't tell me I'll love it because of some programming feature. Make me see why I would love it by showing me how cool it is !
This is very neat. For a while I’ve wanted to create a visual wysiwyg editor for creating/visualizing supervision trees in Elixir/Erlang - love to see visualizations. (The observer is epic)
I have been on again/off again with Elixir for the past ten years, and I can imagine that the upgrade path between Phoenix/LiveView versions would be a pain for orgs that adopted Elixir early. I am not sure how Rails handled breaking changes (as I was never a Rails dev), but I think the rate of change is somewhat problematic if one were to adopt Elixir (and Phoenix/LiveView) today. Hopefully, this will change over time. Edit: and especially with the release of LiveView 1.0.
Elixir has been backwards compatible since v1.0, released more than 7 years ago. Phoenix has also been API stable for a similar period of time and Ecto for 4+ years.
LiveView has changed over time but that’s precisely why it is on a 0.x release cycle. Even then, we do our best to deprecate first whenever possible. But the goal is that established projects have been stable.
In any case, LiveView is nearing 1.0 now, which makes us comfortable enough to promote it as part of the default Phoenix experience.
I think the bigger problem with Elixir is the smallness of its community. There were several libraries that I started using (for example, Gringotts) that were actively developed for a while but then died off and nobody picked up where things were left off. Unfortunately, I am not skilled enough to put forth contributions myself (aside from the occasional bug report). But once LiveView hits 1.0, I think that if the community continues to expand, Elixir has an even brighter future.
Thanks for all your hard work making it possible! :)
I have more 'books' on C++, python, SQL, web dev, dart/flutter, clojure, ruby, and more:
https://markm208.github.io/
I use these for the programming-focused cs courses that I teach instead of having the students buy bloated textbooks. The students prefer them to books (no surprise) and videos (somewhat surprising). The code is searchable and copy/pasteable so the students actually use it.
The tool is free and open.