Elixir for Ruby developers: the three most important differences
phoenixonrails.com
Elixir for Ruby developers: the three most important differences
1–10 of 78 posts
Re: Elixir for Ruby developers: the three most important differences
#2What kinds of cool things are people doing with Elixir these days, where they feel it's a really good fit for the problem domain?
Re: Elixir for Ruby developers: the three most important differences
#3I must have missed where they discuss the type system. They go to great length to explain that there aren’t classes, methods, etc. and showcase modules such as String, but it’s not clear to me how you know what can be passed to String.whatever.
Re: Elixir for Ruby developers: the three most important differences
#4What kinds of cool things are people doing with Elixir these days, where they feel it's a really good fit for the problem domain?
Anything soft real time is a great fit. We push data to clients every 3 minutes or when specific events arrive. It was super easy to build with out of the box tools and just works.
Re: Elixir for Ruby developers: the three most important differences
#5I love Elixir, Phoenix and LiveView. A drawback is the size of the community, and as a function of that, availability of libraries for various things. It is not bad. It is also not great. That said, the community itself deserves high marks for their willingness to help and do so in a friendly manner.
Re: Elixir for Ruby developers: the three most important differences
#6I must have missed where they discuss the type system. They go to great length to explain that there aren’t classes, methods, etc. and showcase modules such as String, but it’s not clear to me how you know what can be passed to String.whatever.
The basic data types work with modules of the same name generally. String module functions work on UTF8 but strings. If you aren’t sure you can run the h() function in an ice shell on the module and function, e.g. h Kernel.+ or whatever.
Re: Elixir for Ruby developers: the three most important differences
#7I must have missed where they discuss the type system. They go to great length to explain that there aren’t classes, methods, etc. and showcase modules such as String, but it’s not clear to me how you know what can be passed to String.whatever.
Elixir doesn't currently have a type system built into the compiler. There is a separate package Dialyzer which does type checking but it would be fair to characterise it as a bolt-on rather than part of the core tooling. Work is now underway[1] to create a type system based on "set-theoretic types" though this is still considered experimental and may never be added to Elixir.
[1] https://elixir-lang.org/blog/2022/10/05/my-future-with-elixi...
Re: Elixir for Ruby developers: the three most important differences
#8What kinds of cool things are people doing with Elixir these days, where they feel it's a really good fit for the problem domain?
It's particularly good when you have concurrent users. Also, if you just have a web app that won't need other clients then LiveView gives you SPA-style development without the need to write a web-API layer.
Personally, I use it for any web app I'm making. It's a very simple language at its core and is just as good for tiny things as it is for large ones.
Re: Elixir for Ruby developers: the three most important differences
#9I must have missed where they discuss the type system. They go to great length to explain that there aren’t classes, methods, etc. and showcase modules such as String, but it’s not clear to me how you know what can be passed to String.whatever.
I imagine they expect that if you’ll be using Elixir at any capacity, you’ll have the docs in front of you, which details all the functions available in the modules, as well as the parameters they expect.
Re: Elixir for Ruby developers: the three most important differences
#10What kinds of cool things are people doing with Elixir these days, where they feel it's a really good fit for the problem domain?
It's particularly good when you have concurrent users. Also, if you just have a web app that won't need other clients then LiveView gives you SPA-style development without the need to write a web-API layer. Personally, I use it for any web app I'm making. It's a very simple language at its core and is just as good for tiny things as it is for large ones.
I know a lot about what the BEAM is good for, I'm curious about actual things people are doing with it.
The last time I used it seriously, we used Erlang as the high level language for these: https://www.icare-world.com/us/product/icare-eidon/ and it was a great fit for that kind of semi-embedded environment.