Live data from Hacker News

Elixir for Ruby developers: the three most important differences

phoenixonrails.com

11–20 of 78 posts

Re: Elixir for Ruby developers: the three most important differences

#11
post #2

What kinds of cool things are people doing with Elixir these days, where they feel it's a really good fit for the problem domain?

I'm building a multiplayer real time web based game (io style, 2 ticks per second, so not 64 like a true realtime game). It seems to work quite well so far. I'm using https://github.com/woutdp/live_svelte for the frontend with pixi.js for the rendering.

Re: Elixir for Ruby developers: the three most important differences

#12
post #2

What kinds of cool things are people doing with Elixir these days, where they feel it's a really good fit for the problem domain?

We built a social network for social justice work, with posts, likes, shares, and the like. Elixir and Phoenix are a really good fit for the problem domain i.e. lots of concurrent users, high scalability via built-in balancing and queuing, the "let it crash" concept for lots of backend APIs such as image processors that sometimes fail. And LiveView is superb for fast interactivity.

Re: Elixir for Ruby developers: the three most important differences

#13
post #10

Earlier quoted context omitted.

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.

Ah, well, personally I'm not doing anything other than web apps.

A slightly cool thing its enabled is that I have a monolith with a single microservice. All the microservice does is process messages from the main app to process images, upload them to S3, then notify back when it's done. The cool thing is that they can be run on two separate connected BEAM instances communicating via the built-in message passing with no need for an HTTP API. I haven't deployed this, yet, though.

Maybe that's still not what you're looking for but I was really happy when I figured out I could do that :D

Re: Elixir for Ruby developers: the three most important differences

#14
post #10

Earlier quoted context omitted.

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.

There's Nerves for semi-embedded.

https://nerves-project.org/

Re: Elixir for Ruby developers: the three most important differences

#15
post #2

What kinds of cool things are people doing with Elixir these days, where they feel it's a really good fit for the problem domain?

I built a real-time updating internal test bed reservation system for the company I am employed by. It’s mostly a LiveView app with some external modules and js hooks scattered throughout.

Re: Elixir for Ruby developers: the three most important differences

#16
post #2

What 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 with concurrency or where you'd normally use LiveSockets, but man, I like using it for everything.

Re: Elixir for Ruby developers: the three most important differences

#18
post #5

I 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.

The community is small, but that means that a reasonable question on elixirforums (not a stateless discord/slack, pun intended) has a good chance of:

1. receiving an answer from a core contributor (valim, McCord, etc)

2. Having the answer become part of the documentation for the language or library

As an aside, the elixir community has a different didactic approach to many others: the documentation in elixir is genuinely instructive (vs a descriptive reference).

As an example, I've been able to download the elixir, Phoenix, and ecto docs and work on an app entirely offline, on an airplane ride, and never felt like I needed to Google anything.

A common elixir answer to "where are all the blog posts" is "read the docs. No, seriously."

Re: Elixir for Ruby developers: the three most important differences

#19
post #5

I 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.

The community is small, but that means that a reasonable question on elixirforums (not a stateless discord/slack, pun intended) has a good chance of: 1. receiving an answer from a core contributor (valim, McCord, etc) 2. Having the answer become part of the documentation for the language or library As an aside, the elixir community has a different didactic approach to many others: the documentation in elixir is genui…

> A common elixir answer to "where are all the blog posts" is "read the docs. No, seriously."

This is indeed very common the forums, ha. Also common is for people to actually then go read the docs and be like, "Oh crazy, I'm not used to this!" Not to over-sell the quality of the docs, of course they aren't perfect but they really are particularly good.

Post reply on HN