On to Elixir(thraxil.org) |
On to Elixir(thraxil.org) |
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!
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"
There's so much progress happening in existing Python-powered ML community that, unless there are very good interop tools and protocols (e.g. ONNX and the like), then even if you gain productivity gains w/your local team by moving to Elixir, you risk losing your ability to draft off that larger community's progress.
Very hard trade-off unless you're sufficiently funded to invest in the gaps.
I think it maybe a reaction to there being too much magic in Rails dependencies, but it makes upgrades much harder.
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.
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.
Otherwise, great article about Phoenix!
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...
ecto.gen.migration!
I also would probably include Django Admin in the "app ecosystem" stuff that I do call out. I think if Phoenix had a similar ecosystem, there could easily be something like Django Admin that you could just drop into a project.
The tool Andy uses is called kaffy https://hexdocs.pm/kaffy/0.5.0/readme.html
Something like the Django admin in phoenix would be like taking the actual USP of Django away … and it could even be real-time and collaborative by default :-)
It's all about great abstractions. Django never extracted the table/filter stuff from the admin into a usable stand alone component, and it really shows.
Django admin is stagnant mostly because of lack of uptake in support from companies. Everyone makes their own admin solution rather than collaborating.
On the other side, `mix ecto.migrate` essentially works the same as `manage.py migrate` for bringing your database in line with the set of migrations in your code.
Ash framework [0] does have this feature, though.
Django migrations have been doing this for a long time...
> Your models will be scanned and compared to the versions currently contained in your migration files, and then a new set of migrations will be written out. Make sure to read the output to see what makemigrations thinks you have changed - it’s not perfect, and for complex changes it might not be detecting what you expect.
So it's not different other than it can scan the changes in models to help create the migration which is a nice little convenience.
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.
It's more about the speed of development. I sometimes make many migrations per day. It's just so fast I don't really think about changing models at all.
It's okay if it doesn't solve a problem you have.
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.