Elixir for Humans Who Know Python • Hacker News Board

Re: Elixir for Humans Who Know Python

#61

Post by l_theanine » Sat, Feb 25, 2023, 2:18 PM UTC

LiveView can’t handle spotty connections, I thought?

Career python expert, not huge into Django/we dev in general…

I thought the whole thing with most HTML over the wire is that its tied to the connection latency? Unless there’s some js component underlying the Elixir code that I don’t know or don’t understand.

With the advent of things like flask+html, I find it a little hard to believe that Elixir hackers could whip up a MVP faster than I’ve seen it done with flask.

I’m not opposed to functional programming by any means, but just because the language embraces it doesn’t qualify all the constituent frameworks to replace world-class solutions like Django.

Re: Elixir for Humans Who Know Python

#62

Post by josevalim » Sat, Feb 25, 2023, 2:18 PM UTC

marhee wrote: post #50

josevalim wrote: post #37

Earlier quoted context omitted.

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

If you reuse the variable, then you are not getting any of the alleged benefits of using variables. The same name tells little except it is perhaps the same data type and in Elixir you would also get this information from the module you are invoking:

  text
  |> String.split(“,”)
  |> Enum.join(“ “)

You could also equally add comments between the lines in the dot example:

    df.sort_values(“dep_date”)
      # group and select
      .groupby(…)[…]

Although most of the comments above are discardable (IMO) because they are restating the code.

My point is: sometimes I will break out into variables to get some of the benefits you mention. But forcing all intermediate steps to assign to variables is as harmful as using “|>” or “.” exclusively and forgetting about variables altogether. If you need to add error handling, code comments, etc, you can break out of the pipeline as needed.

Re: Elixir for Humans Who Know Python

#63

Post by h0l0cube » Sat, Feb 25, 2023, 2:25 PM UTC

marhee wrote: post #50

josevalim wrote: post #37

Earlier quoted context omitted.

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

> won't work if you (just) want conciseness

I think Jose's example provides the best of both worlds, conciseness and readability.

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

There's nothing stopping each pipe expression from having a comment of its own if you lean towards literate programming, or you feel that the pipe function + arguments begs further explanation to unfamiliar developers.

> you have room to handle / check for errors

You can pipe your results into a validation function. Ecto, the go-to database mapper, has exactly this pattern. Failing fast is idiomatic Erlang/Elixir (rather than let the process live on with corrupt state) which means if the validation fails, it ought to raise an exception so the external caller can fix their call/request, or if it's a bug, the developer can be alerted to fix the code.

Re: Elixir for Humans Who Know Python

#64

Post by traverseda » Sat, Feb 25, 2023, 2:26 PM UTC

josevalim wrote: post #45

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…

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

Django models are normal python classes. Depends on exactly the logic you're dealing with, but generally you can make logic be a method on that class. Try to avoid logic that spans multiple tables in general, and if you have logic that does span multiple tables you probably want it to be a function and not a model method.

There are also signals that get sent on different things like model delete/create/etc, but they're to be used even more sparingly.

Logic for querying data should probably go wherever you're going to use it and you should just pass the model objects directly to your views. To start don't worry about optimizing queries or the n+1 problem, but as you get more experience you can use `prefetch_related` in order to avoid the n+1 problem.

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

You shouldn't generally need to. That said django's migration system is very powerful and you can hand-write a migration if you need to.

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

I mean you can using proxy models but that's not really a thing with django. Models are for developers and generally developers have all the permissions any way, so the solution to making a model read only is to just not write to it. If you want to present a read-only model to an end user you can reference it in a view of make a read-only serializer with django-rest-framework. It's python, not java, there's no such thing as private/protected members just convention to put an "_" in front of things other developers probably shouldn't be messing around with.

Re: Elixir for Humans Who Know Python

#65

Post by fdeage » Sat, Feb 25, 2023, 2:31 PM UTC

josevalim wrote: post #27

spapas82 wrote: post #17

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…

With Phoenix 1.7 being released, will there be a new edition of "Programming Phoenix"? The latest one covers Phoenix 1.4, which is already slightly outdated. I think having an up-to-date book would be of great value for Phoenix beginners :)

Re: Elixir for Humans Who Know Python

#66

