[HN Gopher] Elixir for Ruby developers: the three most important...
___________________________________________________________________
Elixir for Ruby developers: the three most important differences
Author : arrowsmith
Score : 123 points
Date : 2023-07-23 15:29 UTC (7 hours ago)
(HTM) web link (phoenixonrails.com)
(TXT) w3m dump (phoenixonrails.com)
| davidw wrote:
| 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?
| jph wrote:
| 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.
| ch4s3 wrote:
| 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.
| wturner wrote:
| 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.
| davydog187 wrote:
| I'm building a product in the media world. Elixir powers our
| webserver, that's connected to NVIDIA Jetson devices, all using
| elixir for coordination and talking over UART to serial
| components. We also plan to do vision and ML workloads in the
| applications in the near future
| sodapopcan wrote:
| 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.
| davidw wrote:
| 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.
| sodapopcan wrote:
| 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
| conradfr wrote:
| There's Nerves for semi-embedded.
|
| https://nerves-project.org/
| Mizza wrote:
| Anything with concurrency or where you'd normally use
| LiveSockets, but man, I like using it for everything.
| ricketycricket wrote:
| 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 weeks from `mix new` to the live event. Not sure
| how I could have done it so easily without OTP and LiveView.
| POiNTx wrote:
| 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.
| barkerja wrote:
| 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.
| POiNTx wrote:
| 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.
| barkerja wrote:
| Thank you for your contribution and for this video! Going
| to give this a try in the near future.
| [deleted]
| tensakai wrote:
| I love Elixir and I have worked with it in past 2 years.
| (Specially in China)
|
| But I have been free because the company was broken. I really
| want to keep writing Elixir, are there any remote job
| opportunities here?
|
| P.S. I also have some experience of React/Nextjs, Ruby and Scala.
| mberning wrote:
| 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.
| ch4s3 wrote:
| 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.
| ollysb wrote:
| 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...
| pavel_lishin wrote:
| 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.
| biql wrote:
| Trying Gleam that also runs on Erlang VM but has static
| types, a fast compiler with Rust-style elaborate error
| messages made me hopeful about how much nicer this
| experience can be when static types are added to Elixir
| too.
| totallymike wrote:
| 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.
|
| https://hexdocs.pm/elixir/1.15.4/String.html
| ljm wrote:
| 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.
| mrcwinn wrote:
| 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.
| pmontra wrote:
| I worked on a Phoenix project for a few years. We had to write
| our own libraries to access some services from Google and
| Stripe which have libraries for other languages but it was not
| difficult. We have to implement only the few HTTP calls we need
| and we can choose the functions that suit our application
| instead of learning somebody's else tool.
| arrowsmith wrote:
| GPT-4 is excellent at this - give it code from an existing
| SDK in Ruby (or whatever) and tell it to rewrite the
| functions you need in Elixir and it'll get you at least 90%
| of the way there.
|
| The other day I used this to create an Elixir wrapper around,
| appropriately enough, the OpenAI API.
| cpursley wrote:
| It's also great at "here are the so and so docs, write an
| adapter for Elixir"
| sbuttgereit wrote:
| I am writing a lot of the code that might be found in
| libraries for my project; I'm doing it mostly because: third
| party, open source libraries really need to be treated as
| hostile code until they're vetted... and then will continue
| to need vetting with every update. For a fair number of uses
| cases, writing the library is less than or as labor intensive
| as a good audit and writing them in Elixir tends to be pretty
| simple. For the larger more complex and essential libraries,
| there are solid, fairly well endorsed packages out there
| (they still need vetting though).
|
| Of course, there's the option of taking an appropriately
| licensed open source license and making an internal fork...
| not expecting to really receive updates from upstream after
| the point of departure.
| el_nahual wrote:
| 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."
| sodapopcan wrote:
| > 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.
| manmal wrote:
| 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.
| enraged_camel wrote:
| My experience has been the total opposite. It can give
| simple answers but makes up total nonsense for anything
| non-trivial.
|
| That said, with Ecto I just ask it to give me the SQL
| query. From there it's pretty easy to manually write the
| Ecto equivalent.
| manmal wrote:
| That was right after the release of GPT-4, when it was
| slow but good. Haven't gotten around to much Elixir
| coding since, it could be that they crippled GPT-4 too
| much to be of use in the meantime.
|
| Oh and the chat is better for me than the API. API
| sometimes gives me the complete opposite of what the chat
| (correctly) gives me.
| arrowsmith wrote:
| Are you using GPT-4 (the paid version) or GPT 3.5?
|
| 3.5 is as you describe. 4 isn't perfect but it's good
| enough, in my experience.
| fxn wrote:
| 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.
| josevalim wrote:
| To add to your excellent points: Elixir is compiled ahead of
| time while Ruby bytecode is generated as the code is loaded,
| which is probably the source of confusion in this case.
|
| This leads to differences such as Ruby meta-programming
| happening at runtime, Elixir's at compile time. The Elixir
| compiler (the Erlang compiler really) can also afford to do
| more work at compile-time which then leads to different
| approaches at the JIT level too.
| atonse wrote:
| This is a good point because in elixir metaprogramming you can
| actually have some things happen at compile time. The
| frameworks use this for performance in a few places.
|
| So if you had different behavior for ex and exs that would
| cause developer confusion.
| benatkin wrote:
| Yeah, if you don't want the code to run when you're compiling
| it, don't have it do anything until some function is called.
|
| And it would be the same as in another language if you run a
| program that has no side effects. For instance "python
| abc.py" will gladly run a abc.py that is empty or has "class
| ABC: pass" in it.
| Mizza wrote:
| I wrote a similar article for Pythonistas:
| https://joyyo.app/elixir-for-humans-who-know-python
| melx wrote:
| Nothing personal but I hate blog posts without a date of
| publication of said post.
| robinbobbin wrote:
| 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.
| Mizza wrote:
| Ok.
| pmontra wrote:
| Looking at archive.org it could be from today
|
| https://web.archive.org/web/20230000000000*/https://phoenixo.
| ..
| arrowsmith wrote:
| There's a date at the bottom of the page.
| pmontra wrote:
| IMHO a more fundamental difference is that because of pattern
| matching and pipelines you'll write code in a very different way
| and any expectation that Elixir and Ruby are similar will
| evaporate before the end of the very first day.
|
| However many Class.method names in Ruby's standard library have a
| match as Module.function in Elixir, by design, to ease the
| migration of developers. Language developers take note, copy from
| the language you want to lure developers from.
___________________________________________________________________
(page generated 2023-07-23 23:00 UTC)