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)

That exists in LiveBook now[1] as part of some visualization improvements.

[1] https://news.livebook.dev/whats-new-in-livebook-0.7-2wOPsY

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.

Do you have a link to something that’s shipped with these technologies?

I think https://www.cars.com/ is largely done with LiveView now.

Its really fast. Their site used to be really slow. Big change

They rewrote the whole back of house system from Java to elixir and apparently it’s been a huge success.

I tried to look around, but is there a blog or something detailing before/after/why etc.? Should be very interesting read..

This is probably the most comprehensive thing online[0]. Not an article but you can read the transcript of the podcast episode[1].

0: https://smartlogic.io/podcast/elixir-wizards/s7e2-jose/

1: https://smartlogic.io/podcast/elixir-wizards/transcripts/s7e...

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.

[1] https://www.youtube.com/watch?v=zKifFG4i-bY

[2] https://2022.elixirconf.com/speakers/zack-kayser

Discord uses elixir quite a bit. I believe pagerduty as well.

Elixir has some case studies written up on its official site.

https://elixir-lang.org/cases.html

Also there's https://elixir-companies.com/en

It even have a jupyter competitor in LiveBook[1].

[1] https://livebook.dev/

Unfortunately VIM bindings are a non-goal, so I’m not going to be spending much time with it (due to a history of RSI).

I use it with Firenvim: https://github.com/glacambre/firenvim

When I tried that the in-page editor would fight it ferociously, was there a trick?

Yeah, that is unfortunate.

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 don't think you should be downvoted, you gave it a fair shot and concluded it was not for you.

Well I am on the fence at the moment. Perhaps I should be downvoted for being indecisive!

Yeah you got bitten by the 0.15-0.16 transition in live view. My condolences.

Documentation across the elixir ecosystem is pretty good, I find. I am way more comfortable in elixir ecosystem docs over python ecosystem docs.

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.

Great job on the upgrades!

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!

Will do and thanks for making such a great language to work with!

One of my first thoughts when I saw the changes to LiveView was "What does this mean for the AlchemistCamp videos"!

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.

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.

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.

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

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

@spec some_function() :: {:error, :bad_args | :out_of_bounds } | {:ok, SomeStruct.t}

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.

Oh my god, why didn't I know about "h Module.some_command`. Thanks, that is going to be really helpful!

Will be reading the IEx documentation more closely.

> Thanks, that is going to be really helpful!

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.

There was a really great talk at ElixirConf 2022 with this tip + loads more. [1] Definitely check it out!

[1] https://www.youtube.com/watch?v=BotVs6TXR-c

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.

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

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.

I am sorry that this has been your experience.

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

Regarding types, we are researching types for Elixir: https://elixir-lang.org/blog/2022/10/05/my-future-with-elixi... - this is still years ahead, but I thought I would mention in context.

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.

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.

I agree this is a pain and we have an open issue in ExDoc (#1551) to tackle this.

If anyone is interested in submitting a PR, it will be very appreciated!

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?

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

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

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.

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.

So I understand that new entries to the ecosystem are in flux, but I would say it is inaccurate to generalize to the Elixir ecosystem as a whole, because we try really hard to keep it stable once a major version is out. :)

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.

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

How’s the job market for elixir? It seems a lot of stacks are popular due to their employability.

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

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

It used to work on Windows but for some reasons nowadays I get trouble to make Elixir works with the OTP version the installer gets.

I couldn't get Elixir 1.14 to work in September actually and reverted to 1.13.4, maybe I should try again.

Make sure you are also running Erlang/OTP 25. I will try to make this clearer in the installer!

First, part of my confusion was that the installer effectively asks you 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 my erl-25.0.4 doesn't seem used (while being in the PATH env)

But it works with elixir 1.13.4.

> elixir -v

> Erlang/OTP 24 [erts-12.2.1] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1] [jit]

> Elixir 1.13.4 (compiled with Erlang/OTP 22)"

This is on Windows 7 FWIW. I searched the Elixir forum and didn't find anybody having the same problem.

This is unexpected. Elixir should just pick whatever Erlang is on the path.

This may be a bit too much, but maybe try removing all Erlang and Elixir versions and just picking the latest for both?

If you are on WSL, then `asdf` or similar can do the trick.

See my edit, it works now thanks, I can now test dbg :)

Awesome! Btw, I sent a PR to Erlang/OTP so it raises a better error message when using an old Erlang version. :)

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.

I've been using WSL, which you can get from the Store now. Works for development and building releases, which then deploy to an Ubuntu VPS.

What are the issues?

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

The iex.bat thing can be circumvented by dropping the iex alias for Invoke-Expression in your $PROFILE.

Ah, good point! I haven't thought of that before. Thanks for pointing it out.

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.

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.

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?

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 ?

You're not forced to make your user an actor just do it the "regular" way.

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 may find these interesting...

- "The Onion Layer Theory" https://learnyousomeerlang.com/building-applications-with-ot...

- "On Erlang, State and Crashes" http://jlouisramblings.blogspot.com/2010/11/on-erlang-state-...

- "Why Restarting Works" https://ferd.ca/the-zen-of-erlang.html (search for "Heisenbug")

> 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

https://www.youtube.com/watch?v=nLApFANtkHs

Agreed, sounds like Orleans. See https://github.com/erleans/erleans :)

Also for general writing on erlang and k8s: https://adoptingerlang.org/docs/production/ -- I try to explain why the two work at different levels so complement each other.

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’

The Horde README links to a really good talk that nicely demonstrates the library. Worth a watch!

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, the world needs more people to write in Elixir/Erlang, and escape the polyglot hell the cloud shift incentivized.

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:

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.

awesome work - will definitely be checking this out not surprised that this is more popular format than textbooks and videos

I love it. It is an interesting twist on the literate programming idea.

Congratulations on designing and developing the system, as well as pouring such a high quality content to it.

I can see the code of a book on GitHub[1]. It seems that the data of a single chapter is crushed in a single JS object[2].

Is the chapter data manageable in some text format, or is it only through the GUI presented in the docs[3]?

[1] https://github.com/markm208/exbook.

[2] https://github.com/markm208/exbook/blob/master/chapter1/01/j...

[3] https://markm208.github.io/storyteller/index.html

This is such a cool tool - I worked in coding education and always loved tools that let you playback/annotate code.

Thanks for posting!

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.

Thanks for the reply, José.

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! :)

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 !

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!