1. 12
  1. 5

    i keep wrestling with phoenix and getting frustrated, in large part because a lot of the expected newbie workflow is based around one-time code generation, which makes it really inflexible in terms of iterating on early decisions. of course part of it could be that web programming is inherently a mess, but i would love to see a framework with a clean separation of generated code and user-modified code, so that the generated bit could be regenerated.

    1. 4

      Yeah, I love working in Elixir, but I never use Phoenix because it feels incredibly overwhelming - just using Plug with EEx in the raw is more comfortable, but I suspect I’m missing out on a lot.

      1. 2

        I hear you. What I ended up doing was create an example “library” of different cases of generated code.

        It helped a lot with learning and also allows me to refactor along the way.

        The other thing I do is that whenever I run a mix generation task, the output of that is always a single git commit, and the git message includes all the stdoutput from the gen task itself. the next commit then is any manual changes I make.

        This doesn’t change your original complaint, but after a while, it certainly becomes less of an issue. I usually use gen tasks to just create a base template for me these days, then heavily modify after the fact.

      2. 3

        Part 1 is OK-ish, it’s a quick tour of Elixir. Part 2 talks about Phoenix and LiveView, but doesn’t really explain the quirks. I discovered Hotwire (https://hotwire.dev/), presented as a language-agnostic LiveView equivalent. Exciting!

        However one remark:

        You essentially avoid the entire javascript ecosystem.

        that’s false for me, even if you don’t write JS, because it requires nodejs libraries.

        1. 2

          yeah that could be worded better. there is a web pack dependency with LiveView and phoenix. What you avoid is having to write any javascript.

        2. 2

          I’m reading the deployment story: https://amattn.com/p/deploying_elixir_phoenix_webapps_to_the_cloud_with_releases.html

          So there is no “ready-to-use executable”? How can one ship a software to another person? Thanks.

          ps: @amattn You mentioned Lisp once. Are you able to compare SBCL’s compile-time type inference (which I enjoy a lot) we get during development with Elixir’s? thanks.

          1. 3

            Elixir is built on Erlang and hasn’t historically been in a space where deployment is via executable. Primary use cases are servers, embedded devices, network hardware etc. Shipping binaries is a different use case. Check out Bakeware which is doing some work in this area.

            1. 2

              Think of it like Java, you need the JVM installed on the system, then you deploy a .war file.

              It’s kinda like that.

              A mix release is basically the Erlang VM (BEAM) and your applications code and resources (css, images, js files, dependent libs, etc) all in one big directory.

              so you just copy or rsync that directory to your cloud instances. alternatively, you can build a docker image and deploy that image.

              1. 1

                I’m not super familiar with SBCL’s implementation of type inference, but with respect to compile time type inference in general, elixir doesn’t have a direct equivalent across the board of all variables and all types. (like say Go does it)

                What you normally do is make heavy use of pattern matching, guards, and what not, to get some safegaurds that get you really close to that kind of safety tho.

                The Dialyzer (static analysis tool) can tell you if a set of pattern matching or guards will never work or clearly have errors. It’s pretty effective and similar to compile-time type inference, helps push errors earlier in the dev process.