[HN Gopher] Unpacking Elixir: Resilience
___________________________________________________________________
Unpacking Elixir: Resilience
Author : lawik
Score : 73 points
Date : 2023-09-24 19:48 UTC (3 hours ago)
(HTM) web link (underjord.io)
(TXT) w3m dump (underjord.io)
| sriram_sun wrote:
| Nice article! FTA: "One for one indicates that if a child crashes
| it, it and only it should be considered when restarting." What is
| "it" in this context?
| actionfromafar wrote:
| The should be a first comma after "crashes" IMHO.
| amilner42 wrote:
| "It" is the child.
|
| So if the supervisor ("parent") has other children, they won't
| be restarted
| thruflo wrote:
| One of the great things about the Elixir ecosystem is that, in so
| many cases, the libraries you're using make the appropriate use
| of supervision trees so you don't have to.
|
| Obviously it depends on what you're building and you can craft
| your own supervision structures if you want to. But most of the
| time you can get the benefits of BEAM resiliency without having
| to drop down into the details.
| pests wrote:
| The one thing I dislike about Elixir is the confusion caused by
| how some libraries execute their functionality in-process and
| others spawn a supervision tree and message pass - putting your
| work in a possible queue that can get overloaded.
|
| Its a common pitfall for more inexperienced devs and I think
| its just a symptom of the language conventions.
|
| Everyone is taught genservers with a client-side API existing
| inside the same module as handle_ functions and it blurs the
| distiction some.
|
| I think if the convention was to create a separate module to
| implement the client-side convenience functions then the
| client-server split would be more obvious.
| sodapopcan wrote:
| > The one thing I dislike about Elixir is the confusion
| caused by how some libraries execute their functionality in-
| process and others spawn a supervision tree and message pass.
|
| It's my assumption that needless process-starting is from
| classic OO developers trying to get something closer to the
| objects they're used to. I'm not sure separating the client
| and API logic in tutorials would necessarily stop them from
| doing this. People who are hellbent on shoehorning familiar
| idioms into an unfamiliar language are going to do so
| regardless. But I see what you're saying.
|
| I think it's more important to drill home that modules and
| processes have nothing to do with each other. I still catch
| myself conflating them once in a while three years in and
| it's caused the most confusion while trying to teach friends
| (although I'm not a particularly good teacher).
| cgio wrote:
| This is an allowed practice, just not idiomatic, mostly
| following on Erlang convention I think. If you do the coding
| gnome elixir course, he quite explicitly has a section on
| this and proceeds with separating API from server. At the end
| of the day, it is equivalent and all it takes is getting used
| to one or the other. I would argue spending the time to get
| used to the idiomatic way a community establishes is to your
| benefit in the end.
| pests wrote:
| I agree and love Elixir and use it daily. I think my
| downvotes above is really strange lmao. This is just a
| common footgun I see new developers struggle with.
| sodapopcan wrote:
| My guess re: downvotes is the wording. The opening sort
| of reads like you have written-off Elixir entirely
| because of this one issue. That was the impression I got,
| at least, though I was able to figure out that wasn't the
| case before I responded.
| nighmi wrote:
| Elixir seems to be picking up insane steam right now. Every day
| or two there is a fascinating Elixir post here and its promise
| seems too good to resist. Has anyone else latched their cart onto
| this horse?
| julienmarie wrote:
| Been running our tech stack on Elixir for the last 3 years. I'm
| the owner of a small e-commerce company where I'm the only tech
| person (and also the ceo so I can only spend 20% of my time on
| tech).
|
| Why I love it:
|
| - The mental model just clicks for me. The syntax is really
| simple and the semantics are consistent. There is no
| abstraction. It's all about processing data.
|
| - The REPL (IEX) is way more than a REPL. It's "you inside your
| running program". You can poke around your code, draft it,
| debug it, right there. You can fire it on prod to understand a
| bug. Or use LiveBook, think of it like the Elixir version of
| Jupyter notebooks that can connect to your application.
|
| - Real life performance is great, not because of speed but
| because of concurrency.
|
| - The whole developer experience is great. Mix (the build tool,
| dependency manager, etc.) is simple, awesome. Dependencies are
| really rarely an issue.
|
| - It's rock solid. In 3 years, I never had one downtime.
|
| - LiveView is a god send. Not having to switch language for UI
| work is amazing, performance is great, and it's server side
| HTML which is amazing for SEO. My website is 99 on lighthouse
| without any crazy work.
|
| - You need heavy computation and performance on some parts? Use
| rust, via rustler.
|
| - You need to scale to multiple servers? It is distributed.
| Already. Just make sure to not have anti-patterns in your code.
|
| - But the real kicker it's in its power due to the OTP
| platform. I think it's quite complex to grasp how much it's
| powerful when you haven't experienced it. Need to batch insert
| statements or rate limit api calls to a 3rd party service who
| can only accept one call per second per channel? A working
| simple solution is only 20 lines of code. Need to launch many
| different workflows running concurrently, keeping their state,
| recovering when crashing? 100 lines.
|
| The exciting developments:
|
| - Elixir NX ecosystem (NX, Bumblebee, etc): running and
| training AI models directly in Elixir, in a distributed way.
|
| - Liveview Native and Elixir Desktop: two big initiative to
| bring Elixir to Desktop and Mobile applications.
|
| - Gradual Typesystem. Jose Valim, the creator of Elixir, is
| working on that right now. I really liked the approach of set-
| theoretic types and the pragmatism of the approach. Hopefully
| it will be released in the not too distant future.
|
| The "to improve":
|
| I have the feeling that the platform (OTP) being the killer app
| per se of Elixir, the whole marketing of the ecosystem if 100%
| targeted towards developers. Which is good in many ways. But
| for the ecosystem to grow I think more initiatives towards
| business-type applications would be welcome. By example, there
| is only a few payment gateways libraries existing which is for
| me a sign of the lack of business audience.
|
| Conclusion: Elixir made me a better developer, but most
| importantly a really productive one.
| lkurusa wrote:
| We've been running a large web application backend written in
| Elixir for over three years now. It's awesome and we've also
| rewritten some of our microservices to utilize Distributed
| Erlang. No need for a service mesh this way. :-)
| plondon514 wrote:
| The company I started working for a few months ago wrote their
| whole web app with Elixir/Phoenix LiveView. It's been a real
| pleasure to work with after years of React and Next.js. The
| main thing I miss are types though.
| actionfromafar wrote:
| Are there no typed languages on BEAM?
|
| Or some Typescript style front for Elixir?
| pawelduda wrote:
| Types in Elixir are on the roadmap [1] but I don't think
| there's concrete ETA
|
| For now you have typespecs and dialyzer that tries to infer
| types and detect incorrect assumptions in code but I found
| it cumbersome to work with. Testing in Elixir is first
| class so I prefer that for now. You get doctests
| (documentation that is also a runnable test), like in
| Python, which I find very useful when looking at some
| package source.
|
| [1] https://youtu.be/giYbq4HmfGA?si=BjNyOc5cjWWA7ER6
| lkurusa wrote:
| https://gleam.run/ Gleam is super promising.
| Arubis wrote:
| Part of this is that ElixirConf 2023 just finished up, so we're
| getting the news output of the talks given and libraries
| released.
| [deleted]
___________________________________________________________________
(page generated 2023-09-24 23:00 UTC)