Elixir and Phoenix after two years | Hacker News Reader

Elixir and Phoenix after two years

nts.strzibny.name

264 pointsbfm111 comments

To add to the author's experience, I spent 18 months of production time with Elixir and Phoenix.

As he says, the templates are compiled and are blindingly fast compared to Rails.

Pattern matching is really really nice when used in the right places (and you'll miss it if you go back to Ruby); but it can be overused. There's a faction of Elixir folks who attempt to avoid all conditionals and instead seem to prefer multiple dispatch/multi-methods to handle different cases. That's nice and very concise, because then you can simply call a function and let the pattern matching resolve which of the various implementations you've defined handle it. The big downside here is, as a reader of the code, you have to basically mentally imagine what all cases are covered and what they mean. Sometimes simply reading a switch statement or if/else/then is much clearer.

The super special magic is in the Erlang VM. If you put more energy into learning it and its capabilities, and using it where appropriate, it can shape the structure of your greater system beyond just one webapp; and it can provide a lot of features without you having to cobble together many other (good but independent) solutions.

Lastly, single thread performance is basically a dog. In my anecdotal experience, the same external service written with Elixir+Ecto was 25-50% as performant as a Python+SQLAlchemy program. So the lesson there is, find ways to parallelize or otherwise scale your process if it is batch oriented and handling a large volume of data.

If you asked me today if I would prefer to use Elixir (and Phoenix) over Ruby and Rails, I would say yes... but honestly mostly just because it's a new fascination with different tradeoffs and a better functional story. Function is the past and the future, and it makes your life easier and simpler. Elixir as a language... borrowed too much from Ruby and has too much syntax. It is noisy in a Perl-like way, and perhaps there could be a more concise enhancement of Erlang which would get the job done and not have you spending time visually parsing code.

sqlalchemy is an ORM - I'm not sure it can be compared against a web framework, but my experience with phoenix vs python web frameworks is that phoenix is easily faster even for single-threaded web requests (which of course will utilize many threads for things like DB thread pooling etc.)

sqlalchemy contains an ORM.

You can do a ton with it without ever importing sqlalchemy.orm.

Sure, but you're missing the whole point - it's not a web framework and it's never marketed itself as one to my knowledge.

> In my anecdotal experience, the same external service written with Elixir+Ecto was 25-50% as performant as a Python+SQLAlchemy program

I'd be interested to see an example here. Using Plug+Ecto has been roughly on par with most real world examples I've seen with SQLALchemy and Flask for single request performance. Python might be a bit faster for some workloads but once you start saturating the CPU, Elixir/BEAM really shines.

I should have been clearer in my final note. My Elixir vs Python example was for standalone batch (script) processing. It was not in the context of a webapp.

The case was a recurring calculation system which would take a few hundred thousand records and do about a dozen different calculations against those (some calculations requiring additional lookups).

The original script was in Python, and then after the new webapp was built in Elixir, I rewrote it also in Elixir. I discovered that even tuning the batch sizes, the Elixir/Ecto version was much slower than the Python version. Then I looking into per-thread Elixir performance and found out that that is not its strong suit :). So the answer there of course is to leverage the strength of the tools and parallelize it; but I had no need to do that since I already had a working Python version. Could Elixir have been faster if multi-threaded? Probably. Single? No, I doubt it.

Hm, if you have a chance to revisit it, you may want to consider Flow, which will likely take a lot of the pain of parallelization away.

Ahh, ok. You've sort of hit a weird spot for Elixir. Python will just start up faster and that will be noticeable. Math is much better optimized in Python, though this is changing with NX.

The real gain here would probably be streaming chunks of rows out of ecto and maybe firing those off to tasks per CPU core. Which is easier than it sounds.

That said, you had working code so no real reason to rewrite it except as a learning exercise.

Typical ways to start beam end up doing a lot of work you might not need.

Taking some time to fiddle with the startup settings for a short running task can make a big difference. You might actually get better results by setting it to single cpu, because there's less setup that way. Really depends on how much total cpu time your work takes. If your VM is going to run for a year (or more), startup time hardly matters and so the defaults aren't highly tuned for a 30 second script.

>Lastly, single thread performance is basically a dog.

Is that still the case? I thought BeamVM recently added JIT? I don't expect it to be LuaJIT or JS V8, but Ruby and Python Single Thread performance should be reasonable expectation?

I also wish some of these experience has more context in terms of code base size and team size. A Production environment of a small project with a team of 2 is very different to production environment of a project that is large and team of dozens if not hundreds.

In my case it was a team of 1 working on OTP 19 and 20. Since that is now 3+ years ago, it is quite possible things have improved in the single-thread performance area.

The 3+ years ago is a good reference, thanks for sharing. The issue could also be Ecto related. Ecto 3, which might not have been out at the time, had a bunch of improvements on this front.

Elixir single thread performance /is/ much faster than Ruby and Python [1].

Are you sure you weren't just doing something sub-optimal with Ecto?

[1] https://amp.reddit.com/r/elixir/comments/46v1l1/is_elixir_fa...

