[HN Gopher] Elixir 1.12
___________________________________________________________________
Elixir 1.12
Author : princemaple
Score : 356 points
Date : 2021-05-19 10:21 UTC (12 hours ago)
(HTM) web link (elixir-lang.org)
(TXT) w3m dump (elixir-lang.org)
| WayToDoor wrote:
| See also, https://news.ycombinator.com/item?id=27192873 (Ask HN:
| Are you satisfied with Elixir or do you regret choosing Elixir?)
| with great insights about the language.
|
| Another popular thread that comes to mind is the one about
| Discord scaling Elixir
| (https://news.ycombinator.com/item?id=14748028 and
| https://news.ycombinator.com/item?id=19238221)
| thibaut_barrere wrote:
| Disclaimer: I use Elixir in production (e.g. here on the French
| national transport data hub
| https://transport.data.gouv.fr/?locale=en), but I also like
| other tools (Ruby, Rust, Crystal etc).
|
| My impression is that some (not all) people had a bad
| experience partly because they may have reached for Elixir at a
| period where everything wasn't "settled" (a bit too young). The
| "first vague of hype" generated some libraries which are now
| unmaintained (e.g. oauth2), and some parts are still rough
| (XML, I look at you).
|
| Having upgraded a number of old apps, though, I find that
| library quality has gone up, the overall developer (and
| maintainer) experience has improved, and there is a sense of
| stability which will have a real impact I believe.
|
| There is a need to reach a larger critical mass I believe to
| really enjoy things in full, but as far as I am concerned, I
| would be perfectly confident to build my next SaaS on top of
| it.
| sneako wrote:
| Check out Saxy for XML: https://github.com/qcam/saxy
|
| I found it to be extremely performant (especially when
| compared to the built in xmerl) and I like using the SAX
| technique.
| thibaut_barrere wrote:
| Saxy is already in my bookmarks because we're going to
| ingest the largest XML files I've ever scanned with Elixir
| soonish.
|
| Thanks for reporting a good experience, this gives me hope
| that my task won't be daunting!
| bryanrasmussen wrote:
| >with great insights about the language.
|
| most insights there, in relation to leaving, are not about the
| language but in relation to the environment, e.g available
| packages, integration with external tools etc. as reasons for
| the aforementioned departures.
| [deleted]
| sodapopcan wrote:
| It makes me really sad that Elixir isn't more popular than it
| is. I'm just a hobbyist but would jump at a good opportunity to
| write it full time (though I'm really happy with my current
| employer and want to put more time in with them). There's just
| so little BS in the language itself (by my standards). A good
| Elixir program reads SO well thanks to some strong conventions.
| I particularly like how it's very common to forgo imports and
| just prefix functions with their module name. That coupled with
| it being functional make for very little need to jump around
| when trying to understand a function--everything is just right
| there. It's also so nice having a performant, query-able key-
| value store at your fingertips. Anyway, I dunno, I know that it
| being a dynamic language is a deal-breaker for many but gah,
| I'm rambling at this point. I just really, really like it.
| nelsonic wrote:
| Sadly that HN thread is biased toward the person/team that is
| "leaving" Elixir because it wasn't a good fit for them. For the
| people who understand Elixir/OTP's strengths it's excellent. We
| use Elixir for several apps and haven't had any issues
| recruiting/training people (remote). If we were to chose again
| we would 100% pick Elixir; nothing else comes close for our
| use-case.
| weatherlight wrote:
| I went though that persons submissions/comments on HN. its
| literally the only time they mention Elixir, everything else
| is ruby/rails or python. Makes me wonder if it's a troll
| post.
| joelbluminator wrote:
| What made you do that? Genuinely curious. You immediately
| suspect trolling when you see people complaining about
| Elixir?
| pdimitar wrote:
| Of course not. But reading how somebody who is strongly
| convinced that their current tech choice is good is
| trashing another tech that didn't immediately solve all
| their problems isn't a compelling or objective criticism
| either, wouldn't you say?
|
| Thinking back, I remember that the guy had 1-2 good
| points but the rest was mostly ranting. They are fun to
| read but rarely are informative.
| swat535 wrote:
| > Sadly that HN thread is biased toward the person/team that
| is "leaving" Elixir because it wasn't a good fit for them
|
| Having a balanced pros and cons are great for everyone. Not
| every thread should be praising Elixir else people won't be
| able to make an informed decision before selecting a language
| to build their business on.
|
| I'm personally more interested in cons of a tool as opposed
| to the pros. This way I can assess whether the failure points
| are within the acceptable parameters or not.
| Vekkby wrote:
| This might be inappropriate but are you hiring right now?
| Would love to get a chance at writing in Elixir.
| rapsey wrote:
| The point how all of Erlangs strengths are now obsolete
| because of XYZ that now exists misses the point how with
| Erlang/Elixir all of those things are at your fingertips
| using a single technology stack that is not hard to use and
| will scale very well for practically anyone.
| realusername wrote:
| That's basically it, yes for sure I could install some
| external pubsub software & associated frontend & backend
| boilerplate with any other stack but I just wouldn't bother
| doing it for just refreshing a tiny counter whereas with
| phoenix pubsub & liveview, it's just one line of code.
|
| It helps you to add lots of tiny quality of life
| improvements to your product that you wouldn't bother with
| normally.
| rio517 wrote:
| I think I saw this one. In many cases there are some crazy
| good, purpose built solutions that are better than what
| Erlang/Elixir can offer, but that requires learning and
| managing all that tooling. Often, good enough is fine -
| especially for small productive teams.
|
| I'm on my second team that has adopted Elixir and it has
| really helped our productivity being able to keep so many
| capabilities in one kit.
| [deleted]
| sergiotapia wrote:
| Same here at Papa - we love Elixir and can't imagine using
| anything else. The dev ux is tremendous.
| thibaut_barrere wrote:
| I'll add that even without understanding OTP in full, people
| will get good results.
|
| I have also had good results with non-Elixir coders learning
| it with a bit of coaching, and recruiting is OK these days
| due to interest of developers for the language.
| heeton wrote:
| Likewise. It's superb, and I haven't had an issue getting
| developers (though half have been Ruby devs who picked it up
| easily).
| konart wrote:
| > For the people who understand Elixir/OTP's strengths it's
| excellent.
|
| Is there any place to read about this on a more or less basic
| level? I bet many people will just ask what benefits they may
| get from this instead of apps build using Go (for example) +
| rabbitmq
| bcrosby95 wrote:
| If you're trying to limit your exposure to different
| technologies, then I think Elixir is a great choice.
|
| If you're going all in on cloud, microservices, and managed
| services, then - outside some specific problems - I'm not
| sure if Elixir is any better of a choice than other
| language. I personally like immutability+FP but that feels
| a bit subjective.
|
| But I've worked at small companies for most of my career,
| and it's my (obviously subjective) opinion that Elixir will
| let you build a better system if you don't have the luxury
| of using the "right tool for each task".
| [deleted]
| pdimitar wrote:
| One big selling point is having almost everything you need
| right there with you in the same runtime environment (the
| Erlang's BEAM VM).
|
| Many underestimate this but it's a huge benefit for most
| projects that don't need a complex deployment pipeline.
| scns wrote:
| Sorry only have a video for you, still worth watching IMHO
| https://youtu.be/JvBT4XBdoUE
| [deleted]
| wkfavdpb wrote:
| I'm actually surprised by that thread, every time I see an
| Elixir related article on hear the comments are usually all
| talking about what a joy it is to work in. (as you can see in
| this thread).
|
| I have been doing elixir for the past ~1yr and from my
| experience it's the language itself is pretty good, but I
| really wish it had better tooling, static typing, and more
| mature libraries for interacting with common tools. Just my own
| opinion, but I would chose another language for future
| projects.
| andy_ppp wrote:
| The one thing I'll say about Elixir I'm always impressed how
| disciplined they are with the issue tracker on GitHub. Currently
| 17 issues for such a broad piece of work seems nothing less than
| astonishing.
| thibaut_barrere wrote:
| I believe it is due to 2 things: excellent vision and work
| first, but also the nature of the language (not a coincidence)
| tend to lead to strong "lever effect", 2nd level order
| benefits, hard focus on composability.
|
| I'm, though, curious if other people have more insights about
| that, because it is truly impressive :-)
| andy_ppp wrote:
| My personal feeling is that it's purity, immutability and
| simplicity of vision. That most of Elixir is also written in
| Elixir helps.
|
| Erlang/the Beam also helps - there are only 112 open Erlang
| bugs.
|
| For reference Golang has 6843 open GitHub issues. I am not
| sure what to make of this.
| Thaxll wrote:
| Rust has the same number of issues open then what? You're
| comparing a simple language that is built on top of Erlang.
| It has a few issues because:
|
| - the code base is small
|
| - it has a few users compare to other languages
|
| - it's built on top of something else
|
| I was curious and I looked at the std lib for Elixir it's
| very minimal.
| rio517 wrote:
| I'd also add it is pretty amazing how responsive and friendly
| the core team is. They generally are very clear, but polite
| when they don't accept something and super fast about
| addressing bugs.
|
| I started following phoenix and a few other important Elixir
| repos on github several months ago. I'm amazed how many times
| the community has taken the time to help someone debug why
| their specific scenario isn't a bug with the library and
| pointed them to the right solution.
| yewenjie wrote:
| What are some good non-book text-based in-depth resources for
| learning Elixir?
| jetpackjoe wrote:
| https://elixirschool.com is really good
| H12 wrote:
| I found going through the official Elixir guide top-to-bottom
| to be an excellent crash course:
|
| https://elixir-lang.org/getting-started/introduction.html
| namelosw wrote:
| Neat. I love how I can install packages in Common Lisp REPL, and
| now I can do it with Mix.install.
| dovrce wrote:
| If you are working through a programming textbook and doing the
| exercises in elixir, LiveBook is great https://github.com/elixir-
| nx/livebook (vs one big mix project)
| conradfr wrote:
| Great news. I'll wait for the official docker image to be updated
| (I deploy on my own server with CapRover).
|
| Seems a bit weird though that they do not generate images for the
| same elixir version with different OTP versions.
|
| Currently the latest is elixir v1.12.0-rc.1 and erlang 23.
| losvedir wrote:
| I highly recommend using the hexpm docker images, which you
| specify with elixir, erlang, and distro versions, e.g.
| hexpm/elixir1.12-erlang24.0-debian-buster.
|
| Since the official Elixir versions aren't pinned to a version
| of Erlang, we had issues where either Erlang or the distro
| should change out from under us. But not with the hexpm ones.
| _asummers wrote:
| Only issue here is that they don't do subpatch versions. We
| needed Erlang 22.3.4.1 for something, so had to build by
| hand.
| ericmj wrote:
| We do build for subpatch versions: https://hub.docker.com/r
| epository/docker/hexpm/erlang/tags?p...
| _asummers wrote:
| Ooooh that didn't used to be true, from what I saw! Happy
| that changed. I can clean up a bunch of images on my
| side.
| thibaut_barrere wrote:
| I second this - it is the best solution if one wants to
| decouple upgrades of Elixir vs OTP, and is really useful for
| long term upgrades (one step at a time).
| conradfr wrote:
| Thanks, I'll look into it.
|
| edit: so far so good.
| wardb wrote:
| There is a known issue with building Erlang/OTP R24 on MacOS.
| Check this gist for current workarounds:
| https://gist.github.com/jj1bdx/972ba8da566f7e2eb1ff209fe4865...
|
| This will be fixed in an update of Erlang.
| svrtknst wrote:
| There are some nice bits in here.
|
| tap() and then() are fairly minor, but very nice quality-of-life
| additions.
|
| The work on numerical, livebook, Mix.install etc are healthy
| steps to take.
|
| Nice work.
| dmitriid wrote:
| I wish they'd instead fix the compiler to not require .then
|
| But in absence of that this is a huge QoL improvement.
|
| tap though... OMG yes!
| klibertp wrote:
| I was very, very disappointed that the `tap` macro has
| nothing to do with pattern_tap:
| https://github.com/mgwidmann/elixir-pattern_tap
|
| Basically, in Elixir pipelines are not very friendly to
| simple destructuring: if a call at the beginning of the
| pipeline returns a tuple of `{:ok, result}`, you can't use
| either of shortcut syntaxes for lambdas (&Mod.fun/arity and
| &Mod.fun(&1)), you have to use `fn` and destructure in its
| head. pattern_tap solves this quite elegantly, but I was told
| that it's a "non-standard macro that people don't know, so it
| shouldn't be used"... So when I saw `tap` in Kernel, I though
| that _maybe_ it 's similar at least... unfortunately, it's
| not similar at all, and now the global identifier `tap` is
| taken, which made the situation even worse :(
| [deleted]
| shakow wrote:
| > if a call at the beginning of the pipeline returns a
| tuple of `{:ok, result}`
|
| In my understanding, pipeline are mostly reserved for
| "unfailable" operations operating on raw data; whereas the
| where/else/do macro is more oriented towards errors
| handling; would it work better in your case?
| klibertp wrote:
| I think you mean `with`, not `where`? Yes, it helps a bit
| in some cases, but it's not a replacement for a pipeline
| - mainly because you'd need to name your intermediate
| results and "thread" them through the calls yourself.
|
| I think I gave a bad example, the better one would be a
| function returning datetime in the format of
| :erlang.localtime: `{{Year,Month,Day},{Hour,Min,Sec}}`. I
| would like to be able to use this value in a pipeline, by
| passing only a `{Hour, Min}` tuple to the next call in
| the pipeline.
|
| With pattern_tap it looks like this:
| :erlang.localtime() |> tap({_, {H,M,_}} ~> {H,
| M}) |> do_something
|
| Without - there are at least 3-4 ways of doing this, each
| with pros and cons, but all of them are more verbose than
| pattern_tap. If you want a single value only, there's
| `elem`, but if you need a few - you're out of luck.
| `destructure` only works on lists, and `match?` only
| return a boolean, not whatever was matched.
|
| `then` macro makes it a bit better, but you still need to
| create a lambda with the longhand syntax, which is
| exactly what I wanted to avoid, so it's hardly a
| solution, even though it may be the best way to do this
| for now...
|
| EDIT: this is in contrast to Clojure, where maps and
| vectors are _callable_ , and you get `juxt` in the
| stdlib. So it's not like pipelines in general can't
| support convenient extraction of subsets of data flowing
| through the pipe, it's just that Elixir decided not to
| support this.
| shakow wrote:
| > I think you mean `with`, not `where`?
|
| Indeed, my bad.
|
| > the better one would be a function returning datetime
| in the format of :erlang.localtime:
| `{{Year,Month,Day},{Hour,Min,Sec}}`
|
| I see what you mean. Yeah, I agree with the rest.
| losvedir wrote:
| Hm, this works and is about as terse as `pattern_tap`:
| :erlang.localtime() |> case do; {_, {h,m,_}} ->
| {h, m}; end |> do_something
|
| Not that I'd want to do that in production code, but I
| felt a bit nerd-sniped here, to see the shortest way I
| could find without dependencies.
| anonymousDan wrote:
| As an aside, I teach Elixir as part of my distributed systems MSc
| course. Anyone here in the London area (or even UK) looking for
| junior engineers? It would be nice to have some companies to
| point my students at when they start looking for jobs (or year in
| industry).
| AlchemistCamp wrote:
| It's such a tiny thing, but being able to paste code with
| pipelines into iex is a great quality of life improvement.
| yannoninator wrote:
| Looking into Elixir, but from what i've heard, Elixir isn't very
| memory efficient when it comes to web servers.
|
| Is that still the case?
|
| Also where does one host Elixir apps these days? Heroku, Vercel
| or Bare metal?
| josevalim wrote:
| > Looking into Elixir, but from what i've heard, Elixir isn't
| very memory efficient when it comes to web servers.
|
| It really depends on your reference point and what your web
| servers are doing. The Elixir website has a series of cases and
| perhaps you can find an example closer to what you are doing:
| https://elixir-lang.org/cases.html - there are also cases where
| companies reduced the number of nodes in production once they
| migrated to Elixir.
|
| Regarding deployments, Heroku, Gigalixir, Fly.io, Droplets,
| K8s, etc are all viable options.
| linkdd wrote:
| For me, it's: libcluster (automatic clustering with Kubernetes
| Service) + horde (distribute workload across cluster) +
| Kubernetes Deployment
|
| Whenever I need to upgrade, I perform a rollout, new OTP
| application instances perform a takeover, once it's done
| previous pods are taken down.
| cpursley wrote:
| Render.com does a great job at running distributed Elixir.
| thejosh wrote:
| Huh? Elixir isn't memory effecient, compared to what exactly
| :)?
| deallocator wrote:
| assembly probably /s
| andy_ppp wrote:
| It also really depends what you're doing - if you need
| millions of processes almost nothing is more memory
| efficient.
| 1_player wrote:
| My Elixir backend, doing background processing, admin
| interface, data ingestion and serving data via GraphQL consumes
| 300 MB RAM on average, which is 20% less memory than the
| Node/Next.JS React frontend. YMMV.
| thibaut_barrere wrote:
| I've heard some stories, mostly around XML handling if I recall
| well, and also due to people not using a form of streaming when
| it would have been necessary.
|
| I'm curious to know what you have heard with more precision, if
| possible.
| acdibble wrote:
| I host a pet project Slack bot on a Digital Ocean droplet. You
| can compile an Elixir app into an executable that treeshakes
| the BEAM. I can't speak to memory usage, but deployment for me
| is as easy as compiling an executable and putting it on the
| server.
| tommica wrote:
| Is it just "mix build" that you run, or something more
| special?
| dudul wrote:
| Just to get a frame of reference, what is memory efficient for
| web servers?
| brightball wrote:
| Because of the way that Phoenix handles HTML templates it's
| probably one of the most memory efficient.
|
| https://bignerdranch.com/blog/elixir-and-io-lists-part-2-io-...
| mrkurt wrote:
| This runs on 256mb VMs and works well even when it gets busy:
| https://liveview-counter.fly.dev
|
| And I'm biased, but we are a pretty good place to run an Elixir
| app: https://fly.io/docs/getting-started/elixir/
| chrismccord wrote:
| For a frame of reference, an Erlang VM running all of Phoenix
| will consume 16MB memory on startup, so we need more details on
| what exactly you've heard and for what usecases. For the
| Phoenix channels 2M connection benchmark, some folks claimed go
| uses less memory for websockets, but neglected to consider our
| realtime layer monitors connections for multiplexed messaging,
| handles distributed PubSub, etc, so it wasn't a proper
| comparison. There are certainly nuanced convos we could have
| about memory usage vs other platforms, but a blanket "non
| memory efficient for web" anecdote is inaccurate :)
| conradfr wrote:
| You could create a Phoenix project, launch it and use the
| erlang observer or the Phoenix LiveDashboard to monitor memory
| consumption and decide if that suits you.
| mrjoelkemp wrote:
| I have https://elixirdaily.link (an elixir/beam news aggregator
| running) on the smallest, free Gigalixir VM just fine. Does a
| ton of memory intensive work and doesn't go OOM (had to be
| careful with # outbound http connections).
| sbarre wrote:
| Oops I think we broke your app.
| nwsm wrote:
| Something something demo gods
| deallocator wrote:
| HN hug of death strikes again
| shakow wrote:
| > Elixir isn't very memory efficient when it comes to web
| servers.
|
| I'm serving (https://domovik.app) for a few dozen people on a
| few dozens MB of RAM. Sure, it's not Google scale, but I really
| can't complain about memory usage.
| losvedir wrote:
| Several versions ago Jose talked about how Elixir is basically
| "done", which is so refreshing these days!
|
| But since then, the developer experience has improved by leaps
| and bounds through all these improvements other than the core
| language. As a professional Elixir developer for the last 4
| years, I'm loving it. A few improvements in the last few versions
| off the top of my head that have been really nice:
|
| * Robust, timezone handling DateTime support in the standard
| library. I don't need Timex anymore!
|
| * Finally a good approach for configuring applications ar _run_
| time (e.g. with ENV vars), that works for dev, test, prod _and_
| releases, via config /runtime.exs.
|
| * Better compiler warnings verging on a little "light" type
| checking
|
| * Mix.install in this release finally makes Elixir work well for
| one-off little scripts, since you can just throw a
| Mix.install([:jason, :mojito]) on top.
|
| * LiveView is amazing, and I now keep open a LiveBook notebook
| for doodling in code, exploring an API, CSV, etc
|
| * Not really Elixir, but I'm jazzed about Erlang/OTP 24 JIT
| support for better performance.
|
| Basically, if you took a look at Elixir a few years ago and
| thought it wasn't ready, might be worth another peek now.
| fastball wrote:
| Wait Elixir didn't have a good approach for env vars until
| recently?
|
| That is like, item one on my list of things I need to be able
| to handle in a backend web application.
| _asummers wrote:
| It had them. But if you did a System.get_env inside the
| config.exs/dev.exs/prod.exs etc it would be at compile time.
| Various patterns arose to do that at runtime, by using things
| like `{:system, "FOO", Integer}` as conventions, but it was
| always a bit ad hoc. If a lib saw that they would know to
| punt the actual reading to runtime, which is what many folks
| did before releases.exs, which runs at RUNTIME, so things
| like System.get_env work as expected.
| losvedir wrote:
| Yeah, basically this. Quite ad-hoc.
|
| The mechanism that Elixir used for providing different
| configuration values for dev, test, and prod (via dev.exs,
| test.exs, and prod.exs files), did not work well with
| environment variables, since those configuration files were
| evaluated at build time, which wouldn't work if you built,
| e.g., a single prod app and wanted to run it with different
| ENV vars in staging and prod.
|
| Meanwhile, as of Elixir 1.10, there was a file called
| releases.exs which you could use to configure your release
| (basically a compiled artifact that included the BEAM VM
| runtime system that you could drop on your server to run,
| the preferred way of deploying production apps). However,
| _those_ values didn 't affect running the app not as a
| release, which is common when developing locally.
|
| In the end, our organization kind of standardized on an
| approach of reading the ENV vars in the app start up, at
| the top of the supervision tree, which kind of worked in
| all scenarios.
|
| But then in Elixir 1.11 there's finally a great (IMO) way
| of configuring: a new file called runtime.exs which is the
| best of all worlds. Like the old dev/test/prod files, it's
| evaluated when you run a mix project, so it's used during
| local development, and has access to Mix.env, so you can
| set variables based on environment. But it instead of being
| evaluated at build time, it's evaluated at run time, so you
| can refer to environment variables, too. And, it's used by
| releases!
|
| So now there's a very slick standard way to configure your
| app, that works in all situations.
| [deleted]
| thejosh wrote:
| Yep, when you consider a language "done", you can focus on
| bringing up the DX. I have been loving Elixir since 2016 and
| haven't looked back since, using it as my primary language for
| what it's good for, which is web based/distributed workloads.
| ch4s3 wrote:
| > Not really Elixir, but I'm jazzed about Erlang/OTP 24 JIT
| support for better performance.
|
| I'm really interested to see how the JIT effects our app. I've
| seen some reports suggesting that a 20% bump in speed isn't
| unreasonable to expect.
| pdimitar wrote:
| Haven't had a chance to observe a lot of runtime stats yet
| but I can tell you that my compile times in big projects fell
| down dramatically with Erlang/OTP 24.0, at times with 35%.
| princevegeta89 wrote:
| Timex was never needed. We have a library Calendar.DateTime
| that has all the functionality we need
| _asummers wrote:
| DateTime was added in Elixir 1.8.0. Timex filled a vacuum for
| a long time, and still has a few nice convenience functions.
| In new codebases, I of course drop Timex, but it was very
| much needed until those APIs were added.
| rubyn00bie wrote:
| > Mix.install
|
| This is game changing for me (my life is boring). I totally
| didn't even know this was coming. It's like unexpected
| Christmas! For folks not in the know, it's been kind of a PITA
| to have packages loaded in an Elixir repl without a proper
| project. This should enable a lot more developer tooling to
| exist too; I'm stoked because I have one tool in particular
| that's going to be immediately be useful thanks to this change.
| patrickdavey wrote:
| Does that mean you're going to be able to drop into an
| Iex.pry session right in the middle of an exs script without
| having to wrap it all in a project?
|
| I always found I had to do that and found it quite annoying
| (working through adventofcode with elixir..)
| blandflakes wrote:
| Agreed that this is huge for quality of life - the ability of
| Ammonite (a Scala shell) to require remote dependencies in
| the script is amazing, compared to having to set up a whole
| project and build a jar.
| chefandy wrote:
| Hey, thanks for this super useful breakdown. I loved Elixir
| looking at it a few years ago but never got productive enough
| in it to do more than a few smaller toy projects. I'm going to
| dig into it again.
| waynesonfire wrote:
| excellent list, thanks for sharing this.
___________________________________________________________________
(page generated 2021-05-19 23:01 UTC)