41–50 of 59 posts
I really am in awe of Elixir. I think it's an amazing language, and it introduced me to Erlang and OTP. I've come from using scala actors, and I can do more in way less time, less memory, and similar performance if I use Elixir. That said, there are some things that suck so hard about it. The log messages suck. If I want to use them in production and actually ship them to ELK or similar, the format really sucks. Gett…
I really am in awe of Elixir. I think it's an amazing language, and it introduced me to Erlang and OTP. I've come from using scala actors, and I can do more in way less time, less memory, and similar performance if I use Elixir. That said, there are some things that suck so hard about it. The log messages suck. If I want to use them in production and actually ship them to ELK or similar, the format really sucks. Gett…
No, I believe that none of these issues are going to last very long - the community is strong, the average skill level of prolific Elixir coders and writers is pretty high, and there's tremendous traction. But currently it's the case and I'd wager that anyone raving on HN about how Elixir is the best thing since sliced bread probably didn't get super much further than a Phoenix CRUD app.
I really am in awe of Elixir. I think it's an amazing language, and it introduced me to Erlang and OTP. I've come from using scala actors, and I can do more in way less time, less memory, and similar performance if I use Elixir. That said, there are some things that suck so hard about it. The log messages suck. If I want to use them in production and actually ship them to ELK or similar, the format really sucks. Gett…
This is a fair point, even in Erlang land. There are a zillion things encouraging you to "let it crash" and far fewer going beyond that.
One thing that doesn't get mentioned often enough is a circuit-breaker like fuse: https://github.com/jlouis/fuse
This also has some more advanced topics:
> Elixir macros are nothing like C/C++ macros. Instead of working on strings, they are something like compile-time Elixir functions that are called in the middle of parsing, and work on the abstract syntax tree (AST), which is a code represented as Elixir data structure. Macro can work on AST, and spit out some alternative AST that represents the generated code. The description above from the article seems like close…
Elixir in general is probably close to Clojure than Ruby in its internals. And well Erlang of course.
Earlier quoted context omitted.
As someone working across JVM, .NET, C++, Android and iOS, I don't have any use case for Elixir. If I ever would need BEAM, Erlang would be quite ok, given that I was quite comfortable with Prolog in the past and do like the syntax. Hence why I kind of see it as BEAM for Ruby developers, even if I am way off what is actually happening on the BEAM world.
If you're doing anything at all server side, you have a use case for Elixir.
Earlier quoted context omitted.
If you're doing anything at all server side, you have a use case for Elixir.
Already covered by the JVM and .NET on my toolbox.
Technically, this stuff is all covered by any preceding language in the toolbox. We could all just use C...or Perl?
Why bother to learn the JVM languages when C already had it covered?
Simple...because you can do it better.
Earlier quoted context omitted.
I know it's probably not the answer you're looking for, but you can learn a lot by just reading the code of popular Elixir libraries, such as Ecto, Phoenix, etc. Error messages have gotten better in Elixir 1.5 The whole ecosystem is actually getting better with each release. For shipping to production I use 'distillery'. You create a 'release' and you can even instruct it to read some arguments from the env vars. But…
> You create a 'release' and you can even instruct it to read some arguments from the env vars. That's my main complain about Elixir. Releasing and configuring at runtime is a huge pain. I honestly don't see any value in this whole "compile time configuration". If it's at compile time, I can put it in the code. What I call configuration is things I can change at runtime. The fact that something that is a given in any…
Earlier quoted context omitted.
Already covered by the JVM and .NET on my toolbox.
Sure. So why does any other language need to exist? Technically, this stuff is all covered by any preceding language in the toolbox. We could all just use C...or Perl? Why bother to learn the JVM languages when C already had it covered? Simple...because you can do it better.
UNIX -> C
Browser -> JavaScript
Data Science -> Python, R, Julia, Chapel, C++
Windows Development -> .NET languages, C and C++
Android -> Java, Kotlin, C and C++
macOS, iOS, tvOS, watchOS -> Objective-C, Swift, C and C++
Docker, Kubernetes -> Go
Game development -> Assembly, C, C++ and C#
High performance data switches -> Erlang
Of course one is free to use outlier languages and try to bend them into specific use cases, but then one also has to live with less tooling as the ones that are the "platform language" for the specific use case.
Throughout my career I always kept an open mind to try out new programming languages and paradigms, but in what concerns production code I learned the hard way to only use the official platform languages.
I really am in awe of Elixir. I think it's an amazing language, and it introduced me to Erlang and OTP. I've come from using scala actors, and I can do more in way less time, less memory, and similar performance if I use Elixir. That said, there are some things that suck so hard about it. The log messages suck. If I want to use them in production and actually ship them to ELK or similar, the format really sucks. Gett…
I will add some comments below but they are not meant to dispute your claims but to find places where we can improve.
> The log messages suck. If I want to use them in production and actually ship them to ELK or similar, the format really sucks.
Do you mean the Logger messages? Their format is customizable. Can we make this clearer?
> Getting information on what happens at compile time vs run time is hard.
Which kind of information do you need? Is it something that would fit the meta-programming guide on the website? Or maybe we are missing a more detailed compiler guide?
> How do you handle operating system signals? like when your autoscale group decides to scala down and you get a SIGTERM with some time to handle it, what do you do? wrapper scripts suck.
It was not possible cleanly until OTP 20, so it is fairly new. At least, from 19.x onwards, the VM will shutdown cleanly on SIGTERM - which means shutting down all applications and supervision trees. A lot of guides (including the Elixir guides) cover supervisor only through the fault tolerance perspective, while they also encapsulate the start-up and shutdown logic. I have opened an issue for this here: https://github.com/elixir-lang/elixir/issues/6479
> What command do I run? when do I run an app vs compiling it? What If I want command line args? Where's a good example of writing an app, which is a daemon, and using an escript to reconfigure it at runtime?
Running your code is a matter of starting your application. We don't really have a `main` procedure as an entry point. Your system is designed as a series of applications and you start them. If you are using mix, it should be a matter of `mix run --no-halt`. If you are using releases, it automatically starts the system for you. Where would you expect to find this information? Did you see `mix run` at all? Maybe in the escripts page we should point to `mix run` as it seems an `escript` is really not required in your case?
> The error messages. Holy hell. What actually caused a pattern match to not work? what is it expecting? especially a few function calls deep - like interaction between tuples and arrays and keyword lists.
Those particular error message were fixed in Elixir v1.5 (with OTP 20+). Pull request is here: https://github.com/elixir-lang/elixir/pull/6127
> Flow / Genstage and getting them into a supervision tree? what's the best practices.
Please open up an issue. If this is not clear form the documentation, it is a "bug" in the docs.
It is also worth mentioning that Ben Marx, Bruce Tate and I are working on book called "Adopting Elixir" (https://pragprog.com/book/tvmelixir/adopting-elixir). The last three chapters focus exclusively on production aspects and it answers many of the questions here (log configuration, system termination, how to run it, design, etc).
Earlier quoted context omitted.
As someone working across JVM, .NET, C++, Android and iOS, I don't have any use case for Elixir. If I ever would need BEAM, Erlang would be quite ok, given that I was quite comfortable with Prolog in the past and do like the syntax. Hence why I kind of see it as BEAM for Ruby developers, even if I am way off what is actually happening on the BEAM world.
100% This. The use cases for OTP are actually quite narrow, despite what Erlang/Elixir evangelists tell you. Discord is a fantastic use for OTP. Writing a CRUD app with a couple of reactive/interactive pages for comments on videos and few thousand users, OTP is overkill. If you have an app that needs the scale and safety of OTP, then which language you pick makes no difference. Phoenix is a really cool project, writt…
I like to describe Elixir should suit well anything that runs on top of a TCP socket. A binary protocol, an HTML app, a JSON API or even a distributed system. Embedded systems is coming up as a new area of interest as well.
I wouldn't say those cases are narrow. But I believe you meant the use cases are narrow if you are already using other platforms. Then indeed we have many things to consider beyond the technical aspects.
But I also would like to argue that scale and safety are not the only reasons to try Elixir and OTP. I personally find functional code easier to maintain, especially because of immutability. The performance aspects really shows up during development and testing as well. I wrote a bit about the latter here: http://blog.plataformatec.com.br/2017/07/the-fallacies-of-we...