Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elixir for Ruby developers: the three most important differences

phoenixonrails.com

Post reply on HN
Print view View original

21–30 of 78 posts

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

#21

Post by barkerja »

POiNTx wrote: post #11
davidw wrote: 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.

How's the svelte + LiveView integration been working out for you thus far? I still find a lot of issue with trying to do a bit of work in JS-land for things where I want to have no latency, but find it can sometimes be a challenge managing everything through various LV hooks.

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

#22

Post by POiNTx »

barkerja wrote: post #21
POiNTx wrote: post #11

Earlier quoted context omitted.

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.

How's the svelte + LiveView integration been working out for you thus far? I still find a lot of issue with trying to do a bit of work in JS-land for things where I want to have no latency, but find it can sometimes be a challenge managing everything through various LV hooks.

I'm biased since I made LiveSvelte, but it works quite well! I made a video to showcase some of its features here: https://www.youtube.com/watch?v=JMkvbW35QvA

Working with it in a real project now, instead of toy examples like in the video, it works really well for when you have highly complex components that rely on quite a lot of local state.

What you'll find is the developer experience is quite nice with LiveSvelte compared to JS hooks.

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

#23

Post by pavel_lishin »

ollysb wrote: post #7
mberning wrote: post #3

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

My experience with Dialyzer wasn't great a few years ago. The error messages are often counter-intuitive, to the point where hating dialyzer became a meme at work.

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

#24

Post by barkerja »

POiNTx wrote: post #22
barkerja wrote: post #21

Earlier quoted context omitted.

How's the svelte + LiveView integration been working out for you thus far? I still find a lot of issue with trying to do a bit of work in JS-land for things where I want to have no latency, but find it can sometimes be a challenge managing everything through various LV hooks.

I'm biased since I made LiveSvelte, but it works quite well! I made a video to showcase some of its features here: https://www.youtube.com/watch?v=JMkvbW35QvA Working with it in a real project now, instead of toy examples like in the video, it works really well for when you have highly complex components that rely on quite a lot of local state. What you'll find is the developer experience is quite nice with LiveSvelt…

Thank you for your contribution and for this video! Going to give this a try in the near future.

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

#26

Post by manmal »

sodapopcan wrote: post #19
el_nahual wrote: post #18

Earlier quoted context omitted.

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.

As a convenient side effect, GPT-4 is actually quite good at coding in Elixir. I tasked it once to find a bug in an Ecto query and it even improved the query‘s structure. I‘d been worried that, as a small-ish language, Elixir would suffer from bad LLM support, but that’s not the case.

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

#27

Post by fxn »

The article section about interpreted vs compiled is incorrect.

.exs files are compiled just like .ex files are. The only difference between `elixirc` and `elixir` is that the former creates an artifact on disk, and the latter does not. See https://medium.com/@fxn/how-does-elixir-compile-execute-code....

Also, Ruby is as compiled as Elixir is.

Compiled vs interpreted is blurred the moment you compile to bytecode run by a VM. An artifact is not a fundamental difference.

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

#29

Post by robinbobbin »

melx wrote: post #25
Mizza wrote: post #17

I wrote a similar article for Pythonistas: https://joyyo.app/elixir-for-humans-who-know-python

Nothing personal but I hate blog posts without a date of publication of said post.

Same here. And maybe mention the versions of the languages at the moment the article is written. Some of them add/remove features with each release.
Post reply on HN