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

101–110 of 198 posts

Re: Elixir for Humans Who Know Python

#101

Post by traverseda »

Alir3z4 wrote: post #82
traverseda wrote: post #76

Earlier quoted context omitted.

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

> 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. This. Very much this. I have given up on one finding such. The closest and nicest one that comes to mind is SQLAlchemy. The rest of languages or frameworks have indeed nothing compared to Django ORM and SQLAlchemy. It's not even fair to compare them.

Peewee ORM can also be nice if you need support for more esoteric DB features (sqlite user-defined table functions?). No migrations though.

Re: Elixir for Humans Who Know Python

#102

Post by fdeage »

scwoodal wrote: post #100
fdeage wrote: post #65

Earlier quoted context omitted.

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

I don’t think 1.7 is officially out yet as it’s sitting at rc-3.

It's been released yesterday :) https://phoenixframework.org/blog/phoenix-1.7-final-released

Re: Elixir for Humans Who Know Python

#103

Post by otreblatercero »

Spivak wrote: post #90

Assuming the author is in the comments, the paragraph about data immutability is wrong. Integers are immutable in Python, when you created the lambda the name x is in its closure. When you assign to it it changes where the name is pointing to. Elixir does something wild and completely different. When you assign x that second time at that moment is creates a new variable behind the scenes and you transparently start u…

Thanks for pointing that out, I knew it was a closure because of the Elixir in Action book, and the example's explanation threw me off balance.

Re: Elixir for Humans Who Know Python

#104

Post by Scubabear68 »

I haven’t gotten through the whole article yet, and haven’t encountered Elixir before, but I really like the popes ideas. I am going to dig into that a little more. Are there other languages that have similar constructs (outside of shells!)?

Re: Elixir for Humans Who Know Python

#105

Post by conradfr »

fdeage wrote: post #102
scwoodal wrote: post #100

Earlier quoted context omitted.

I don’t think 1.7 is officially out yet as it’s sitting at rc-3.

It's been released yesterday :) https://phoenixframework.org/blog/phoenix-1.7-final-released

Nice.

It didn't seem to have really made the frontpage of HN despite a lot of votes.

Re: Elixir for Humans Who Know Python

#106

Post by winrid »

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…

The Phoenix docs don't look like they even hold a candle to Django. I spent 5mins in it and still don't know how to define a model. I eventually figured out a doc section called "Ecto" - so i had to know what ecto was to find it. Then, in those docs I still don't know how to define models. Do they expect me to manage my database and schemas separately and generate the models from that?

That's completely opposite what Django does, and that's partly why Django is so productive.

I don't think Pheonix and Django are competitors. They are too different.

Re: Elixir for Humans Who Know Python

#107

Post by bullfightonmars »

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.

More orgs should hire experienced engineers and train them on the job.

Re: Elixir for Humans Who Know Python

#108

Post by xutopia »

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?

Elixir will present you new concepts that you will be unfamiliar with and the development experience is actually really fun! For becoming a better programmer long term I would go for an Elixir experience early on.

Re: Elixir for Humans Who Know Python

#109

Post by josevalim »

traverseda wrote: post #99
josevalim wrote: post #84

Earlier quoted context omitted.

Ack on migrations, tks! --- For completeness, you can do the same in Ecto: from t in MyTable, where: t.key >= 12, select: ["field1", "field2", "field3"] However, that will still allocate a "MyTable" struct in Ecto. And if that struct is large (say 50 fields), slots for it are allocated (but none of the actual data on the fields). I am not familiar with Python Object Model enough but, if your Python example still allo…

>I am not familiar with Python Object Model enough but, if your Python example still allocates an object with slots for all 47 other fields besides the three selected, then you may still find yourself under circumstances you would rather have a "slim" version of the model and reduce memory allocation. Honestly at that point probably don't be using python. ORM objects don't use slots, they use a hashmap to look up eve…

That’s great, thanks for taking the time! Appreciated.

Re: Elixir for Humans Who Know Python

#110

Post by Xzya »

josevalim wrote: post #84
traverseda wrote: post #76

Earlier quoted context omitted.

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

Ack on migrations, tks! --- For completeness, you can do the same in Ecto: from t in MyTable, where: t.key >= 12, select: ["field1", "field2", "field3"] However, that will still allocate a "MyTable" struct in Ecto. And if that struct is large (say 50 fields), slots for it are allocated (but none of the actual data on the fields). I am not familiar with Python Object Model enough but, if your Python example still allo…

> I am not familiar with Python Object Model enough but, if your Python example still allocates an object with slots for all 47 other fields besides the three selected, then you may still find yourself under circumstances you would rather have a "slim" version of the model and reduce memory allocation. This may be needed when you need to load dozens of thousands of entries into memory for processing or similar.

Alternatively you can also tell the ORM to return a dictionary rather than a model instance: https://docs.djangoproject.com/en/4.1/ref/models/querysets/#...

For example, you may get a list of dictionaries with only "field1", "field2" and "field3" from a model like this:

  SomeModel.objects.filter(...).values("field1", "field2", "field3")

  [{"field1": "foo", "field2": "bar", "field3": "baz"}]
Post reply on HN