[HN Gopher] Elixir and Phoenix can do it all
       ___________________________________________________________________
        
       Elixir and Phoenix can do it all
        
       Author : mike1o1
       Score  : 110 points
       Date   : 2023-10-28 19:57 UTC (3 hours ago)
        
 (HTM) web link (fly.io)
 (TXT) w3m dump (fly.io)
        
       | yewenjie wrote:
       | Love Elixir and Phoenix, but the last time I checked (granted,
       | two years ago), the major lack was learning material for people
       | who weren't coming from Ruby experience.
        
         | lawik wrote:
         | I have found learning materials to be plentiful. I came from
         | Python which I guess looks sikilar enough to Ruby. But of
         | course what paths you hit can vary wildly.
        
         | givemeethekeys wrote:
         | The Elixir and Phoenix books by Pragmatic Programmers are very
         | good. Beyond that, a little bit of practice and getting used to
         | the docs is all I've needed (so far).
        
         | mattferderer wrote:
         | It's been well over 2 years since I tried it out & I thought
         | the Elixir docs were really awesome when I did it. They had
         | great walk throughs to getting started.
         | 
         | I also did Rob Conery's Elixir tutorial which was fun -
         | https://robconery.com/course/take-off-with-elixir/#/ Absolutely
         | loved the way he did this one as a story but it also didn't
         | feel like I was sitting there forever waiting for him to get to
         | the lesson either. Looks like it's out dated though.
        
       | crummy wrote:
       | I hear so much good stuff about Elixir and Phoenix (often from
       | fly.io blogs) but I've always dismissed it for the lack of type
       | support. Is there a TypeScript equivalent on the horizon? Or is
       | it not so much of an issue?
        
         | winter_blue wrote:
         | I second this question. Static typing is super critical for
         | large projects.
        
           | lawik wrote:
           | I hear this a lot. I get that it is helpful. But I know
           | people run large projects without it in Elixir and seem to do
           | fine. Discord and remote.com seem likely to be fairly
           | massive. Last I spoke to Remote they did 70 releases a day
           | and no type static typing.
           | 
           | I know from Elm that it does change how things feel. I could
           | see an upside. But coming from a dynamic life I can't quite
           | grok considering it a requirement.
        
             | sodapopcan wrote:
             | Not to mention the AXD301 :)
        
             | gloryjulio wrote:
             | > fairly massive
             | 
             | It really depends on your definition of your massive.
             | Discord seems to have a few hundreds to a thousand
             | employees in total. I am from a typical tech company. So I
             | could estimate that their total engineers count is probably
             | just a couple of hundreds, which is about our
             | director/senior director's team size.
             | 
             | In our definition of massive, we could have even hundreds
             | of ppl to touch the same portion of the code base
             | frequently. We regularly have to deal with code which are
             | about 10 years old and it's a moving target. You have to
             | deliver quickly with migration requirement in mind. Also we
             | frequently collaborate with the other teams and you have to
             | be able to understand others' code quickly.
             | 
             | Typing is critical as you don't have time to deal with the
             | constant stream of the new projects to dig deeper in to the
             | objects. And you really want to have some understanding of
             | the code in the first glance. We also want to offload lots
             | of the things to compiler and ide as much as possible.
             | 
             | It doesn't have to be full on static typing like Java, type
             | annotation in python/ruby already helped a lot
        
         | cschmatzler wrote:
         | Elixir will get type support, it left the research stage and is
         | now in development.
        
           | sodapopcan wrote:
           | It _might_ get type support. They have been very upfront that
           | they might fail and will only proceed with it if they can
           | come up with something that is right for the language. It 's
           | not a rush to get a type system just to attract more users.
           | I'm very optimistic they'll succeed, though! :)
        
         | mrmincent wrote:
         | It's underway - https://elixir-lang.org/blog/2023/09/20/strong-
         | arrows-gradua...
        
           | chromatin wrote:
           | GREAT NEWS! This is what has kept me away from Elixir, but no
           | such great web framework yet exists for e.g. Rust
        
           | Yoric wrote:
           | Eh. I designed some kind of static type system for Erlang ~20
           | years ago. It wasn't very good and I changed job before I
           | could test it on anything serious, but it was fun!
           | 
           | Glad to see that some people are doing a more serious job
           | than me :)
           | 
           | (also, it's a small world - I know Giuseppe Castagna, wasn't
           | aware that he was working on typing Elixir)
        
         | shijie wrote:
         | The language is still strongly typed, and with the language
         | being purely functional, I found myself not missing static
         | typing nearly as much as I thought I would. Things just work,
         | and they break during compilation if they don't.
         | 
         | I will say that editor support for static languages is
         | categorically better due to the language server being able to
         | more completely reason about the state of your code. That's the
         | one drawback.
        
           | loloquwowndueo wrote:
           | Elixir is not strongly typed. You can bind any data type to a
           | variable at any time.
        
             | pitkali wrote:
             | Elixir doesn't technically have variables. Those are
             | bindings: you give names to values. Variable would be more
             | like a box storing a value.
        
             | impulser_ wrote:
             | This is not true.
             | 
             | For example doing "1" + 2 would give you an error.
        
               | sodapopcan wrote:
               | You also can't do "foo" + "bar" to get "foobar", you have
               | to do "foo" <> "bar" giving it even more type "strength"
               | than many strongly typed dynamic languages have.
        
             | status_quo69 wrote:
             | Elixir is strongly typed, elixir is not statically typed
        
             | heisenzombie wrote:
             | Parent is making a distinction between "strongly" and
             | "statically" typed. By some definitions. Type conversions
             | in Elixir are generally explicit (contrast with JavaScript)
             | and the type of a variable matters at runtime (e.g think
             | about pattern matching), and so some people would call it
             | "dynamic and strongly typed".
        
             | shijie wrote:
             | This is untrue.
             | 
             | https://thinkingelixir.com/elixir-in-the-type-system-
             | quadran....
        
             | arrowsmith wrote:
             | You're thinking of _statically_ typed, which Elixir isn 't.
             | Elixir _is_ strongly typed, which means something
             | different.
        
         | satvikpendem wrote:
         | The Gleam language is the alternative, it also runs on BEAM.
         | It's also supported by Fly.io as is this article. It was also
         | recently discussed [1].
         | 
         | [0] https://gleam.run/
         | 
         | [1] https://news.ycombinator.com/item?id=38031342
        
         | impulser_ wrote:
         | It not as big of an issue as people make it out to be. Maybe it
         | becomes they haven't used a functional programming language. I
         | have yet to have a problem with Elixir where static typing
         | would be the only thing that would solve the problem.
         | 
         | Elixir has great support for pattern matching, guards,
         | documentation, testing and being a functional language all help
         | negate the problems of a dynamic language.
        
         | thibaut_barrere wrote:
         | I've done both strongly typed & "less typed" languages over the
         | last couple of decades, and I do not find the current situation
         | a problem in Elixir. We're using Dialyzer on my main project,
         | without too much interest I must say. I am following the
         | discussions on that topic (improving types in Elixir) with
         | interest, but it's not an issue for me at the moment (and large
         | refactorings occur without much troubles either).
         | 
         | I think the fact that most functions are "pure" / "static" is
         | really helping with refactorings.
        
         | tryptophan wrote:
         | Elixir has features called guards which allow you to check for
         | a condition to be true before a function is called(and will
         | match another version of the same function if it is false).
         | This is used as a crude form of type checking.
        
       | shijie wrote:
       | We're experiencing this at my place of work. Our backend stack is
       | Python, and coming from an Elixir/Phoenix background, adding a
       | durable queue to our infrastructure _should_ be trivial but
       | because of the nature of Python, it is all but impossible to run
       | the queue in the same codebase and application server.
       | 
       | Elixir and the BEAM make it so easy and pleasant to run extremely
       | complicated infrastructure in the same codebase and in the same
       | application context. Hard problems made easy.
       | 
       | I miss it.
        
         | lionkor wrote:
         | FYI "all but impossible" usually means the opposite of what you
         | think it means - "all but" meaning "everything except". Seen
         | this usage a lot and it bothers me, because both usages are
         | common and theyre the exact opposites.
         | 
         | If I didn't have context clues, it'd be difficult to know which
         | one you mean.
         | 
         | Edit: not native but I've always understood it as the first def
         | here https://idioms.thefreedictionary.com/all+but
        
           | pakitan wrote:
           | It's an idiom and means "nearly impossible". There is no
           | other usage.
        
           | shijie wrote:
           | In this context I meant "all but" == "everything except" i.e
           | it is almost impossible. Are you saying it means the opposite
           | of how I used it? I'm not certain what you mean.
        
           | yodon wrote:
           | 100% of the usage I've encountered as a native speaker is
           | "all but impossible" = "almost impossible".
           | 
           | This stems from "all but" = "almost"[0]
           | 
           | [0]https://www.merriam-webster.com/dictionary/all%20but
        
           | TJSomething wrote:
           | I'm not sure how it makes sense to claim that an action is
           | "everything except impossible." This is more in the classic
           | sense of "the battle was all but lost" for a battle was
           | practically but not actually lost. You could implement a
           | queue in a Python server, but it would be technically awful
           | to do.
        
           | andyferris wrote:
           | "All but" = "almost" (which presumably historically was "all
           | most").
           | 
           | Like "all but dead". Everything except dead, as in as close
           | to death as possible without actually being dead (and
           | certainly not the opposite of dead, as in perfect health).
        
         | catlover76 wrote:
         | > it is all but impossible to run the queue in the same
         | codebase and application server.
         | 
         | I am surprised, both in terms of the difficulty you faced that
         | you would want to; I have beef with the fact that using Celery
         | with Django runs "worker" process on the application server by
         | default.
        
         | Yoric wrote:
         | Every time I see microservices, or Kafka, or Redis, ... I can't
         | help being disappointed because we seem to be stuck reinventing
         | BEAM/Erlang (and Elixir) 30 years after the fact, except with
         | technologies that are slower, more fragile, more complicated to
         | use and harder to deploy.
         | 
         | :sigh:
        
           | rdtsc wrote:
           | Someone in the Erlang community named our processes
           | "nanoservices" as a joke. I thought that was pretty apt
           | though, a gen_server is pretty close. And you can have 3M of
           | those on one node!
        
         | thibaut_barrere wrote:
         | Something I often "draw" to other developers when showing
         | Elixir is the difference in terms of "boundaries".
         | 
         | It is common to have:
         | 
         | frontend <-JSON-> backend <-db/queue-> background jobs
         | 
         | Each boundary introduces complexity (marshalling / impedance
         | mismatch / but also different HR/recruiting needs).
         | 
         | In Elixir you can more or less do:
         | 
         | front/back/background
         | 
         | with no boundaries or reduced boundaries (e.g. using LiveView &
         | OBAN in the same process, even if going through Postgres as a
         | queue).
         | 
         | Someone coined the term "deepstack engineer" as well recently I
         | think, which I could draw as:
         | 
         | frontend <-> backend <-> background <-> machine learning
         | 
         | Now with Elixir you can do everything in the same process (but
         | with isolation as required):
         | 
         | front/back/background/ml
         | 
         | And this is something I find really interesting about this
         | stack.
        
       | cschmatzler wrote:
       | This post is missing one _huge_ point: its tooling is bad. Like,
       | real bad. The language server will regularly crash, does not
       | support code actions _at all_, messes up formatting regularly by
       | ignoring the configuration. Then credo, the popular linter, will
       | tell you that your imports are not alphabetically ordered but
       | there's no fix mode, meaning you'll go back to order them
       | yourself. I love the language, am using it during my day job
       | right now, and have published multiple libraries, but the
       | development experience can be infuriating.
        
         | michalg wrote:
         | Regarding credo - try https://github.com/adobe/elixir-styler
        
         | loloquwowndueo wrote:
         | Works fine for me under vim with elixir_ls and mix format.
        
         | aeturnum wrote:
         | I also develop Elixir professionally and I find the tooling to
         | be excellent. I've seen some transient language server
         | crashes[1] - but I wouldn't call it common? I personally
         | dislike Credo, but it's very customizable, and you can simply
         | remove the "alias order" readability check[2].
         | 
         | [1] https://elixirforum.com/t/elixir-ls-error-
         | undefinedfunctione...
         | 
         | [2]
         | https://hexdocs.pm/credo/Credo.Check.Readability.AliasOrder....
        
         | sbrother wrote:
         | I find the tooling excellent. `mix` just works, and `alchemist`
         | mode in emacs provides everything I could imagine needing. I've
         | never heard of credo, but adding a call to `elixir-format` on
         | save solves any linting needs I've had.
        
       | SteveMorin wrote:
       | Elixir/Erlang is great and excited for types. A project that
       | would help webassembly run natively on the beam with an actor
       | model interface.
       | 
       | Have a proposal here:
       | https://docs.google.com/document/d/1adXQGiDoqyJ37r8XWYthFFZf...
        
       | mrdoops wrote:
       | This is a great resource to map "what library/thing should I use
       | for x situation" which can sometimes be daunting to someone new
       | to an ecosystem.
       | 
       | The "niche" label cast at Elixir and its ecosystem hasn't been
       | relevant for years; it can do what you need it to and with
       | massive reduction in complexity.
       | 
       | If or when you do need to write your own library: you'll find
       | that straightforward as well.
        
       | banashark wrote:
       | In a lot of these BEAM threads I see certain features listed as
       | "part of the benefits", but when I look to see who is using them
       | in production, most of the advice is "don't use that, use an
       | established service to do that".
       | 
       | This is usually things around either ETS/mnesia for state storage
       | or doing hot-releases, both of which I find most people in the
       | community recommend _against_.
       | 
       | A few examples:
       | 
       | - Server-wide state - Persistable data - Background Jobs
       | 
       | Having worked in a heavy Erlang codebase and enjoyed some of the
       | features of it, but realized some of the shortcomings where when
       | reliability is a primary concern (medical/healthcare), a lot of
       | the advice changes.
       | 
       | Though I haven't written any F# in a while, I was always curious
       | to see how F# + https://learn.microsoft.com/en-
       | us/dotnet/orleans/overview (virtual actors) would feel
       | comparatively.
        
         | toast0 wrote:
         | I dunno, the blogging community of Erlangers seems to have a
         | different opinion of hot-loading and mnesia scalability than I
         | developed working at WhatsApp.
         | 
         | Specifically, hot loading allows for tremendous agility in
         | rolling out code: for better and worse. There's sharp edges,
         | but it's worth it IMHO (of course, it should be noted that
         | AFAIK, hot loading is either unused or very rarely used at
         | WhatsApp now. I believe they now use fairly conventional
         | rollouts where new instances are started with the new code,
         | load balancers shift the load and old instances are shut down
         | eventually... back in my day, we didn't have load balancers or
         | easy access to spare machines to rotate through, etc)
         | 
         | Mnesia has lots of sharp edges too, but if you are willing to
         | learn them as you grow, and maybe do a bit of work here and
         | there, disc_copies and ram_copies tables scale pretty good
         | (afaik, we only used disc_only_copies for the schema table, and
         | that's a small table, so it works; I don't think that table
         | type works well with large tables). And having data and
         | application colocated makes a lot of things pretty nice. IMHO,
         | if you are doing the volume of data and accesses we were doing
         | with any other database, you'd need in house engineering on the
         | database as well, so I don't see it as a strong negative that
         | it's needed for mnesia. If you have a smaller need, maybe it
         | works out of the box. IMHO, mnesia works best with stable nodes
         | and stable network though: the original use case was for two
         | nodes in the same chassis, and the farther you stray from that,
         | the more work you may have to do. But we had replication setup
         | between Reston, VA and Dallas, TX and it worked fine as long as
         | the backbone between the two wasn't being extra flakey.
         | 
         | Again, I think post-acquisition, mnesia was phased out, but FB
         | doesn't value stability of nodes or networks.
        
           | davidw wrote:
           | Are they still using Erlang at Whatsapp?
        
       ___________________________________________________________________
       (page generated 2023-10-28 23:01 UTC)