Live data from Hacker News

Elixir for Humans Who Know Python

hibox.live

71–80 of 198 posts

Re: Elixir for Humans Who Know Python

#71

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…

> “On the other hand, I agree with you that everything that Phoenix generates through its phx.gen generators are for demo purposes and will get thrown away eventually.” The parent didn’t say that and it’s not true in my experience writing Phoenix apps over the past six years. I usually add to the generated contexts, controllers or now live views, but I often leave the migrations as is. Even when making a migration to…

My experience as well. The generated code is absolutely kept and used (excepting the template, but even that serves as a nice example to follow for people who are newer). Mainly the only changes are to add validation code and some business logic here or there depending on how complex the behavior needs to be (again mainly validation). The generated code is a big help, and we still use it for every new model despite being able to easily add new stuff manually.

Re: Elixir for Humans Who Know Python

#72

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…

Hi José, thanks for joining the discussion!

The sibling to this post (by “traverseda”) is more informed and informative than I could hope to write. I will add that Django has Manager classes that have default behavior included for interacting with the query API, and they can be customized to your needs. You can even have multiple managers for a given model.

https://docs.djangoproject.com/en/4.1/topics/db/managers/

It’s been a few years since I used Django, but I remember its model layer fondly, and still follow the framework’s release processes.

One of the areas where Django lags is being fully async (Python imposed a lot of limitations on async operations for most of its life). The upcoming 4.2 release of Django is laying the groundwork for async DB operations.

Re: Elixir for Humans Who Know Python

#73
post #47

Earlier quoted context omitted.

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

It is totally fine to get spoiled if you consider it is better :D

Your case about structure.sql is interesting. It would be nice if we could automate it somehow but, if we simply tried to re-run a changed migration, then the migration would likely fail because the other operations in it (such as adding fields), you already exist, no?

Do you have any suggestions/ideas on how to tackle this? We could have a "mix ecto.migration.fix" that reverts the last migration, wait until you close/save the file, and migrate again, but I am not sure how useful it would be. How would Django approach this? If you auto-migrate and then do further changes, does it change the existing migration or does it generate new ones?

PS: the changeset functions are pretty much on purpose though. It is important to decouple the validation from the schema because a single schema can have several validations rules (and they can diverge overtime!).

Re: Elixir for Humans Who Know Python

#74
post #43

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

Ah sorry, I should have clarified in my original message. The page I linked to is our public marketing site, which is a static site built with Next. The Phoenix application is the product that the site is talking about (Duffel Links).

Re: Elixir for Humans Who Know Python

#75

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…

> I use Phoenix only on projects where its real-time capabilities will be the protagonist Yep, that feels sound advice (and motivation). I would add more broadly "federation capability" (in the style of the fediverse / activitypub but also wherever that decentralization path might take us in the near future) as an important dimension to look into. Remains to be seen if the "telecoms/erlang" pedigree of elixir is a cr…

It is only sound advice if you already know Python/Django really well and don't mind context-switching your language. If you know Elixir/Phoenix well, you can easily crank out simple sites that don't use any real-time stuff as well as any other framework, and you get the added benefit of blazing fast (pre-compiled) templates and a highly robust database connection pool. Personally I prefer to keep as much as possible in the same language/ecosystem rather than having to straddle.

Re: Elixir for Humans Who Know Python

#76

Earlier quoted context omitted.

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

Yep, you do check the migrations into version control.

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

Nope, the django ORM has several helpers here. What you do in the most basic case is do something like

    MyTable.objects.filter(key__gte=12).only("field1","field2","field3")
Which will (during the initial request) only fetch the specified fields from the DB. There's an equivalent (defer) for telling it not to fetch those fields during the first query.

Of course is someone than tries to access "field4" in a template/view django will make an additional query to get that extra data.

It's a bit more complicated to make a nice chainable filter so you can call `MyTable.objects.only_foo_rows()`, you'd need to define a method on a custom object "manager", but that still wouldn't generally be handled at the model level.

There's also things like select_related, prefetch_related, and other tools to make the ORM layer more performant. Of course for really exotic things like tree-based data structures you can also perform raw SQL queries on an ORM object with `MyTable.object.raw("SQL goes here")` and have it still return ORM objects. Please don't do that though.

For a long time I didn't realize why people were so down on ORMs until I tried using a non-django ORM, it really does set the bar.

Re: Elixir for Humans Who Know Python

#77
I love functional programming because it feels natural to me to have functions that always return a value (method chaining or postfix notation FTW!) do not mutate data (and therefore avoid side effects), and use clear naming conventions for any potentially destructive functions. However, Python's popularity, vast library, and strong community make it a more practical choice for solving problems - at least when programming is not my primary focus but rather a means to an end.

While I find Clojure, Elixir, and F# attractive, it doesn't make sense to use them for anything more than experimenting or playing around, given the resources available in Python.

Re: Elixir for Humans Who Know Python

#78

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

> LiveView can’t handle spotty connections, I thought?

LiveView handles it just fine. If the websocket disconnects for some reason it will automatically re-establish itself when the connection is restored.

You can also use the built-in JS module to do client-side things when you don't need backend support. I use Alpine.js (PETAL stack) and I like it a lot.

If you have a very complex client-side need, it's also pretty easy to use React.js for that.

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

You'll have to get more specific if you want an accurate answer. Does this MVP require a database? Does it require specific UI or can you just massage the OOtB UI that Phoenix gives you? You'd be surprised at how much of a headstart the generators can provide. I've built working protoypes (with database persistence) in 30 minutes. If it's purely a static page, I would just use nginx directly but you could easily do that in Phoenix as well in about the time it takes you to write the HTML since the default new project comes with a page controller already set up for that.

Re: Elixir for Humans Who Know Python

#79

Earlier quoted context omitted.

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

Yes. Migrations are checked into the source control. They're still the source of truth of the database changes.

Regarding read only models pointing to a tabel. It'd possible to use proxy models or even non managed models where with some mix of Managers it can provide what you're looking for.

For getting a subset of fields from a database tabel, Django provides ".only()" on the QuerySet which you can use to list all the fields explicitly and only them will be retrieved. It can even span to foreign field relations as well.

Diango ORM is indeed powerful and vrry flexible once you learn it. A novice developer can use it quickly and won't get in the way. An advanced developer can do very complex sfuff with it without touching any raw sql. Still, it's possible to write custom sql commands directly.

Re: Elixir for Humans Who Know Python

#80
post #77

I love functional programming because it feels natural to me to have functions that always return a value (method chaining or postfix notation FTW!) do not mutate data (and therefore avoid side effects), and use clear naming conventions for any potentially destructive functions. However, Python's popularity, vast library, and strong community make it a more practical choice for solving problems - at least when progra…

As a Python programmer, I truly believe Elixir/Phoenix is the best stack out there from a technical perspective.

However the incredible breadth of libs and resources ... and most importantly the mind share (both available devs, but more importantly available jobs for seniors who commit to Elixir) means that it is still just not a competitive choice.

Almost all commercial software dev is not about technical excellence, but rather about applying the available tech to a particular business domain. And there Python (and .Net, Java, PHP, Ruby ... even Go) are so far ahead that sadly Elixir doesn't look like it will make it.

Post reply on HN