I'm a huge elixir fan, but in micro made up benchmarks I consistently see Ruby win over Elixir. I haven't run it with the jit.

One specific case that cripples Elixir - is as far as I know Elixir can't handle large multiplications efficiently. Ruby, Python use karatsuba or some derivative - from what I can tell multiplication in Erlang doesn't. Though I haven't actually asked anyone and was just poking around on my own.

example: Multiplying the first 100_000 numbers together I get

ruby multi.rb 3.47s user 1.91s system 99% cpu 5.396 total

elixir multi.exs 14.32s user 0.62s system 103% cpu 14.441 total

I was curious to see what my JIT build looked like for me so I ran the following: https://gist.github.com/cararemixed/c232b888b9dbdaeb67967f35...

This shows a significantly different story between the two with at least similar code. Note I am not trying to optimize for the fastest factorial here as both can be made much quicker but roughly equivalent code seems to tell a different story for me.

(NOTE: I put the code in a module as iex interpreted expressions on the top level are always slower than compiled modules, even when pasting them into iex. Doing the same for Ruby didn't show any difference for me.)

Neck in neck! That's amazing. Thanks for testing that out.

I wouldn’t call twice as fast neck and neck (others seem to show that the old interpreter is neck and neck) but the primitive JIT is clearly pulling ahead here.

I've seen several reports of pretty good performance improvements from the new JIT, but keep in mind a couple things:

It's included in the not yet finalized release that is currently only a release candidate. It's a little early to expect people to have experience with it. Some organizations might update quickly, but others will take quite some time. Also, the JIT isn't on all supported platforms; i think it's amd64 and aarch64 only at the moment, which probably covers most performance oriented servers, but maybe not everyone.

The other thing is it's not an optimizing JIT like Hotspot or v8; it 'only' turns the beam opcodes into native code as it's loaded. This eliminates interpretation overhead, but there's potential to optimize the native code in the future.

> attempt to avoid all conditionals

I think that's a symptom of the lack of a return keyword (and therefore early returns).

> and perhaps there could be a more concise enhancement of Erlang which would get the job done

Erlang already is a more concise language than Elixir but also noisier as there are more punctuation characters. I would love if Erlang would drop some of its punctuation, as some of it is frankly unnecessary.

Elixir syntax is definitely simpler than Ruby’s. Probably in the same ballpark as Python complexity wise: Elixir has less keywords and less rules thanks to the macro system but on the other hand more affordances, such as optional parenthesis.

> Erlang already is a more concise language than Elixir but also noisier as there are more punctuation characters.

What?

Here's more-or-less the entirety of Erlang's "noisier syntax with more punctuation characters"

  -spec f(A :: any(), B :: some_type(), C :: list()) -> any().
  f(A, {B}, [C | _]) ->
    A1 = fun() -> io:format(a, []) end,
    A1(),
    case C of
       <<1, _/binary>> -> 1;
       _ -> #person{ok = ok, field = C}
    end.

Edit:

  %% plus map syntax

  #{"tuple" => {1,2}}
  M#{"key" := "new_value"}

  %% plus list comprehensions

  [X || X <- List, X /= 10].

Elixir has all that plus more. The equivalent in Elixir is something along the lines of

  @spec f(a :: any(), b :: some_type(), c :: list()) :: any()
  def f(a, {b}, [c | _]) ->
    a1 = fun() -> IO.inspect(a) end,
    a1.(),
    case C do
       <<1, _ :: binary>> -> 1
       _ -> %Person{ok: :ok, field: c}
    end
  end

  ## and don't forget the capture and pipe syntax
  
  x |> (&f(y, {&1}, list)).()

  ## and default function parameters

  def f(a, b, c \\ []), do: something()

  ## and sigils

  String.replace(str, ~r".*", "")

  ## and Ecto adds its own characters

  id = 1

  (from p in Person, where: p.id == ^id, select: p) |> Repo.all()

  ## and dropping down to Erlang is a function call on an atom

  :io.format(x, y)

And I'm definitely forgetting more...

Edit:

  ## and string interpolation

  a = 1
  
  s = "The value is: #{a}"

  ## and two different map syntaxes

  %{a: :map, with: "various", keys: "as", atoms: 0}

  %{"another" => "map", "but" => "keys", "are" => "strings"}

  ## and different map access

  map[key]

  map.key

  ## and map update

  %{ map | key: "new_value" }

  ## and list comprehensions

  for x <- list, x != 10 do
  end

you are conviently forgetting one thing:

The equivalent of "hello world" in erlang is

    <<"hello world">>

Not the best. Keyword lists in erlang are unpretty

    m:f(value, [{foo, <<"bar">>}, {baz, 47}])

Where in elixir you would do:

    :m.f(value, foo: "bar", baz: 47)

> The equivalent of "hello world" in erlang is

is "hello world".

Edit:

I know that "" in Elixir is binaries which are <<>> in Erlang. In Erlang "hello world" is really a list of ["h", "e", "l", "l", ...].

What was surprising to me is how rarely that matters (unless you actually do a lot of text processing). And the functions that matter (like I/O) deal with io_lists anyway.

And since strings in Elixir are binaries, when you actually need to work with binaries, you're back to the same/similar syntax:

  <<0:1, 0:1, 1:1, 1:1>> == <<3:4>> %% Erlang

  <<0::1, 0::1, 1::1, 1::1>> == <<3::4>> ## Elixir

> Keyword lists in erlang are unpretty

Keyword lists in Elixir are nice, that's true.

My god, it’s like Perl but somehow worse. How do you even keep track of what’s going on?

That’s not a representative example of none of the languages. It is also just plain invalid for Elixir. I recommend checking actual code examples on their websites to form a better opinion.

It's not that bad, really. As with most languages, syntax is the easy part.

From personal experience:

- You're comfortable with Erlang syntax within half a day. There's just so much less of it

- You're comfortable with Elixir syntax within a day of two of active coding. Function captures may trip you up once or twice more, but then it's fine.

Your Elixir example is literally wrong. It won’t compile unless you do many changes. You are keeping -> instead do. You are still using commas after each expression. The fn syntax is wrong and also using parens for args. So you forgot to remove most of the punctuation noise.

You are conveniently not showing many examples where Elixir is considerably less noisier such as keywords, utf-8 binary strings, etc. Module definitions in Erlang use -(). while Elixir doesn’t use a single punctuation character. Erlang has special syntax for list and binary comprehensions while Elixir has unified both and uses no special syntax. Maps in Erlang also have two syntaxes, more ways of doing try/catch, etc.

If you take examples of actual code implemented in both languages, instead of cherry-picked invalid gibberish, you will find that Erlang has more punctuation per character than Elixir.

> Your Elixir example is literally wrong. It won’t compile unless you do many changes.

I was typing this inside the HN comment box. And no, not many changes.

> So you forgot to remove most of the punctuation noise

For the two examples you could come up with for my entire text Elixir adds half a dozen new punctuation characters on top of Erlang.

> If you take examples of actual code

Of course. Here you go:

  Enum.sort(["some", "kind", "of", "monster"], &(byte_size(&1) < byte_size(&2)))

I mean, Erlang doesn't even have `&` as a part of syntax, but sure, "Erlang has more punctuation".

Besides, Erlang's syntax is significantly more consistent than Elixir's. Just take Elixir's two separate syntaxes for maps, for example. Or the dichotomy between syntax for functions and lambdas (both for declaration and invocation).

The only reason Elixir feels like it has less punctuation is that Erlang is actually more terse than Elixir.

Just having pipes and function captures everywhere makes Elixir code have more punctuation than Erlang.

The example that you picked and wrote translates to this in Erlang:

    lists:sort(
      fun(X, Y) -> byte_size(X) < byte_size(Y) end,
      [<<"some">>, <<"kind">>, <<"of">>, <<"monster">>]
    ).

I will let others decide which one is noisier.

(And no, using Erlang strings here is not the same, especially when popular libraries like Hackney and Cowboy work only with binary strings)

> Erlang is actually more terse than Elixir

Which was my point since the beginning but you quoted only part of my reply. It is clear Elixir has more syntax than Erlang. The function definition delimiters (->/.) vs (do/end) is a good example in itself of how Erlang is more compact and using punctuation.

I stand with my position that if you take actual code, a file or a project, and write it in both idiomatic Erlang and Elixir, Erlang will have more punctuation per character and will feel noisier.

Here is an actual example. I got the hex decoding/encoding code recently committed to OTP in Erlang (https://pastebin.com/qMtj8mSY) and rewrote to Elixir (https://pastebin.com/zUCLeXZG). I ran them through the Whatsapp formatter and the Elixir formatter respectively. Both snippets compile and define proper modules. If you remove all whitespace, the rate of punctuation character per alphanumeric character for Erlang is 35%. For Elixir it is 25%. And FWIW, in this particular case, the Elixir implementation has roughly the same amount of characters as the Erlang one: 718 vs 721.

I will be glad to continue this discussion if you want to use actual code instead of fictional examples.

EDIT: I fixed an error in the Erlang snippet and updated the stats.

Let's go back to the original statement:

> Erlang already is a more concise language than Elixir but also noisier as there are more punctuation characters.

Nope. Elixir has more punctuation characters, and I've shown that.

Now, when we talk about "punctuation per characters of code", then yes, Erlang may have more punctuation in this regard. But it has another thing going for it: there's significantly less syntax in general, and it needs less brainpower to disambiguate (BTW, Elixir's syntax is ambiguous to the point that the compiler can't figure it out in certain contexts).

Even in the examples you provided:

  defp encode_hex(<<a::4, b::4, rest::binary>>, acc) do
    a = encode_hex_digit(a)
    b = encode_hex_digit(b)
    encode_hex(rest, <<acc::binary, a, b>>)
  end
 
  defp encode_hex_digit(char) when char <= 9, do: char + ?0
  defp encode_hex_digit(char) when char <= 15, do: char + ?a - 10

Oh, look, it was `f() do ... end` but then all of a sudden `f(), do: ` (with no end). Whereas Erlang's syntax is (mostly) the same forms everywhere.

And where Erlang is consistent due to terseness of syntax:

  decode_hex_char(Char) when Char >= $a, Char =< $f ->
    Char - $a + 10;

Elixir is an agglomeration of punctuation:

  defp decode_hex_char(char) when char in ?a..?f, do: char - ?a + 10

I have complained about Elixir syntax in the past [1] when I knew little to no Elixir (I'm now building a big-ish side project in it), but the complaint mostly remains.

Meanwhile Erlang may look like it uses more punctuation, but that punctuation can be much easier pattern-matched by our brains because it's consistent and means the same in (almost) all cases.

[1] https://medium.com/@dmitriid/in-which-i-complain-about-elixi...

I accept that my original sentence was unclear. I mentioned more punctuation characters in the context of conciseness, which obviously takes the amount of characters into account. Other than that, I don’t dispute Erlang has less syntax and I hope it is clear that Erlang is noisier (assuming the definition of noise is punctuation / character).

Regarding the compiler, most compilers have ambiguity. It is the reason why you have to put a space between = and binaries in Erlang. The question is if the compiler is going to pick a side or require the developer to be explicit. Modern compilers prefer to fail early in such cases, rather than letting a syntax error pop up later on.

Furthermore, the use of do/end vs do: is completely up to you. My original draft had only the first, which reduced the amount of punctuation in Elixir further, but I decided to include both styles because you will find both in practice. But if you want to stay consistent, you have the option.

Finally, happy to disagree on the “agglomeration of characters” in the Elixir example. The Elixir code has less punctuation and is clearer, despite the use of “do:” (which, as I said above, is optional).

> Sometimes simply reading a switch statement or if/else/then is much clearer

Case statements are pretty common, and for code I read the with statement[1] is even more common. This allows you to code a happy path broken into small steps and then collect your edge cases. It doesn't solve every case for if/else or cases, but it's a nice tool.

[1]https://hexdocs.pm/elixir/Kernel.SpecialForms.html#with/1

I love with, completely forgot to mention it.

Don't know Elixir. Understand a bit about pattern matching from dabbling in OCaml and F#. Not clear about this:

>you have to basically mentally imagine what all cases are covered and what they mean

Why? Isn't the logic clearly specified in some way by the multiple dispatch/multi-methods? Because if not, how does the program work? So shouldn't a user be able to read the multi* code, and understand it, just like they can with if/else statements?

one difference is that you can really afford to be lazy with elixir. If your pattern match fails, one option is to let it throw a MatchError. Especially if the failure is rare, you just let the process die and your supervisors will restart the process into a sane state, and hopefully the next time you hit the code path it will be ok (for example: you are calling out to a 3rd party web service and they have a brief service outage, or some backhoe went over a network link and killed your packets).

The problem for a new technology like Phoenix that wants to dethrone an established player like Rails is that it's not good enough to be 50% better. It has to be 2x or 3x as productive to offset the smaller ecosystem and pool of developers. And I'm not convinced for most of the things that Rails is used for it's that big of a productivity boost.

As a Rails dev I have to say: Why trying to dethrone Rails? I don't get the Elixir obsession with Ruby/Rails (yes Jose Valim came from Ruby - so what?). Ruby is smallish enough, I don't get the obsesssion with going after that segment.

from my experience, Rails is not really much part of the general discussion in Elixir/Phoenix world. Sure, a number of us came from Rails, and lots of 'new to the community' discussions might hit on that, but that's a far cry from being 'obsessed' with dethroning Rails.

If anything, my impression is that a significant portion of the community still uses Rails for many of their applications, and some occasional grumblings aside, it's not a big deal.

Exactly!

> And I'm not convinced for most of the things that Rails is used for it's that big of a productivity boost

It could be a big productivity hit actually...

It's always interesting to read these and I completely agree with the author's comments on productivity (both on Phoenix and Rails). It's a major reason why I learn and teach Elixir, even though it's niche. I genuinely want the skills!

One thing to that stood out was how the author found deployment easy, the same as I first did 5 years ago:

> "The deployment of Phoenix can be as easy as copying the Mix release I already mentioned to the remote server. You can then start it as a systemd service"

I was using Distillery to make the release, but the workflow was virtually identic. Back then, the command to make a Distillery release was even "mix release", just as this author types for Elixir 1.9+ mix releases now.

> "Of course, you can make a light way Docker container too, but maybe you don’t even need to. Mix releases are entirely self-contained (even better than a Java’s JAR)!"

Also true!

I've found the release story to be lacking. For example, the suggestions I've seen for automatically running migrations after launch can blow up if you have traffic between the deployment start and the migration end. Even if I accept downtime, I've found mix annoyingly low level.

How do you run database migrations on Rails, Laravel or whatever your framework of choice is?

I wrote elixir for a couple years in a high scale environment, and I agree with OP on most of what he described. My favorite aspects, ranked: 1) immutable data / actor model paradigm 2) mix (super modern build tool that does it all) 3) pattern matching

