Live data from Hacker News

Elixir for Humans Who Know Python

hibox.live

31–40 of 198 posts

Re: Elixir for Humans Who Know Python

#31
My perhaps slightly biased input on Python vs. Elixir (I worked with Python for different projects for a couple years, and have been using Elixir full-time for ~1.5 years).

Elixir as a core technology for application development (as opposed to data science/ML/AI - it’s still early days for Nx/Axon/etc.) is better than Python in just about every way that matters; e.g. immutability by default eliminating whole classes (no pun intended) of bugs, having the full power of OTP available if you need a distributed system, more convergence around libraries and frameworks (to the point that José Valim also works on Phoenix, LiveView, Nx, etc., not to mention having Mix, EEx, and ExUnit built in).

I do wish Elixir had significant whitespace rather than do/end, but that’s not a hill I’m willing to die on…

My one major gripe with Elixir’s ecosystem compared to Python’s is that, IMO, Django would have been a better source of inspiration for a dominant Web framework compared to Rails; Django’s model layer is top-notch, with all your basic model information for an app contained in one models.py file. In Rails and Phoenix, you don’t get auto-migrations out of the box for simple use cases, and your model layer ends up being distributed across schema/ActiveRecord files, a “structure.sql” or “schema.rb” file, and the migrations. In my real-world use, this has been… “sub-optimal” compared to Django, to the point that I sometimes dream about building my own Django-ish framework for Elixir. Django+Django REST Framework are that good - if you stick with Python and are not using them already, do yourself a favor and check them out.

Also, Django’s admin is old, crusty tech, but it does what it set out to do really well.

I will admit Django’s implicit queries can cause DB performance issues, I wish there was an explicit analogue to Ecto’s Repo.* functions to force devs to think about when to make the DB call.

Re: Elixir for Humans Who Know Python

#32

I've been using Elixir with Phoenix and Liveview at my job for the past three months as part of a small team building a non-trivial web app ( https://duffel.com/links ). I'm mostly a front-end developer and was brought in to handle the UX side. Prior to this project I've spent the last 5+ years in the React world. I found a lot of what the author says to be true. I'm used to the nightmare that is managing front-end d…

Serious question—if you were on a tight deadline, why did you choose a tech stack that you still had to learn? Leveraging existing knowledge is exactly what anyone in a rush should be doing.

I wasn't personally involved in making this decision, I was brought onto the project after it was taken, but there was a perception that we'd be faster if we did everything as a full-stack application. In fairness, we did deliver what we set out to do so it was a success, even if there were some rough edges to deal with.

Also bear in mind that I'm only covering my front-end perspective on this. I think the back-end developers involved on the project found it much easier to work with as they were already experienced with Elixir and Phoenix. For them, a tightly-coupled front and back end meant that they could change the way things worked and it was straightforward to update a few functions in Elixir and then the HEEX template, as opposed to a decoupled setup where we'd probably have been communicating using a JSON API and changes would have had more of a barrier to adopt.

Re: Elixir for Humans Who Know Python

#33

Earlier quoted context omitted.

I've got experience in both Phoenix and Django and I disagree. In my view, Phoenix is the less clean one: Django does not generate anything through scaffolding like Phoenix. Your CRUD (and auth and forms and everything more or less) is generated by overring the built-in Django classes or the classes offered by the packages. Nothing gets thrown away in real production; you use your class hierarchy to change it to your…

> Django does not generate anything through scaffolding like Phoenix I was one of the co-authors of Devise, which is an integrated authentication solution for Rails (similar in spirit to Django), and you will easily find people who swear that the code generation solutions are miles better. That’s because eventually they’d want to customize how the framework or library work and then, instead of simply being able to ch…

Is there a channel where we can share suggestions for the upgrade guide?

I think it would save people some time if the phx 1.6 -> phx 1.7 upgrade instructions started with the following two steps:

