[ryanrasti]

I share the OP's enthusiasm for Elixir, but as the CTO of a startup that ran it for three years in production, our experience was a mixed bag as the codebase grew.

The core promises of the BEAM (concurrency, fault tolerance) absolutely held up. Libraries like Ecto and Oban are world-class, remote `iex` is a lifesaver in prod, and the talent pool is exceptional.

However, developer experience (DX) was our biggest bottleneck. At our scale of 300k lines of code, the pain points were sharp:

* Compile times: A one-line change could easily take >10 seconds to compile in dev, constantly shattering flow.

* Tooling: ElixirLS was a coin flip. Unreliable autocomplete in a large codebase meant constantly grepping for function names and schema fields.

* LiveView: It wasn't a fit for our complex UI, which required a lot of client-side interactivity, forcing us to build a React frontend. This introduced the exact split-stack complexity (GraphQL overhead, context switching) LiveView promises to fix

I wrote a full retrospective for anyone considering the stack for a long-term project: https://ryanrasti.com/blog/elixir-three-years-production/

[Alifatisk]

> Compile times: A one-line change could easily take >10 seconds to compile in dev, constantly shattering flow.

Has anyone else experienced this? I've mostly read comments on how good Elixir is and if you are a Rails user you will only benefit more from Elixir. This is a bit surprising

[fridder]

for a very large graphql api maybe? I've seen long compiles with a combo of Absinthe, Phoenix, and Elm. Also if you are not a little careful about dependency cycles it can get messy. It is an easy thing to check in CI via mix xref graph --format cycles --fail-above

[ryanrasti]

Ah yeah great callout, that's very plausible. We used Absinthe heavily to power our GraphQL API.

[arrowsmith]

Not remotely. Maybe I'm just not working on big enough projects, but I've never experienced any frustration at all with Elixir compile times.

[Kreoss]

Nope. I also worked on a Startup with a Full Phoenix LiveView Experience. Codebase was around 300k-400k lines of code and compilation was blazing fast. I would say they have a lot of circular dependencies if they are experiencing that.

[auraham]

Can you elaborate on how React was a better fit than LiveView for your use case?

In my opinion, the main drawback of LiveView is that we assume that the user do no click on the Back button of the browser. In other words, if the user changes the page by pressing the Back button, then Phoenix closes the socket, creates a new one, and the state is lost. I really like LiveView but not sure how to persist the state between page reloads without using Ecto (also, not sure if that is idiomatic).

[arcanemachiner]

> if the user changes the page by pressing the Back button, then Phoenix closes the socket, creates a new one, and the state is lost

I don't think that has to be the case. You can use "patch" style links to navigate from page to page in the same session.

https://hexdocs.pm/phoenix_live_view/live-navigation.html

[auraham]

I am aware of that option. However, AFAIK patching links do not prevent the user to press Back button.

[arcanemachiner]

I don't see why that would affect it, unless that Back button press modifies the URL such that it is out of the current live session, which would trigger a page reload.

My LiveView is rusty, but I encourage you to reconfirm your assumptions, as I think that things work the way we both hope they do (as long as the live session doesn't change).

[klecansky]

I had a similar experience when learning Elixir. I really like the language, but I ran into a lot of issues with the LSP not working properly. It might be because I’m using Windows with WSL, but I’m really looking forward to the new official LSP (https://github.com/elixir-lang/expert), and I hope it will make things better.

[akarshc]

Absolutely, any frontend, LiveView or React, can get messy if not carefully maintained. As the app grows and more developers contribute, regular code reviews and removing unused logic are essential, otherwise DX suffers just like in any other framework. I also agree there is still so much room for improvement in this space.