i'm not a web developer but enjoy paying attention to this space from the sidelines.

elixir and phoenix are wonderful. the phoenix liveview is a fantastic piece of technology; it moves the processing to the backend and allows the web application to be developed in the same language (mostly).

i just recently discovered microsoft blazor and it seems like it's an even better improvement. compared to liveview, the computation is moved back to the client while the development experience is still a single language. there is no more javascript (at least that's the claim) and the platform takes advantage of webassembly to deliver a high performance UX. really compelling stack. I hope it continues to drive the innovation in web development. I'm so excited to see the javascript eat dust. Maybe light at the end of the tunnel to a horrible 10+ year period of web development.

I'm an Elixir developer, and I love the language, but I'm not sold on Phoenix LiveView. It sounds really cool, but it seems like there are too many edge cases. How do you scale it horizontally? What happens to user state when a connection is dropped? What do you do when you get a business requirement that hits one of LiveView's pain points? What if you have to swap out your backend for business reasons, and now you have to rewrite your frontend, too? I'm not trying to talk anyone out of LiveView; these are just the thoughts that prevent me from getting excited about it.

> How do you scale it horizontally

If you're using Phoenix PubSub for your message queue, then it scales out automatically over PG2 clusters.

There is now good support for keeping the data cashed client side, so that if your connection does drop, it can be restored once the connection is reestablished. That used to be a pain point, but as far as I have seen, it has been pretty well fleshed out now. This all happens mostly automatically, so you don’t have to worry about it. I think it’s just a parameter that you set to “true“.

