Elixir 1.12(elixir-lang.org) |
Elixir 1.12(elixir-lang.org) |
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.
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.
I always found I had to do that and found it quite annoying (working through adventofcode with elixir..)
That is like, item one on my list of things I need to be able to handle in a backend web application.
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.
See this thread in elixirforum https://elixirforum.com/t/absinthe-graphql-performance-issue...
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)
I'm, though, curious if other people have more insights about that, because it is truly impressive :-)
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.
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 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.
This will be fixed in an update of Erlang.
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.
But in absence of that this is a huge QoL improvement.
tap though... OMG yes!
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 :(
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.
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.
edit: so far so good.
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.
Is that still the case?
Also where does one host Elixir apps these days? Heroku, Vercel or Bare metal?
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.
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.
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
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.
I found it to be extremely performant (especially when compared to the built in xmerl) and I like using the SAX technique.
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.
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.
And I'm biased, but we are a pretty good place to run an Elixir app: https://fly.io/docs/getting-started/elixir/
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.
https://bignerdranch.com/blog/elixir-and-io-lists-part-2-io-...
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'm curious to know what you have heard with more precision, if possible.
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.
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 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.
Thanks for reporting a good experience, this gives me hope that my task won't be daunting!
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.
It helps you to add lots of tiny quality of life improvements to your product that you wouldn't bother with normally.
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".
Many underestimate this but it's a huge benefit for most projects that don't need a complex deployment pipeline.
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 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.
:erlang.localtime()
|> case do; {_, {h,m,_}} -> {h, m}; end
|> do_something
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.
> 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)
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.