Live data from Hacker News

Elixir and Phoenix after two years

nts.strzibny.name

91–100 of 111 posts

Re: Elixir and Phoenix after two years

#91

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?

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

Re: Elixir and Phoenix after two years

#92

Earlier quoted context omitted.

> 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([…

The example that you picked and wrote translates to this in Erlang: lists:sort( fun(X, Y) -> byte_size(X) >, >, >, >] ). 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…

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(>, acc) do
    a = encode_hex_digit(a)
    b = encode_hex_digit(b)
    encode_hex(rest, >)
  end
 
  defp encode_hex_digit(char) when char 
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 =
    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...

Re: Elixir and Phoenix after two years

#93
post #3

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 mult…

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.

Re: Elixir and Phoenix after two years

#94

Earlier quoted context omitted.

> 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([…

The example that you picked and wrote translates to this in Erlang: lists:sort( fun(X, Y) -> byte_size(X) >, >, >, >] ). 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…

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

Re: Elixir and Phoenix after two years

#95
post #44
post #36

Earlier quoted context omitted.

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…

> 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

Re: Elixir and Phoenix after two years

#96
post #7
post #2

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?

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 libr…

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

Re: Elixir and Phoenix after two years

#98

Earlier quoted context omitted.

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.

Re: Elixir and Phoenix after two years

#99

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

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?

Re: Elixir and Phoenix after two years

#100
post #95
post #44

Earlier quoted context omitted.

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…

> 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 b…

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.
Post reply on HN