My understanding is that some kinds of horizontal scaling are much easier than in other languages and frameworks due to the clustering magic you get for free.

https://elixirforum.com/t/phoenix-channels-horizontal-scalab...

https://www.phoenixframework.org/blog/the-road-to-2-million-...

What are people finding as the real sweet spots for Phoenix?

I have used Erlang very successfully in a semi-embedded context, but that's quite different from a web server that can usually be scaled horizontally pretty easily.

One obvious one is if you have to hold open a lot of concurrent connections like web sockets. It'd be great for that. Others?

It's pretty great anywhere that you might use Rails or Django, but if you expect spike in traffic that are hard to predict you get nice stable worst case latency.

I think it's also really good if you need to hold state server side for any reason.

Rails has a ton of high quality code available for it. It looks to me like Phoenix is certainly 'good enough' for a lot of tasks, but it just hasn't been around as long.

I'm looking for those use cases where someone picked Phoenix and it was just clearly a better tool than, say, Rails because of X, Y, and Z, despite maybe being inferior for one or two other things.

Having done both, I think Rails has a ton of baggage around ActiveSupport and ActiveRecord that are full of gotchas. Ecto prevents N+1 queries by default, which I think is clearly better. I also think that the lack of lifecycle hooks in Ecto is a better decision than the pile of foot guns in ActiveRecord hooks.