Post by josevalim » Sat, Feb 25, 2023, 2:32 PM UTC

spapas82 wrote: post #60

josevalim wrote: post #27

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…

> instead of simply being able to change the code, you need to find the exact hook or configuration to get the behavior you want. I don't think that this is a bad thing. This is the purpose of a framework. To extend its functionality. If I wanted to re-write everything (or change the generated scaffolds) then I'd skip the framework and use libraries directly. I'd like to point out the biggest problem with scaffolding…

If you need to change it, you would add it to the migration, schema, and then in the necessary templates. Some fields are private, read-only, etc. so you would change your templates accordingly. Some fields you want to change via a button press, others via a form, and so on. The whole point is that you can evolve the generated structure based on your needs.

> (i.e you can use views if you want and think you need them)

I was mostly speaking about existing applications. New applications have a clear path forward.

I don’t think this strengthens your argument the way you think. I _bet_ Django also has features that were used in the past and are no longer favored now, but still supported for backwards compatibility. This is in no way a phenomenon exclusive to Phoenix.

Re: Elixir for Humans Who Know Python

#67

Post by 8s2ngy » Sat, Feb 25, 2023, 2:35 PM UTC

fud101 wrote: post #56

I'm trying to decide between taking a Django job and an Elixir one. Can't decide between old and proven and new and early adopter. Any advice?

I am in a similar situation as well. The company at which I am working as a trainee engineer has a small team dedicated to Elixir and Phoenix. I have a choice between Ruby with Rails and Elixir with Phoenix after I am done with my training. Elixir intrigues me because it is so different from the programming I learned at college, but I am also anxious about shoehorning my initial work experience into a niche technology that might be difficult to find a job in, a few years down the line.

Re: Elixir for Humans Who Know Python

#68

Post by ralmidani » Sat, Feb 25, 2023, 2:50 PM UTC

dudul wrote: post #47

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?

I’ve never used Ecto outside of a Phoenix app, so yes, in my mind the line between them was blurry. Thanks for pointing out my mistake!

A very recent real-world challenge I ran into was having to coordinate updates and diffs to all the files involved and keeping them in sync while doing local development (before deployment but also while working on fixing a very subtle bug). Every time I changed the migration file (even to add an index), I had to remember to checkout the previous version of “structure.sql” or the migration wouldn’t be run, even during a complete DB reset (structure.sql is used to know which migrations have been run and synced with the SQL dump). Also, the schema in Ecto does not have a complete validation API, so you’ll need to do those in “changeset” functions. Overall I like Ecto, and part of me regrets letting myself get spoiled by Django’s model layer and DB tools.

Re: Elixir for Humans Who Know Python

#69

Post by fud101 » Sat, Feb 25, 2023, 2:52 PM UTC

8s2ngy wrote: post #67

fud101 wrote: post #56

I'm trying to decide between taking a Django job and an Elixir one. Can't decide between old and proven and new and early adopter. Any advice?

I am in a similar situation as well. The company at which I am working as a trainee engineer has a small team dedicated to Elixir and Phoenix. I have a choice between Ruby with Rails and Elixir with Phoenix after I am done with my training. Elixir intrigues me because it is so different from the programming I learned at college, but I am also anxious about shoehorning my initial work experience into a niche technolog…

Yeah, it's a big trade off careerwise, i'd have to go with Django also. I have the lisp disease of wanting a magic bullet when none exists.

Re: Elixir for Humans Who Know Python

#70

Post by josevalim » Sat, Feb 25, 2023, 3:03 PM UTC

traverseda wrote: post #64

josevalim wrote: post #45

Earlier quoted context omitted.

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…

>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? Django models are normal python classes. Depends on exactly the logic you're dealing with, but generally you can make logic be a method on that class. Try to avoid logic that spans multiple tables in general, and if you have logic that does span multipl…

Thanks for the insights, I appreciate it! I will take some time to go through the docs and learn more. One last question for now (I hope): after the migrations are auto-generated, do you check them into version control?

> Models are for developers and generally developers have all the permissions any way

To clarify, the reason why you would want to have read-only models is rather in complex data model cases or for performance reasons. For example, if you have a large model with 50 fields, defining a subset with 10 fields can be beneficial to performance in several queries. Other than that, I agree with you.