1.) Upgrade LiveView to 0.18.x (with link to https://hexdocs.pm/phoenix_live_view/changelog.html#0-18-0-2...)

2.) Update web.ex macros for Phoenix Component (with link to https://hexdocs.pm/phoenix_view/Phoenix.View.html#module-rep...)

Then the upgrade doc will work and people won’t get stuck trying to follow those instructions with a Phoenix 1.6 app using whatever version of LiveView they had before.

Re: Elixir for Humans Who Know Python

#34
> The pipe operator, |>, passes the output of a function to the first argument of the next function. So, instead of writing something like:

foo(bar(baz(new_function(other_function(my_input)))))

You have the option to write:

my_input |> other_function() |> new_function() |> baz() |> bar() |> foo()

The readability benefit is clear - you don't have to read the code "backwards" to understand what it really does.

—- (end of snippet)

This is a nice example of fixing a problem that does not need be there at all.

Just use intermediate variables instead of doing clever stuff. Benefits:

- 1 way of doing stuff

- variable names will help readers understand the intention of the function calls

- you can do explicit error handling for each call

Note: in contrast, in shell prompts the pipe operator is useful because:

- less typing counts here

- prompts are use-once mostly, maybe repeated (history & scripts), but readability is not a mayor concern

- commands deal with large amount of data often, hence storing in intermediate variables can be expensive or even impossible.

None of these points are valid for a programming language. (Unless of course you just fancy the syntax)

Btw I find the joke about “bearded wizards” not very inclusive towards women. It feels assuming that only men (can) be that wizardry.

Re: Elixir for Humans Who Know Python

#35

Earlier quoted context omitted.

> Django does not generate anything through scaffolding like Phoenix I was one of the co-authors of Devise, which is an integrated authentication solution for Rails (similar in spirit to Django), and you will easily find people who swear that the code generation solutions are miles better. That’s because eventually they’d want to customize how the framework or library work and then, instead of simply being able to ch…

Is there a channel where we can share suggestions for the upgrade guide? I think it would save people some time if the phx 1.6 -> phx 1.7 upgrade instructions started with the following two steps: 1.) Upgrade LiveView to 0.18.x (with link to https://hexdocs.pm/phoenix_live_view/changelog.html#0-18-0-2... ) 2.) Update web.ex macros for Phoenix Component (with link to https://hexdocs.pm/phoenix_view/Phoenix.View.html#m…

Please open up an issue.

Re: Elixir for Humans Who Know Python

#36

No offense to TFA author, but I don't think this is doing to sell Elixir to Python people. In fact, I have serious doubts as to whether most Python lovers would be willing to set aside their beliefs and practices to learn the Elixir way. Perhaps Phoenix and LiveView will be the gateway drug, but even to reach that point requires a lot of effort to understand functional programming and Elixir. Python has some function…

It seems like the basis for your comment is weird stack tribalism that you’ve very evidently bought into, rather than anything actually…worth discussing.

It then comes as no surprise that throughout your entire comment you didn’t seem willing you yield any ground to Python or Django at all.

It then comes as no surprise that your assertions about Django are counter to my experience, as someone that by the sound of things has worked with Django a lot more than you have.

I have only worked on one production Django project that *didn’t^ use Django’s auth system. And the fact that you call Django’s generic class-based views “scaffolding” - a term that I seldom hear in Django spaces but hear all the time in Rails spaces - further speaks to your lack of familiarly. Most production Django projects I’ve worked on have made extensive use of either these generic class-based views or the Django REST Framework analogues, which - whilst not part of core Django - still speak to the usefulness of the pattern.

It honestly sounds like your experience with Django - if any - has been treating it like Rails. Which - honestly - is mostly fine. In my eyes, the frameworks are comparable in…most ways. But your assertion that these batteries are thrown away in production contexts is just wrong. Unless you want to tell me that I’ve spent ~a decade earning a living working with Django and somehow not managed to do any “real” work, perhaps consider the global applicability of your personal experience.

It’s really disappointing to see the re-uprising of Ruby (and Elixir) developers positioning themselves as the enlightened elite against the hoards of plebeian Python developers. I without a doubt include your comment in this critique. I understand that given Elixir’s increased FP focus that the community can’t avoid FP elitism. Doing it for Ruby though? It’s just cringey. I’ve got no beef with Ruby, Rails, or the development communities of either, except for the fact that people are feeling the need to pick up this ridiculous turf war.

Given that Python is my daily driver, Python spaces are where I’m usually active in. Ruby is seldom mentioned. Whenever I go to a Python-related HN thread, I don’t have to scroll far to see some Ruby developer making some thinly veiled assertions that Python developers are un enlightened idiots. If I look at a Ruby thread, there’s always someone salty about not being able to get the Python drones on their team to use the One True Language. It feels like I’ve gone back in time 15 years.

Re: Elixir for Humans Who Know Python

#37
post #34

> The pipe operator, |>, passes the output of a function to the first argument of the next function. So, instead of writing something like: foo(bar(baz(new_function(other_function(my_input))))) You have the option to write: my_input |> other_function() |> new_function() |> baz() |> bar() |> foo() The readability benefit is clear - you don't have to read the code "backwards" to understand what it really does. —- ( end…

I would find such principled approach to be unproductive. The same could be said about Python, the `.` is equally syntax sugar for passing the object as first argument. So if we take this Pandas code:

    df.sort_values('dep_date')
      .groupby('name')['duration']
      .transform('cumsum')
If we were to pass df as first argument in nested calls, I would find it less readable. But I would also find using variables in this case to be more noise than helpful:

   sorted_df = df.sort_values('dep_date')
   grouped_duration_df = sorted_df.groupby('name')['duration']
   grouped_duration_df.transform('cumsum')
The variables are just repeating some of the information found on the right side and IMO they end up getting in the way of understanding the whole pipeline.

Re: Elixir for Humans Who Know Python

#38

Earlier quoted context omitted.

Is there a channel where we can share suggestions for the upgrade guide? I think it would save people some time if the phx 1.6 -> phx 1.7 upgrade instructions started with the following two steps: 1.) Upgrade LiveView to 0.18.x (with link to https://hexdocs.pm/phoenix_live_view/changelog.html#0-18-0-2... ) 2.) Update web.ex macros for Phoenix Component (with link to https://hexdocs.pm/phoenix_view/Phoenix.View.html#m…

Please open up an issue.

Okay! Will do.

Re: Elixir for Humans Who Know Python

#39
post #13

I was randomly watching youtube videos about Elixir ("The Soul of Erlang and Elixir " by Sasa Juric), and I have never really been interested in it... I was completely wrong. BEAM/Erlang is amazing piece of technology, and Elixir does excellent job to bring in new people in. If you do web development, then just for the sake of professional curiosity, I urge you to go watch a couple of videos to make yourself in idea.…

5+ years elixir exp here, about to take python/django job. Why do you feel sad! I just gave up finding elixir jobs for a couple months.

I work for an org that does a lot of Elixir (on other teams though, I’m actually a Django developer!). I’ve heard from those team leads that they’ve had trouble hiring people with FP / Elixir experience, which is not that surprising to me. Guess it’s a matter of right place right time.

Re: Elixir for Humans Who Know Python

#40
post #34

> The pipe operator, |>, passes the output of a function to the first argument of the next function. So, instead of writing something like: foo(bar(baz(new_function(other_function(my_input))))) You have the option to write: my_input |> other_function() |> new_function() |> baz() |> bar() |> foo() The readability benefit is clear - you don't have to read the code "backwards" to understand what it really does. —- ( end…

No downvotes from me btw, but I think the author and just about most people using Elixir (which tends to not be a first language for most in the community) have used the classic-style of temporary variables for lack of any other option. Certainly in my own experience the pipe operator has eliminated those redundant expressions rendering the code more concise, expressive, and hence more readable. Many APIs in other languages emulate something similar with method chaining for this very reason (see Fluent APIs).

Extracting variables out of if-expressions can still be useful for improving readability of long boolean expressions though.

Post reply on HN