I wrote a similar article for Pythonistas: https://joyyo.app/elixir-for-humans-who-know-python
I'm curious, what are the chances to python you don't like?
Elixir for Ruby developers: the three most important differences
61–70 of 78 posts
Re: Elixir for Ruby developers: the three most important differences
#62I 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.
No classes, but there are types. When looking at the docs (which you'll do often) you'll see the doc.
I say you'll be in the docs often because of things like
Enum.map which returns a List not a map
Enum.map_reduce takes either a List or a Map, but returns a List.
Kernel.get_in takes a Map and a List
Re: Elixir for Ruby developers: the three most important differences
#63Mostly the dev cycle in Elixir is different. There are no "binding.pry". We're back to putting logs in the code.
Re: Elixir for Ruby developers: the three most important differences
#64Mostly the dev cycle in Elixir is different. There are no "binding.pry". We're back to putting logs in the code.
Use `dbg` for prying. You can also use `break!` in an `iex` session to manually set breakpoints without modifying your source. Additionally, you can use Erlang’s `:debugger`for visual debugging, and `:observer` for understanding the entire VM when prying is not enough.
Re: Elixir for Ruby developers: the three most important differences
#65I 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…
The type system has moved from the research phase to in development: https://elixir-lang.org/blog/2023/06/22/type-system-updates-...
Re: Elixir for Ruby developers: the three most important differences
#66Earlier quoted context omitted.
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.
I’ve always found dialyzer errors to be quite straightforward and easy to understand—the challenge is finding where a poor typespec originates in a codebase (or dependency) with poor typespecs.
Re: Elixir for Ruby developers: the three most important differences
#67Earlier quoted context omitted.
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?
https://github.com/saleyn/erlexec is pretty good for handling external processes. The builtins aren't quite there if you have more complex use cases.
Re: Elixir for Ruby developers: the three most important differences
#68Earlier 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.
This is quite cool. Can it enable optimistic UI updates?
Yes :)
Re: Elixir for Ruby developers: the three most important differences
#69I 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.
Really???
Re: Elixir for Ruby developers: the three most important differences
#70Mostly the dev cycle in Elixir is different. There are no "binding.pry". We're back to putting logs in the code.
This is not nor has not ever been true.
Now, you've got `dbg()` and running whatever you're running via `iex -S `.
Prior to `dbg()` you had `IEx.pry()`.