On to Elixir

76 points by ahmaman 1 year ago | 39 comments
  • mgdev 1 year ago
    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!

    • thraxil 1 year ago
      > 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"

      • mgdev 1 year ago
        Totally. I support a team of 40+ and even I have a hard time proposing this. Very hard to go against the herd.

        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.

    • sethherr 1 year ago
      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.

      • mgdev 1 year ago
        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.

        • neillyons 1 year ago
          Jose has written about this before https://news.ycombinator.com/item?id=34935952
          • sethherr 1 year ago
            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.

          • devoutsalsa 1 year ago
            A lot of that code generation is to facilitate macros. Personally, I don’t like macros when a little extra code to make a function call would work just fine.
            • sodapopcan 1 year ago
              Might be misunderstanding code generation. This means literally writing code into your project via a script. It has nothing to do with macros.
          • sodapopcan 1 year ago
            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've over-written a massive chunk of a library anyway, upgrading is no easier.

            Otherwise, great article about Phoenix!

            • thraxil 1 year ago
              (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/
              • sodapopcan 1 year ago
                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

              • throwawaymaths 1 year ago
                You forgot

                ecto.gen.migration!

                • sodapopcan 1 year ago
                  You’re right! I still haven’t read up on how Django does it, but I’m assuming it must make a migration file? Obviously I shouldn’t assume but how else would you add things like indexes and whatnot?
                  • sodapopcan 1 year ago
                    All right, I've read! I'm sort of referencing two different threads I'm involved in here but from the Django docs:

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

              • aloukissas 1 year ago
                I’m surprised to see that the OP, as a Django user, does not call out the lack of an out of the box admin tool that’s not there in Phoenix. Django’s admin is amazing and super useful in production. I love phoenix but I miss an admin tool :(
                • thraxil 1 year ago
                  Author here. I do love me some Django admin, but I find that I tend to use it a lot early on in a project and then slowly move as much away from it as possible as we build up more specific admin/management-type functionality in the app itself.

                  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.

                • anonyfox 1 year ago
                  As a Phoenix user, I Call out!

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

                  • throwawaymaths 1 year ago
                    Not interactive, but I hear good things about kaffy
                  • boxed 1 year ago
                    The Django admin has unfortunately stayed stagnant for 15 years. We built a replacement admin in iommi first almost as a joke, but now it's a serious part of the framework. Our admin is 645 lines of code (54 of which are imports!) while djangos admin is 5307, and still our admin is way more customizable. Not only that, but you can easily reuse all those customizations if you want to lift stuff out of the admin to your own stand alone view, unlike with the Django admin.

                    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.

                    • true_religion 1 year ago
                      Could you consider releasing it into the open source?

                      Django admin is stagnant mostly because of lack of uptake in support from companies. Everyone makes their own admin solution rather than collaborating.

                  • cpursley 1 year ago
                    There's several plug-and-play admin tools for Phoenix.
                  • boxed 1 year ago
                    Last time I looked Ecto didn't have automatic migrations I think. Does it now? I can't imagine working without this feature after many years of Django...
                    • thraxil 1 year ago
                      It takes the more Rails-like approach where you run a mix command to generate a migration (and that potentially writes out an elixir module with the Ecto schema, eg, when defining a whole new table) rather than Django's approach of updating your `models.py` and then having `manage.py makemigrations` introspect the DB and generate the migration code from that. I do slightly prefer Django's approach, but it's an easy adjustment to make.

                      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.

                      • sodapopcan 1 year ago
                        I don't know why this is always talked about as if it's some killer feature. You still have to review the migration its generated, don't you? Don't get me wrong, it's a nice feature that I would use if were available, but certainly not even on a list of dealbreakers for me when evaluating a framework.

                        Ash framework [0] does have this feature, though.

                        [0] https://ash-hq.org/

                        • DangitBobby 1 year ago
                          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.
                          • sodapopcan 1 year ago
                            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.

                          • boxed 1 year ago
                            I haven't looked at an auto generated migration in years. So no.
                          • di4na 1 year ago
                            No and it is not on anyone roadmap. So far we have not had anyone that found a way to make it work well.
                            • boxed 1 year ago
                              You just need to cover the easy 80%, and nicely tell you to go to the documentation for the other cases.

                              Django migrations have been doing this for a long time...

                            • throwawaymaths 1 year ago
                              Ash has automatic migrations. They are great when they work. When they don't...
                              • zachdaniel 1 year ago
                                When they don't you just write them yourself. All we do is generate migration files to provide a good starting point. Its a convenience tool.