I would also argue that Plug is a large improvement over Rack, and the idea of explicitly passing a single context map all the way through the request is just a better way to build http responses. I also think that the Fallback controller is obviously a better way to handle common errors.

Anything related to web sockets will be leagues better in Elixir, because the BEAM is built to do a thing like that.

SSR html as a compiled linked list is a better idea than runtime string interpolation.

Sure, Rails has libraries for everything, but some of the core parts just aren't a nice. So if you don't need all of that breadth of ecosystem then Phoenix is a better choice IMHO having worked professionally with both for a number of years.

>Ecto prevents N+1 queries by default, which I think is clearly better

How does it know what associations to eagerly load without knowing about the views? It can't eagerly load all of the data on complex objects.

It doesn't eagerly load anything. It preloads exactly what you tell it to.

Ecto Repo vs Active Record: https://youtu.be/IFKG4Hgt-zM

So you have to be explicit in what to "preload"?

How does that differ from specifying an includes on associations for eager loading?

It's not saving you any mental energy; you still have to discern what should and shouldn't be loaded up front.

> Ecto prevents N+1 queries by default, which I think is clearly better.

To be fair...

If you want to protect yourself from these with Rails you can install Bullet[0] and get protection through in your face notifications, and you have the option to let it slide because you're taking advantage of caching with Rails and in this case you know what you're getting into and the N+1 query with caching ends up being better because you understand your domain.

Rails also has the strong migrations[1] gem which is a huge help for not shooting yourself in the foot for running migrations in production by helping you avoid table locks and other issues / errors. But AFAIK there's no Ecto equivalent, but strong migrations is really really useful.

Rails also has the data-migrate[2] gem which is a nice little abstraction for splitting out your schema changes and backfilling data in an automated way. There's nothing like this with Ecto. This one isn't as useful as strong migrations IMO but it's still very handy to have this problem taken care of for you without having to re-invent a new strategy in every project or copy code over.

Basically all 3 of these things are something I'd use in every Rails project but with Phoenix I wouldn't have these things except for N+1 query protection.

I'm pretty sure you could technically create strong migrations and data-migrate for Ecto but the reality of the situation is today neither of them are available and there's no sign of them coming anytime soon. Meanwhile strong migrations has had ~6 years worth of real world testing at this point.

[0]: https://github.com/flyerhzm/bullet

[1]: https://github.com/ankane/strong_migrations

