Because it makes me happy.. and OTP, Beam, Jose and team are amazing.
Why Elixir (2014)
31–40 of 59 posts
Re: Why Elixir (2014)
#32Earlier 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…
I appreciate the response, at any rate. I will read more libraries; hopefully I can find some which use flow. I have used distillery but I find myself going down a pretty big rabbit hole just to release something which in most languages is pretty simple. I will look at it again.
Releases and deployments with Elixir are still the area that needs most work, but it's nothing that would ever prevent me from using it. I have several in production and once we figured it out, it was easy peasy from there on.
We have some on DO and some on Heroku for clients. Both work well enough.
Re: Why Elixir (2014)
#33Earlier 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 would argue there are more developers interested in Elixir than there are jobs available. I would also argue that any developer worth paying, is a developer than can get up & running with a new syntax in a short period of time.
Re: Why Elixir (2014)
#34Earlier 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…
what about costs of running the application? You're not taking that into account.. I can run my elixir app far cheaper than you can a ruby app for instance. This means I can charge less than my competitors and offer more to my customers.
Re: Why Elixir (2014)
#35I 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…
> The error messages. Holy hell. What actually caused a pattern match to not work? what is it expecting?
Elixir 1.5 has introduced improved messages for pattern matching errors in function clauses: https://github.com/elixir-lang/elixir/blob/v1.5/CHANGELOG.md...
Re: Why Elixir (2014)
#36Earlier quoted context omitted.
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 li…
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.
Re: Why Elixir (2014)
#37I 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…
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?
This might help: from the release notes to Erlang R20 (i.e. latest):
A new event manager to handle a subset of OS signals in Erlang
It's documented in the docs for kernel here:
http://erlang.org/documentation/doc-9.0-rc2/lib/kernel-5.3/d...
You can write your own handler, which you'll install using gen_event (or :gen_event in Elixir), but even if you don't, there's a default handler which handles 3 signals, SIGUSER1, SIGQUIT and SIGTERM.
Per the link above, SIGTERM is handled like so:
The default handler will terminate Erlang normally. This is equivalent to calling init:stop().
Also worth a look, to see how os:set_signal/2 works (this allows you to decide which signals should be ignored, handled by the default handler or handled by your own handler):
http://erlang.org/documentation/doc-9.0-rc2/lib/kernel-5.3/d...
(And a shout out to legoscia on Stack Overflow for letting us know this might be available:
Re: Why Elixir (2014)
#38I started learning Erlang a few months ago and after spending a week with the online class at Future Learn [0] I can understand why some people say Erlang is more readable than Elixir. I know if you're coming form Ruby world, Erlang almost feels second nature. However, for people coming from other languages, I recommend looking into Erlang as well. It's more expressive, IMHO. [0] https://www.futurelearn.com/courses
>I know if you're coming form Ruby world, Erlang almost feels second nature. I'll assume you meant "Elixir", and seriously I hope people will give up on this myth really soon. Yes, the syntax kind of look like Ruby, but the platform is nothing like it. I'm actually very scared for Elixir to see so many Ruby developers moving to it, thinking that it's just "fast Ruby". They may bring all their Ruby habits with them an…
If they just want "fast Ruby", then they should move to Crystal instead. Elixir as a language is a lot different than Ruby, in addition to the platform it runs on.
Re: Why Elixir (2014)
#39Earlier quoted context omitted.
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 would argue there are more developers interested in Elixir than there are jobs available. I would also argue that any developer worth paying, is a developer than can get up & running with a new syntax in a short period of time.
Indeed, I work in many languages with many frameworks, and if my CTO decided that we were going to use Elixir then I would happily start using it.
For me personally though, I can't see any advantages of using it over a JVM stack.
Re: Why Elixir (2014)
#40Earlier quoted context omitted.
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…
what about costs of running the application? You're not taking that into account.. I can run my elixir app far cheaper than you can a ruby app for instance. This means I can charge less than my competitors and offer more to my customers.
Sure I am, for a personal project, of which I have a couple, a $5 per month Digital Ocean droplet can run pretty much anything I will ever write.
Professionally my company uses AWS, and I will concede that you might make a small saving using a few less EC2 instances.
Edit: This is on a JVM (Tomcat) stack by the way, not Ruby.