Live data from Hacker News

Elixir for Ruby developers: the three most important differences

phoenixonrails.com

51–60 of 78 posts

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

#51
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 use Elixir as the backend for a lot of services that need reliability and performance in healthcare specifically on the pharmacy side. One such use case is pricing medications at the point of prescribing to enable conversations between a provider and a patient.

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

#52
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…

Too late to edit this comment, but as evidence: at time of writing this, the top comment has a very thoughtful reply by...Jose Valim (creator of the language).

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

#53
post #31

Earlier quoted context omitted.

Looking at archive.org it could be from today https://web.archive.org/web/20230000000000*/https://phoenixo...

There's a date at the bottom of the page.

I don’t see one?

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

#54
post #28

I would give seasoned Ruby engineers a lot more credit than this article expects. A lot of its examples are just…functions? A lot of the things that are ‘elixir’ are what I learned when I was writing PHP and modding forums.

A lot of Rails developers don't actually know Ruby.

Well a lot of developers think Rails is a programming language. :shrug:

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

#55
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?

Just wrapped up a live translation feature that watches an HLS live stream, live transcribes with whisper and then translates into 18 languages. Heavy use of OTP: supervision trees for each stream, ports for managing ffmpeg and receiving audio, async tasks for concurrently submitting chunks to translation API, etc. Transcription and translations provided in real-time via LiveView to about 4,000 viewers. Little over 3…

That's really cool. Managing ports is something I've done in elixir yet, but managing ffmpeg through elixir could be very useful for a few things in my current area of focus.

Can you share any details of how that works? E.g. do you operate on a single HLS chunk at a time, or can you get ffmpeg to separate a continuous audio stream, etc?

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

#56
this is missing the big one:

@ does not work at all the same way in ruby vs elixir, it's not even close

I would probably also put in

"Please for the love of God don't try to turn a genserver into an object"

Because many ruby programmers will try.

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

#57
post #53

Earlier quoted context omitted.

There's a date at the bottom of the page.

I don’t see one?

> Last updated • Jul 23, 2023

after the Learn Phoenix Fast red box.

However the convention is to put dates at the beginning of an article. Readers shouldn't have to make an effort to look for them.

This reminds me when I had to look for how to check for inequality in Lua after I wrote != and it didn't work. didn't work too.

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

#58
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.

It's indeed relatively small, but what it may lack in numbers, it makes up for in quality. It's one of the most dedicated, helpful, and friendly communities I've come across.

I've personally been surprised by a pro of having a more intimate community: in my experience, this leads to a higher signal-to-noise ratio in discussions and resources. It feels like what I need to get online is more "condensed".

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

#59
post #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.

This is quite cool. Can it enable optimistic UI updates?

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

#60
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?

Wrote the basics of a MMO emulator for metin2 in it with horde for multi node Game Server distribution (per map a process) and ranch for connection pooling, basic stuff like login and walking around, and having monsters spawn (it's a hack n slash MMO) multiplayer and PvE combat works, stopped at that point to further develop it deeper, since I kept musing about to advanced feature wishes like behavior trees for monsters /bosses

Elixir felt all around like s perfect fit for it , apart that some faster deep mutations likely would have been had to be ported to rust or c because the way I wrote it having 250 players on a single map walking around and seeing each other close by caused huge latency but no crashes Scaled well across multiple machines and lots of players as long as they did not all bog down the same map process :) Didn't even had to think s lot about how I structured it for the current state of development it was basic rapid iteration with mostly live recompilation on changes without having to restart anything https://gitlab.com/zen_core/zen_core

Post reply on HN