[2]: https://github.com/ilyakatz/data-migrate

For a lot of people and teams, having to know about and rely on a bunch of third party dependencies (not seldom the effort of one or a few developers without financial support) is not a positive thing. Not saying these specific gems are a problem, just the general mindset in the Ruby and JS world (although Ruby is a lot better) to just go and depend on the work of others for core functionality.

> For a lot of people and teams, having to know about and rely on a bunch of third party dependencies (not seldom the effort of one or a few developers without financial support) is not a positive thing. Not saying these specific gems are a problem.

I think this is a really great discussion point btw because depending on a ton of 3rd party libraries that come and go can be an issue for sure.

But at some point you need to live in the moment and align your expectations with the current reality and think about what happens to your code base if the library stops being maintained.

For example, strong migrations has a 5+ year track record and shows no signs of dying. It doesn't make sense to live your life in fear and avoid 3rd party libraries because one of them might go away in the future because the maintainers get bored or stop using it. Because what happens if that doesn't happen and it ends up being wildly popular and maintained for years?

The reality is a lot of people develop libraries, use it for a while time and then move on. This happens in Elixir too. The ExAWS package comes to mind (the most popular AWS package for Elixir). Similar things happened with Arc (file uploads) too. Eventually those tools got replacements or new maintainers.

If you're developing an application it makes sense to weigh the pros and cons on using certain libraries but it's not like these libraries immediately go away. Usually there's a huge amount of notice before a library becomes officially dead. There's also tons of opportunities to talk with the authors and collaborate with the community to keep it going. And in this case, the outcome is likely a lot better than you trying to develop a custom solution in total isolation that's not open source.

So yeah, there's really no downside to using most 3rd party libraries. Either it fits your app well enough and continues to be maintained while you happily use it (and maybe contribute back changes), or it fizzles out and you got some value out of it and now you have a great head start in implementing a custom solution from it for your unique use case.

I will grant that strong_migrations is really cool, and data migrate is nice but not really that hard to implement yourself if you need that. Bullet however IMHO is a way overly complicated way to solve for N+1 queries. I would argue that eager loading associations by default is wrong and a thing ActiveRecord shouldn't do at all.

You can opt in to preloading with Ecto when you consciously want to make the tradeoff, which I think is a better default approach.

I can add a bit of my experience. I used Rails here and there since 2.3 and have followed Elixir since its inception.

- Channels in Phoenix are just a joy to use compared to ActionCable. This is partly due to the language (pattern matching, especially) but not having to deal with a Redis instance (and/or AnyCable) is also appealing. It just works out of the box and is ridiculously performant.

- I find the Repository pattern much easier to wrap my head around than ActiveRecord. I feel like with Rails, I always have to know the state of an object whereas w/ Ecto, things are more explicit. I know some people prefer AR here, but I prefer not making an accidental query.

- I feel like I am lost every time I'm in a Rails project with so many abstractions now. Maybe this is me being a curmudgeon, but I remember being able to trace request all the way from where it hits the machine (say, Nginx) to the HTML rendering even with Rack. Now, if I had to do something similar, there are so many layers to peel. This is again partly due to the language, and partly to Rails' age.

In terms of language, Phoenix is a complete replacement for Rails for me. I feel more comfortable growing a functional codebase, and the BEAM means I don't have to worry about scaling as soon as I would with Rails. I think it's a good fit for when you want to do more with a small, experienced team.

I would reach for Rails when I'm concerned about finding developers (Elixir devs are fewer and more expensive, generally), or if there are Ruby libraries I want that aren't available in Elixir.

I fear it would be difficult to hire Elixir people as well, but now I realize it's actually also hard to hire decent Ruby/Rails people. Honestly I think we should just accept anyone who can demonstrate thinking and programming skills of any language and then plan for 2-3 months of ramp-up time to get them into our language of choice.

I agree, and to be clear I've never really been in a position to worry about hiring anyway. But I would imagine building a medium/large team with varying experience levels (including juniors) would be easier with a more established framework like Rails.

I'd be happy (if I were job-hunting) to be able to try out a different language/platform every so often. Now and again I'll play with, say, Ruby or Elixir or whatever. But I know that I'll never get a job working with these languages because I don't have the n years experience with them. The tech hiring process is gruelling enough with languages and frameworks we are familiar with, your resume won't even get a glance if you apply for jobs where you don't have that experience. But I think that narrow thinking is to everyone's detriment.

I've seen at least a few Elixir jobs where they explicitly specify that you don't need to have experience specifically with Elixir. Don't know how common it is though, and it's true that finding Elixir work can be difficult to begin with.

I worked at a well known company running Erlang. Out of maybe 25 people hired to work on software in Erlang, I think two had used it before, and they were hired several years after Erlang became our key enabling technology. I was ahead of many because I remembered seeing the slashdot post when it was open sourced.

If you hire smart and flexible people, and give them a bit of time to learn the syntax, Erlang and I assume Elixir will bend their mind to a new shape, and they'll be fine.

Figuring out what you want the computer to do, and what steps will be needed are much more important than the specific syntax you use.

