Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elixir for Humans Who Know Python

hibox.live

Post reply on HN
Print view View original

41–50 of 198 posts

Re: Elixir for Humans Who Know Python

#41

Post by josevalim »

KyeRussell wrote: post #36
michaelteter wrote: post #5

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

It is perhaps utopia but it would be nice if we could discuss those topics without falling into camps.

For example, I could argue for hours about the benefits of immutability, but I still believe that imperative loops are clearer than functional ones. There is even a repository with solutions for nested traversals in different languages and the Python one is my preferred by some margin: https://github.com/josevalim/nested-map-reduce-traversal

Re: Elixir for Humans Who Know Python

#42

Post by [deleted] »

marhee wrote: 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…

[deleted]

Re: Elixir for Humans Who Know Python

#43

Post by IceDane »

shaundon wrote: post #24

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…

Which part of this app is using LiveView? Since what you link to is using next.js. Are you guys mixing the two?

I really want to find a reason to build something with elixir, and it might be viable for my current work project. We won't be replacing our next.js frontend, though, that's for sure, though I wouldn't mind experimenting with it.

I'm mostly interested in deploying elixir on the backend, since we are using microservices, and there would definitely be a couple of services where elixir seems like a great fit. OTOH, we are also pushing some data through ML models, and it seems like Python is still the only real choice for this kind of stuff. I really wish it weren't the case, since the python interpreter with its GIL is just a piece of crap, to be frank.

Re: Elixir for Humans Who Know Python

#44

Post by noloblo »

michaelteter wrote: post #5

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…

I think this article does capture the magic of elixir phoenix live view that is impossible in the async await madness hell in python. I cannot wait to try elixir Phoenix live view, elixir |> pipes, :atom pattern matching and ets pids to send and manage processes across servers none of these AFAIK are currently possible with the GIL and single threaded nature of python

As the venerable prof Joe armstrong would say

you need erlang and haskell for fp you need c for high performance you don't really need cpp Java python c# etc

Also as an aside does anything in haskell have something similar in spirit to phoenix or live view?

Re: Elixir for Humans Who Know Python

#45

Post by josevalim »

ralmidani wrote: post #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…

If you don’t mind, I have some questions as I would like to learn more. Are you aware of a large models.py for reference and learning purposes? Is it expected to define the schema of all my models in a single place but none of the logic?

Also, don’t you run into scenarios in Django where the automatic migration is not enough and you need to provide custom commands? In such cases, how do you provide them?

And can you have scenarios where you have two models pointing to the same table, but perhaps to a subset of fields (this is specially useful in read-only cases)? How is that handled?

Thank you :)

Re: Elixir for Humans Who Know Python

#46

Post by RandomWorker »

Mizza wrote: post #25
RandomWorker wrote: post #11

As someone that is deep into a Python web development, I see where this can be useful. However, after 1/3 down of the article it gets harder and harder to wrap my brain around the concepts without really learning elixir syntax. I feel like it would have been better to have 10 smaller articles than this long one, going deeper into the syntax and showing other example of Python way of doing it. I’m not sure I would do…

Author here. This blog post originally started out as just notes to myself as I was learning the language, so it's basically a brain-dump wrapped in a little prose to give people some exposure to the language. I still love Python, but I think Elixir is a great tool to have in the toolbox.

Hi there commenter here. Thanks for writing the article, I will return on it maybe in a year or so. I started learning Clojure this year and it’s quite a journey. But functional programming is the future I’m convinced. Cheers.

Re: Elixir for Humans Who Know Python

#47

Post by dudul »

ralmidani wrote: post #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…

Aren't you confusing Phoenix and Ecto here?

I'm familiar with neither Rails nor Django so I dont fully follow what you're describing. Are you just talking about the difficulty of maintaining the schema/DB mapping with the migrations ran against the DB?

Re: Elixir for Humans Who Know Python

#48

Post by Xzya »

I have been working on a library for Django that allows you to build reusable template components, and it is heavily inspired by Phoenix's Components. I just released it today, so if you are a Django user and find the way that Phoenix Components work interesting, give it a try!

https://github.com/Xzya/django-web-components

Re: Elixir for Humans Who Know Python

#49

Post by Existenceblinks »

KyeRussell wrote: post #39
Existenceblinks wrote: post #20

Earlier quoted context omitted.

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.

Yeah, right place, right time, knowing right people. I think it's close to impossible to go through from front door cold.

Re: Elixir for Humans Who Know Python

#50

Post by marhee »

josevalim wrote: post #37
marhee wrote: 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…

You could reuse df (as the method presumably change df), in addition:

- you have more room to comment what the intention of the code/call is

- you have room to handle / check for errors

For example, the "sort_values" and "groupby" in you example are obvious most readers. But "transform("cumsum") is probably obvious to you but I don't know the intention of the code.

By reassigning to df it makes it clear that the returned value from each of the functions is a `df` (some kind of query builder I think). Actually rewriting you r code I discovered your groupby did a groupby and then selected a result column I think.

So we would get:

   // sort result on dependency date 
   df = df.sort_values('dep_date')

   // ... check if sort_values worked (i.e `dep_date` is valid column)

   // group result by name and select duration column 
   durations = df.groupby('name')['duration']

   // compute columns cumulative sum of durations
   sum = durations.transform('cumsum')
I agree its much more verbose, so this won't work if you (just) want conciseness.
Post reply on HN