Longtime Rubyist here that has worked with Elixir. It is only loosely based on Ruby's syntax - there is a _lot_ more punctuation in Elixir. Also much more explicit passing of parameters, including database connections and error handlers in the case of a Phoenix application. It's also a challenge to deploy OTP along other non-hypervised runtimes. BEAM and Elixir are very cool, don't get me wrong, but after some programming web services in Elixir I was ready to head back to Ruby. If I need a highly fault tolerant near realtime comms system, I'll look at Elixir, otherwise I avoid.
Switching to Elixir
11–20 of 283 posts
Re: Switching to Elixir
#12How do people switch programming languages? Established languages have massive ecosystems. Large set of libraries. For example, I cannot give up MS Entity Framework Core or Hot Chocolate graphql server for C#. Sure, there are alternatives, but nothing as feature complete. Perhaps it is possible for applications that have small set of requirements.
> Perhaps it is possible for applications that have small set of requirements.
Well, for existing applications it is extremely difficult, not because Elixir lacks many important features that C# delivers (although I'm sure it does lack some, and vice versa in a big way), but more just because rebuilding any project that's had hundreds or thousands of person-hours poured into it, that's currently satisfying hundreds or thousands of business requirements which may or may not be documented, is a huge project with few rewards; the investment is huge and the return on investment is... I mean, being on {sexy new language} is nice, but nobody's paying you for that.
But that's not what the OP's job is talking about. They just got a different job using Elixir, and are learning the technologies the same way anyone else does, and they're excited about this instance of it enough to write about it.
Re: Switching to Elixir
#13Longtime Rubyist here that has worked with Elixir. It is only loosely based on Ruby's syntax - there is a _lot_ more punctuation in Elixir. Also much more explicit passing of parameters, including database connections and error handlers in the case of a Phoenix application. It's also a challenge to deploy OTP along other non-hypervised runtimes. BEAM and Elixir are very cool, don't get me wrong, but after some progra…
> It's also a challenge to deploy OTP along other non-hypervised runtimes.
Pardon?
Re: Switching to Elixir
#14For me the big sell of Elixir/Erlang is that it makes running "background jobs" a complete breeze with no concern for blocking IO bringing the entire server to a halt, especially in a web server context.
At my last job I had to do a bunch of HTTP requests in a webhook handler and if enough happened at once, the entire site would just crash due to all the OS processes being busy. I found myself desperately wishing I was just using Elixir instead because it would have been trivial to just spin up a Task to do it and move on.
Re: Switching to Elixir
#15How do people switch programming languages? Established languages have massive ecosystems. Large set of libraries. For example, I cannot give up MS Entity Framework Core or Hot Chocolate graphql server for C#. Sure, there are alternatives, but nothing as feature complete. Perhaps it is possible for applications that have small set of requirements.
I used C# before using Elixir. I also thought Entity was awesome. But Ecto and Absinthe are even better from my perspective.
Re: Switching to Elixir
#16Which companies have used Elixir in production, I know Brex used to use Elixir but now used Kotlin and also the Bleacher Report.
Are there any more?
Re: Switching to Elixir
#17For me the big sell of Elixir/Erlang is that it makes running "background jobs" a complete breeze with no concern for blocking IO bringing the entire server to a halt, especially in a web server context. At my last job I had to do a bunch of HTTP requests in a webhook handler and if enough happened at once, the entire site would just crash due to all the OS processes being busy. I found myself desperately wishing I w…
We recently switched from Rust to Elixir on a new service in no small part to this. The idea of sharing objects through Tokio async processes felt difficult compared to this being a first class feature of Elixir. It’s not that it’s hard, per se, but it felt harder to get right.
Re: Switching to Elixir
#18`...If you call model.update(params) in Ruby, then it returns false if it fails and updates model.errors with what went wrong. Mutable state.` This is Rails stuff, not Ruby
True, you could implement Ecto exactly in Ruby, except you'd be writing effectively Elixir and every library released that got close to this in the 15 years I've been doing Ruby has been either disliked or disregarded. Each with less contributor activity in their lifespan than a month of ActiveRecord attention.
Re: Switching to Elixir
#19Coming from F# and only dabbled in Elixir, I find the language unfortunately a bit confusing. For instance, the signature of a function only reveals the name and number of the parameters but not type, so in a big library, it’s quite hard to recognize (mentally) what goes into what and one can only see one plugged the wrong parameters after one had ran and debugged the code. In strict-type language like F#, such issues would be detected right away during coding, thus it helps to reduce the time and effort immensely.
So my question is what are the main selling points of Elixir besides the Erlang environment?
Re: Switching to Elixir
#20Longtime Rubyist here that has worked with Elixir. It is only loosely based on Ruby's syntax - there is a _lot_ more punctuation in Elixir. Also much more explicit passing of parameters, including database connections and error handlers in the case of a Phoenix application. It's also a challenge to deploy OTP along other non-hypervised runtimes. BEAM and Elixir are very cool, don't get me wrong, but after some progra…
> It's also a challenge to deploy OTP along other non-hypervised runtimes. Pardon?
This part stumped me too. Maybe op had some deployment issues on VM systems.