I find elixir and supporting libraries to be the best general web-dev experience of any language. Optional typing, first class documentation, ecto as a library for validations is far more successful at encouraging separation of concerns than I've seen in other CRUD webdev ecosystems.

The performance for typical stateless webapps is great, but honestly the thing I love is the amazing tooling and libraries. Elixir libraries are often very high quality.

+1 for Ecto, really a game-changing library.

> ecto as a library for validations is far more successful at encouraging separation of concerns than I've seen in other CRUD webdev ecosystems.

Which other ecosystems have you tried?

Just asking because with Python and WTForms they've kept validations separate from your model for the last ~10 years.

You could for example create "sign up", "sign in" and "profile" forms based off a single user model and each form has its own fields that you can define with their own validations. Very similar to how you can create separate changesets with Ecto and use a single user schema.

Looking purely at webapps, Liveview is the killer feature of Phoenix.

Other than that, I would say that any place with a complex service oriented environment where you could leverage the Erlang VM would be an obvious place to use Phoenix for doing your webapps.

> I have used Erlang very successfully in a semi-embedded context

Elixir is really quite good in the semi-embedded space with several successful companies having their IOT bread and butter in Elixir Nerves platform. The deployment story is getting really mature in Elixir.

The article has some really salient points: Testing and Documentation and really amazing in Elixir. Concurrent tests are amazing. So for example normally a "database" would be a global resource and running concurrent tests against the database is really tricky. It's basically turnkey in Elixir (need to set up two settings).

With a bit of work, it's not terribly hard to write concurrent tests that exit the VM and come back into the vm and use a test-shard of a global resource. So, for example, you write a test that issues an HTTP request to itself, and the request is instrumented with parameters to connect it back to the test process and use the correct "temporary shard" of the database. (In the case of the database it's a transaction, I use the phrase "temporary shard" because the same mechanism can extended to other concepts too, like module mocks, ets tables, process registries, etc, which all use the same mechanism, you only have to set it up once).

> Elixir is really quite good in the semi-embedded space

Yeah, I don't need any convincing there. Erlang was a perfect fit for the device I worked on. High level enough to get things done quickly, but with a really solid, predictable runtime.

>> but that's quite different from a web server that can usually be scaled horizontally pretty easily

So a lot of the other responses are comparing it against Rails and the like, but it sounds like you may be asking specifically around scaling.

Erlang (and by extension, Elixir), is nice even when scaling because the actor model will scale to I/O or CPU bound workers simply, without having to tweak threadpools or worry about thread starvation or etc. Other languages that provide n:m concurrency here have the same benefit though (i.e., Golang).

Where it shines in comparison to those is in its fault tolerance and memory model. Immutable non-shared data + supervisor hierarchy gives you tools to tackle state that are less error prone than most other languages.

And the fact it has a Rails like environment in Phoenix (and Plug, and Ecto, and the whole ecosystem) means you get the same quick-to-build app functionality, without giving up the performance and state management.

It's basically having all of these that make it desirable on this front; you can write code as quickly and simply as in Rails, getting the braindead simple scaling behavior of any actor/CSP based model, with the state management of an immutable language, and the fault tolerance of Erlang.

Not that concerned about scaling - I think it's going to beat Rails there, but for a larger web app growing quickly, the difference between going to N web servers from 1 might not be that many months.

Oh, sure, Erlang isn't going to save you from going multi-node...in fact, it shouldn't; just basic resiliency should mean you're starting multi-node.

But the actual number of concurrents per instance, and the effect on latency, is quite another thing.

And it also provides you a better story around shared state within the instance, and better controls around its access.

Fast templates are a superpower for our CMS. Combine it with LiveView to eliminate react and we deliver a really good site quickly.

We used Elixir to implement a columnar database and Phoenix for the web front end, which was about 20% of the code. It’s very convenient having all the tests run together, including end to end integration tests. Elixir (with NIFs) has the necessary performance for the database layer, and Phoenix has the necessary productivity for the web layer, and we don’t have to switch languages to work on both.

Pretty curious about this, are there more details that are publicly available? The only thing I can find about this is some meetup from 2018 with a speaker from Pinterest.

I, too, want to hear about this mythical columnar database in Elixir (or databases!!, if there are two!).

If not we'll have to write our own by duct taping multiple instances of DuckDB. :)

Elixir with Phoenix feels like programming with simple and straightforward abstractions around HTTP server, HTML generation and DB querying. Ruby on Rails feels like some sort of divine incantation. Rails has a lot of magic and hand waving, and there are recipes for doing everything that you would ignore at your own peril. I don't get the "hold on to your butts" feeling with Elixir.

At work I am building a new internal project in Phoenix Live View and the developer experience so far is sublime. The entire Elixir ecosystem is an absolute joy to use. In the early life of an application, you get the incredible productivity of Ruby on Rails, while building on the battle-tested OTP platform that can scale with your business. The language itself combines the best of Erlang, Clojure, and Ruby all under one roof.

Big fan of Elixir. First and third party libraries are typically very high quality; community support is great; and documentation is best in class.

