Why Elixir (2014)
theerlangelist.com
Why Elixir (2014)
1–10 of 59 posts
Re: Why Elixir (2014)
#2Very relevant to this: How to sell Elixir - a talk from today's ElixirLondon https://speakerdeck.com/evadne/how-to-sell-elixir
Re: Why Elixir (2014)
#3[deleted]
Re: Why Elixir (2014)
#4[deleted]
ElixirConf 2017 is coming up in the US, and there have recently been some conferences in Europe.
Erlang's conference is coming up too... so people are gearing up and getting excited again.
Re: Why Elixir (2014)
#5Very relevant to this: How to sell Elixir - a talk from today's ElixirLondon https://speakerdeck.com/evadne/how-to-sell-elixir
Somehow I get the feeling Elixir is the new Ruby, every time I go through such presentations.
Basically it looks like the escape route for Ruby developers that care about performance.
Re: Why Elixir (2014)
#6Very relevant to this: How to sell Elixir - a talk from today's ElixirLondon https://speakerdeck.com/evadne/how-to-sell-elixir
Somehow I get the feeling Elixir is the new Ruby, every time I go through such presentations. Basically it looks like the escape route for Ruby developers that care about performance.
It's actually Erlang with Ruby-like syntax.
Re: Why Elixir (2014)
#7Very relevant to this: How to sell Elixir - a talk from today's ElixirLondon https://speakerdeck.com/evadne/how-to-sell-elixir
Somehow I get the feeling Elixir is the new Ruby, every time I go through such presentations. Basically it looks like the escape route for Ruby developers that care about performance.
Elixir really isn't just Ruby with better performance. The two look syntactically similar (and have some similar tooling, from rubyists who've moved over to elixir), but that's about where their similarities end.
Ruby really isn't designed for building complex concurrent systems. Erlang/OTP is designed specifically for that.
When I need to build something that recovers from failures in Rails, it means code that is littered with try/catch statements. I recently wrote a basic caching system in Elixir for a project at work. There are plenty of ways for it to fail, and I handle none of those situations. I let it crash, bring it down gracefully, and then bring it back up in a healthy state. You can write truly fault-tolerant programs on top of a very powerful and stable VM.
Re: Why Elixir (2014)
#8I 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.
Getting information on what happens at compile time vs run time is hard.
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.
Not many great design resources.. I mean I've got lots of books on OTP. But if i'm building a daemon which reads off a queue and talks to some databases - where are some patterns I can follow? How do I handle config? What if I want to hotload it?
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?
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.
Flow / Genstage and getting them into a supervision tree? what's the best practices.
I want to introduce it to my workplace but without some of these common patterns easy to find, it's kind of a risk to the business.
Re: Why Elixir (2014)
#9> 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 closer to the Lisp macros. I have not programmed in Elixir yet.
Can someone who knows comment on the similarity here?
Re: Why Elixir (2014)
#10I 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 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 yeah, more resources would definitely be welcome. Hopefully as more people start using the language, more resources will be created.