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

On to Elixir

thraxil.org

Post reply on HN
Print view View original

21–30 of 41 posts

Re: On to Elixir

#21

Post by DangitBobby »

sodapopcan wrote: post #20
DangitBobby wrote: post #18

Earlier quoted context omitted.

The people who talk about it consider it to be a killer feature. I certainly do. There's considerably less ass pain and fear involved in Django migrations.

As I said, I would use it if it existed. But I have never experienced anything close to fear when writing migrations, that sounds insanely hyperbolic. The most I've experience is very mild pain. There's also the thing that schemas are not 1-to-1 with tables in Ecto (I realize it's possible in ORMs too, but not as ergonomic). Sure, you don't have to do this, and many don't, but it's very useful.

The fear isn't when writing migrations, it's when executing them in production. And please don't lecture me on how you should always be confident that your migrations work as expected before they go out.

It's okay if it doesn't solve a problem you have.

Re: On to Elixir

#22

Post by thraxil »

DangitBobby wrote: post #21
sodapopcan wrote: post #20

Earlier quoted context omitted.

As I said, I would use it if it existed. But I have never experienced anything close to fear when writing migrations, that sounds insanely hyperbolic. The most I've experience is very mild pain. There's also the thing that schemas are not 1-to-1 with tables in Ecto (I realize it's possible in ORMs too, but not as ergonomic). Sure, you don't have to do this, and many don't, but it's very useful.

The fear isn't when writing migrations, it's when executing them in production. And please don't lecture me on how you should always be confident that your migrations work as expected before they go out. It's okay if it doesn't solve a problem you have.

Executing them in production by running `mix ecto.migrate` is essentially equivalent to running `manage.py migrate`. That part of the two approaches is really the same.

Re: On to Elixir

#23

Post by sodapopcan »

DangitBobby wrote: post #21
sodapopcan wrote: post #20

Earlier quoted context omitted.

As I said, I would use it if it existed. But I have never experienced anything close to fear when writing migrations, that sounds insanely hyperbolic. The most I've experience is very mild pain. There's also the thing that schemas are not 1-to-1 with tables in Ecto (I realize it's possible in ORMs too, but not as ergonomic). Sure, you don't have to do this, and many don't, but it's very useful.

The fear isn't when writing migrations, it's when executing them in production. And please don't lecture me on how you should always be confident that your migrations work as expected before they go out. It's okay if it doesn't solve a problem you have.

Dangit, Bobby, please don't assume I'm going to lecture you ;)

But I'm very curious how this solves that problem. I've only ever had problems with migrations when misusing them to do data migrations. And of course when renaming and deleting columns... does it somehow create a multi-step deploy plan in these scenarios!?? If it did that then I'd change my tune. I can do reading on my own, though.

> It's okay if it doesn't solve a problem you have.

Once again, I'm not, repeat NOT, saying it's a bad feature. I even said I'd use it sometimes if it were available. I'm saying it's unfortunate when I hear people writing off an entire framework because it doesn't have this.

Re: On to Elixir

#24

Post by thraxil »

sodapopcan wrote: post #14

The point about code generation into the project is unfair. The only library I'm aware of that does this is phx_gen_auth, everything I've used works exactly as described. phx_gen_auth takes this approach due to José's experience working on Devise for Rails, which mirror's mine as a user. I overrode almost everything in Devise, often in very messy ways. While the difficult-to-upgrade argument is a sound one, once you'…

(Author here). Yeah, it may be unfair. phx_gen_auth is definitely one of the main ones that I encountered and struggled with (compared to, eg, django-allauth or django-social-auth). Even just the basic approach to working with Phoenix seems to be much heavier on using code gen (`mix phx.gen.`, `mix phx.new.`, etc) than Django. Maybe that's my newness and the books and documentation I encountered, but it seems like a lot more of the code in a Phoenix project ends up being code that was originally generated compared to an equivalent Django project). Even from the very beginning, there's a lot of code generated when you do `mix phx.new`. Eg, this exists for a reason: https://www.phoenixdiff.org/

Re: On to Elixir

#25

Post by mgdev »

sethherr wrote: post #2

I agree with the code generation of libraries in Phoenix being a drawback. I think it maybe a reaction to there being too much magic in Rails dependencies, but it makes upgrades much harder.

I've found the code gen approach to be very positive. Most of the generated code is minimal app-specific modules that in turn `use` Phoenix modules. This gives you a handy place to insert your customization w/o having to resort to dynamic metaprogramming contortions the way you used to have to in Rails.

I also like the philosophy of magical experiences, without magical code. Everything is very traceable. And most of the time you don't even need to use the generators - just make your module, register in the right places, and you're done.

Re: On to Elixir

#26

Post by mgdev »

After 20 years trying All The Frameworks, Phoenix is the first that excites me in a long time. Both the community and the coding experience remind me of Rails's early days in 2004/2005.

Same for Elixir in general. Different philosophies, but same energy, some craftsmanship, some welcoming attitudes, same hubris about what can/can't be done by revisiting from first principles.

LiveView is quite elegant, and is something that could only exist with such elegance in a language/runtime/community that values and supports long-lived processes with functional semantics.

Broadway builds on the shoulders of giants to provide robust data ingestion and processing... as a library, rather than the cobbled-together set of independent systems that is usually needed to do this.

The architectural concepts underlying Livebook put it on a path to surpass Jupyter, if only we can get critical mass adoption.

The stuff emerging in the Elixir + ML space thanks to Nx and Axon gives me some hope that Elixir will find a place as an all-in-one home for all things ML. Livebook makes it easy do to incremental experimentation. Bumblebee makes it stupidly simple to use pretrained models.

It's all so magical.

What we need, though, is better marketing!

Re: On to Elixir

#27

Post by sodapopcan »

thraxil wrote: post #24
sodapopcan wrote: post #14

The point about code generation into the project is unfair. The only library I'm aware of that does this is phx_gen_auth, everything I've used works exactly as described. phx_gen_auth takes this approach due to José's experience working on Devise for Rails, which mirror's mine as a user. I overrode almost everything in Devise, often in very messy ways. While the difficult-to-upgrade argument is a sound one, once you'…

(Author here). Yeah, it may be unfair. phx_gen_auth is definitely one of the main ones that I encountered and struggled with (compared to, eg, django-allauth or django-social-auth). Even just the basic approach to working with Phoenix seems to be much heavier on using code gen (`mix phx.gen. `, `mix phx.new. `, etc) than Django. Maybe that's my newness and the books and documentation I encountered, but it seems like…

Ya, it's fair, it's a common complaint! Though the size of the generated files is nothing compared to Rails :D

You're right that phx_new does count too. It's a bit misunderstood that Phoenix is actually closer to a micro-framework like Flask than it is a full-fledged solution like Django or Rails. What takes it up to their level is `mix phx.new`, so your argument is more on point than I initially thought. The LiveView issue tracker even provides a single-file version of a Phoenix app to re-create your issue in [0]. As you can see, it's not as simple as something like Flask, but not as complex as the generator does.

Again, great article and happy to have you aboard ;)

Also, if you want an auth solution without code generation, there is Pow [1]

[0] https://github.com/wojtekmach/mix_install_examples/blob/main...

[1] https://github.com/pow-auth/pow

Re: On to Elixir

#28

Post by sethherr »

neillyons wrote: post #16
sethherr wrote: post #2

I agree with the code generation of libraries in Phoenix being a drawback. I think it maybe a reaction to there being too much magic in Rails dependencies, but it makes upgrades much harder.

Jose has written about this before https://news.ycombinator.com/item?id=34935952

After reading that, I understand exactly where he’s coming from - I too have overridden a bunch of Devise in a bunch of different ways in various projects.

But, unlike the rest of Elixir and Phoenix, this approach doesn’t feel like an elegant solution - it feels like a moderately ok trade off.

Re: On to Elixir

#29

Post by sodapopcan »

thraxil wrote: post #22
DangitBobby wrote: post #21

Earlier quoted context omitted.

The fear isn't when writing migrations, it's when executing them in production. And please don't lecture me on how you should always be confident that your migrations work as expected before they go out. It's okay if it doesn't solve a problem you have.

Executing them in production by running `mix ecto.migrate` is essentially equivalent to running `manage.py migrate`. That part of the two approaches is really the same.

Oh, ya, if DangitBobby is thinking there are no auto-mated migrations in production then we're talking about two different things. I just meant the ability to infer migrations from models.

Re: On to Elixir

#30

Post by thraxil »

mgdev wrote: post #26

After 20 years trying All The Frameworks, Phoenix is the first that excites me in a long time. Both the community and the coding experience remind me of Rails's early days in 2004/2005. Same for Elixir in general. Different philosophies, but same energy, some craftsmanship, some welcoming attitudes, same hubris about what can/can't be done by revisiting from first principles. LiveView is quite elegant, and is somethi…

> The architectural concepts underlying Livebook put it on a path to surpass Jupyter, if only we can get critical mass adoption. > > The stuff emerging in the Elixir + ML space thanks to Nx and Axon gives me some hope that Elixir will find a place as an all-in-one home for all things ML. Livebook makes it easy do to incremental experimentation. Bumblebee makes it stupidly simple to use pretrained models.

Totally. My current employer does a bunch of data science and ML stuff and I'm hoping those give us a path off Python. Right now, it's hard for me as a non-data science, non-ML person to just be like, "here, use this Elixir thing instead of $tool_theyve_been_using_daily_for_10_years, I swear it's probably better or at least will be eventually"

Post reply on HN