Right now, I’m trying to find a way to speed up builds in CI because they’re the biggest bottle neck to deploying. Building an umbrella with 5 apps, 3 of which are phoenix, leveraging parallelised docker buildkit, will still take 8~ minutes.

Interesting. Elixir builds are the fastest builds in my CI pipelines. I make sure to cache the builds/ folder; usually only a small amount of files need to be re-compiled, which is very fast. This was actually improved even further in Elixir 1.11 [0]. Compared to TypeScript + React and Java, Elixir build times are significantly better.

[0] https://github.com/elixir-lang/elixir/blob/v1.11/CHANGELOG.m...

"Elixir is not an object-oriented language. We practically only write modules and functions. This helps tremendously in understanding code..."

Sign me up. I hold hope that Elixer is the thing that starts pushing the knife into OOP. Microsoft has added a ton of features to make functional style a thing in C#, and nearly everyone hates Java...so maybe the stars are aligning.

Agreed. OOP is obnoxiously convoluted at times and—I feel anyway—never fully delivered on its promises of reuse. I've been using Elixir for about five years now and I never want to write another line of OOP code. I don't care what language it is in.

This has been my experience as well. I left Elixir for a brief stint with Kotlin, a modern OOP language, and it was jarring how many abstractions and incidental complexity I had to wrangle with to be productive and ship well-tested features.

I have a dream that one day most of our software will be built with something like elixir and most of the saas products we're using now (octa, zapier, newrelic...) will be just installable modules with a simple api

last hype train i joined, was scala... this language reminds me of scala... a HORRIBLE developer experience, yet we zerglings are happy to be lemmings to someone's "best idea evah"

This brings up the pain of scala... only this time im not going to join the fan club.

I wish more Node.js people shake off their Stockholm syndrome and check out Elixir and Phoenix.

Let me tell you the single reason I haven't switched to Elixir yet: I develop backend and frontend (SPA) so I'd rather just stick with a single language and library catalog. It helps that there's plenty of libraries in JS land too. I would love to just write elixir code but at the end of the day I feel sticking with node+browser js is the more pragmatic choice right now.

Isn't phoenix meant to remove the JS dependency on FE dev? (Not arguing with any of your points btw, JS is matter-of-factly more popular and pragmatic).

I just implemented a thing for work in very bare Phoenix Liveview. It integrates with Plaid. I definitely needed hooks and about 200 lines of JS to get it working. You can't completely kill JS, yet, unfortunately.

Was it your integration with Plaid that required the 200 lines of JavaScript?

I've spent the last year building out a web application for service providers to use to manage disaster recovery software for multiple clients using Elixir, Phoenix, LiveView, and TailwindCSS. We haven't used a single line of JavaScript code, including for the Tailwind components that typically rely on JavaScript to function. LiveView has been able to handle it all.

Correct, it's entirely the plaid integration. Actually I cleaned up the code considerably since writing that statement and now it's about 100 lines.

I wish I could have better integrated tests with the javascript, but considering, the live view suite of tests is really quite good.

I agree that JavaScript is more popular, but I think it is the least pragmatic language I've ever used.

In my mind, a pragmatic language doesn't do things like:

1. Have multiple ways to define a function. 2. Handle functions differently depending on how they're defined. 3. Allow silly things like 2 + "2".

I so wish Elixir had a strong type system

It has a strong type system. Are you mixing static and dynamic typing with weak and strong typing?

aha, right! I meant, static typing

Oh no same crap of mixing hash symbol and string keys as in ruby? You didnt have to borrow that Elixir! Does Elixir also have HashWithIndifferentAccess?

Honest question, why is this a problem?

Just google HashWithIndifferentAccess...

I get a feeling that it is just a band aid because of unsanitized data and sloppy coding practices.

If you subscribe to the philosophy of sanitizing and validating user data on the edge as soon as you receive it and then stick to using whatever data type you decided on, this is much less of a problem (any mismatch in runtime would then be considered a bug).

Elixir does not have HashWithIndifferentAccess

Not built in, and not remotely suggesting anyone use this, but as an experiment I did build this a few years ago as a toy/to play with a few ways it might look if we ever wanted something similar.... https://hex.pm/packages/indifferent_access https://github.com/bglusman/indifferent_access (see also https://github.com/vic/indifferent )

Typically string key maps should exist only at the edges of your system, but they are still often necessary when you're interacting with the outside world. Params in Phoenix come in as a string key map because the atom table does not get garbage collected, so where you don't know what keys may be passed in, string keys are necessary to avoid the risk of running OOM. That said, once I know the shape of the data I'm dealing with, I pretty much always convert to an atom key map as quickly as possible. If I see a string key outside of the context of a controller or worker, I am immediately suspicious.

You really should never mix them, String keys are basically only there for accepting untrusted input, and should get sanitized. Any internal map should only have atom keys. String keyed maps exist so that you can accept inputs from untrusted sources without worrying about a malicious or malformed input from overflowing the atom table and crashing your VM.

Well you can use any datatype you want as a key in a map. It wouldn't make sense to not allow either atoms or strings.

Reply on news.ycombinator.com