Elixir 1.12(elixir-lang.org)
elixir-lang.org
Elixir 1.12
https://elixir-lang.org/blog/2021/05/19/elixir-v1-12-0-released/
108 comments
> 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.
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.
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.
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..)
I always found I had to do that and found it quite annoying (working through adventofcode with elixir..)
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.
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.
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.
That is like, item one on my list of things I need to be able to handle in a backend web application.
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.
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.
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]
> 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.
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.
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%.
Havent's measured by myself but I'd expect performance noticeable improvement for GraphQL apps that use Absinthe, since significant time is spent on parsing, validating and serializing data around resolvers.
See this thread in elixirforum https://elixirforum.com/t/absinthe-graphql-performance-issue...
See this thread in elixirforum https://elixirforum.com/t/absinthe-graphql-performance-issue...
excellent list, thanks for sharing this.
Timex was never needed. We have a library Calendar.DateTime that has all the functionality we need
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.
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)
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)
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.
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.
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.
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.
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.
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.
It helps you to add lots of tiny quality of life improvements to your product that you wouldn't bother with normally.
[deleted]
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.
What made you do that? Genuinely curious. You immediately suspect trolling when you see people complaining about Elixir?
Oh yes, @joelbluminator, the troll-in-chief when it comes to Elixir posts. You really have an axe to grind against this language, do you?
> For one I really do think Elixir is a horrible career choice and I wanna save young average developers who still have time to correct that mistake (https://news.ycombinator.com/item?id=27204755)
Sadly, your trolling is too subtle to get shadow banned, so we are doomed to keep reading your inane comments in every Elixir thread, hiding under the cowardly guise of "doing it for the young developers."
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
> Im not at all negative about Elixir. It could be a fantastic tool, I never used it. (https://news.ycombinator.com/item?id=26905869)
> For one I really do think Elixir is a horrible career choice and I wanna save young average developers who still have time to correct that mistake (https://news.ycombinator.com/item?id=27204755)
Sadly, your trolling is too subtle to get shadow banned, so we are doomed to keep reading your inane comments in every Elixir thread, hiding under the cowardly guise of "doing it for the young developers."
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
> Im not at all negative about Elixir. It could be a fantastic tool, I never used it. (https://news.ycombinator.com/item?id=26905869)
The funny thing is that I remember back in the Aughts when guys like that were trying to "save" people from using Ruby or Python.
[deleted]
[deleted]
[deleted]
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.
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.
Likewise. It’s superb, and I haven’t had an issue getting developers (though half have been Ruby devs who picked it up easily).
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.
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.
> 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.
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.
Same here at Papa - we love Elixir and can't imagine using anything else. The dev ux is tremendous.
> 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
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
Sorry only have a video for you, still worth watching IMHO https://youtu.be/JvBT4XBdoUE
Thank you!
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".
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]
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.
Many underestimate this but it's a huge benefit for most projects that don't need a complex deployment pipeline.
This might be inappropriate but are you hiring right now?
Would love to get a chance at writing in Elixir.
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.
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.
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.
I found it to be extremely performant (especially when compared to the built in xmerl) and I like using the SAX technique.
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!
Thanks for reporting a good experience, this gives me hope that my task won't be daunting!
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.
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.
[deleted]
[deleted]
>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.
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.
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.
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 :-)
I'm, though, curious if other people have more insights about that, because it is truly impressive :-)
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.
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.
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.
- 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.
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.
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.
That's partly because Jose is a machine. I have one anecdote that might provide some insight:
I filed a bug that turned out to be an incorrect dialyzer spec on a library function. Jose fixed it and merged the fix to master within 40 minutes of me filing the bug. It was a small issue, and I had done a reasonable job at bug filing (small test case, pointers to source of problem) but to have that level of discipline and responsiveness on bug fixing is spectacular.
I filed a bug that turned out to be an incorrect dialyzer spec on a library function. Jose fixed it and merged the fix to master within 40 minutes of me filing the bug. It was a small issue, and I had done a reasonable job at bug filing (small test case, pointers to source of problem) but to have that level of discipline and responsiveness on bug fixing is spectacular.
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.
This will be fixed in an update of Erlang.
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.
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.
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!
But in absence of that this is a huge QoL improvement.
tap though... OMG yes!
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 :(
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 :(
> 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?
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?
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:
`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.
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
`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.
Hm, this works and is about as terse as `pattern_tap`:
:erlang.localtime()
|> case do; {_, {h,m,_}} -> {h, m}; end
|> do_something
That's actually what pattern_tap's tap macro expands into :) See: https://github.com/mgwidmann/elixir-pattern_tap/blob/master/...
> 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.
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.
[deleted]
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).
Oh really cool!
Which University then?
[deleted]
Thanks. For various reasons I'd rather not say here.
I work in the Wireless and Digital Systems department of Cambridge Consultants (Cambridge, UK). We build weird and wonderful radio systems for clients. We are using an increasing amount of Elixir and Erlang because it's a great fit for what we do, but it's still in the minority.
Yes I know your company, but wasn't aware you were using Elixir/Erlang. Thanks for the heads up!
V7(v7labs.com) is based in London and we are going to be looking for junior engineers quite soon. We use Elixir quite extensively. Drop us an email!
Will do, thanks!
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)
It's such a tiny thing, but being able to paste code with pipelines into iex is a great quality of life improvement.
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.
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.
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.
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.
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).
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.
We do build for subpatch versions: https://hub.docker.com/repository/docker/hexpm/erlang/tags?p...
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.
Thanks, I'll look into it.
edit: so far so good.
edit: so far so good.
This video by Saša Jurić -- https://www.youtube.com/watch?v=JvBT4XBdoUE -- is really interesting.
It moves kind of fast and you might need to rewatch a few parts, but it demonstrates some of the principals that make Elixir / Erlang so compelling.
If you watch this, imagine what you would need to do as a developer to make this work in your language of choice.
It moves kind of fast and you might need to rewatch a few parts, but it demonstrates some of the principals that make Elixir / Erlang so compelling.
If you watch this, imagine what you would need to do as a developer to make this work in your language of choice.
Neat. I love how I can install packages in Common Lisp REPL, and now I can do it with Mix.install.
What are some good non-book text-based in-depth resources for learning Elixir?
https://elixirschool.com is really good
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
https://elixir-lang.org/getting-started/introduction.html
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?
Is that still the case?
Also where does one host Elixir apps these days? Heroku, Vercel or Bare metal?
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 :)
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/
And I'm biased, but we are a pretty good place to run an Elixir app: https://fly.io/docs/getting-started/elixir/
> 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.
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.
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-...
https://bignerdranch.com/blog/elixir-and-io-lists-part-2-io-...
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.
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.
Is it just "mix build" that you run, or something more special?
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.
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.
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.
I'm curious to know what you have heard with more precision, if possible.
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).
HN hug of death strikes again
> 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.
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.
Just to get a frame of reference, what is memory efficient for web servers?
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.
Huh? Elixir isn't memory effecient, compared to what exactly :)?
It also really depends what you're doing - if you need millions of processes almost nothing is more memory efficient.
assembly probably /s
Render.com does a great job at running distributed Elixir.
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.