Question to the former Rails devs out there:
We mostly see threads fawn over Elixir and Phoenix, have you experienced any downsides to switching? Anything you miss from Rails?
I'm convinced to give it a try after that demo!
We mostly see threads fawn over Elixir and Phoenix, have you experienced any downsides to switching? Anything you miss from Rails?
I'm convinced to give it a try after that demo!
Some other things to consider are that Go's concurrency model is quite bloated when compared to Elixir's, Go uses public memory for its goroutines vs. Elixir's private memory that protects processes, Go uses cooperative multitasking vs. Elixir's preemptive model, and Go's dependency handling is absolute rubbish. Elixir's process supervision is amazing and Elixir's pattern-matching allows you to write easier-to-read and more maintainable code, in my opinion.
While both are good languages, I've personally found Elixir > Go.
I'm currently planning a SaaS project and had settled on go, but this discussion is making me wonder if perhaps Elixir is the better choice.
OPT, which is how you build supervision trees and other more complex Elixery things, is tricky at first but reading through Designing Elixir Systems with OTP, by James Edward Gray & Bruce A. Tate, and The Little Elixir & OTP Guidebook, by Benjamin Tan Wei Hao should clear it up fairly well.
This is highly subjective, of course, but I've written code in C, C++, Pascal, Basic, Python, Perl, Ruby, JavaScript, Go, PHP, Java, C#, Clojure, Scheme, Cobol, and Pick Basic (of all things). Elixir has been my most favorite language so far.
My anecdotal view of the marketplace is that Elixir recruitment emails tend to come from startups looking for their 2nd or 3rd dev, usually full stack, and the salaries are nothing special. Go recruitment emails tend to come from bigger companies looking for backend devs, often hoping for kubernetes experience too, and the pay is higher.
I built an internal service with LiveView at work and I loved it. I gave a presentation about how it all works and was hoping it would catch on. It didn’t. The front end team would probably mutiny if we told them to give up React and level up their LiveView skills.
If I were running a web business as a solo founder I would 100% want to use LiveView. As a dev on a larger team that already has specialization it’s a tougher sell.
You shouldn't really compare it to React, you should compare it to your whole stack, and see how a lot of the code and the worries just kind of go away.
This is much like how it used to be with classic server-side rendered Rails/PHP/Phoenix... except with LiveView you can update part of the page running on the client, in response to events coming from the client without a page refresh.
To someone who uses Rails/Django with React, I'd describe LiveView as something that offers pretty much everything you're used to, but with the React part consolidated with the server-side of things.
I've been playing around with LiveView since it came out, and have been using it for 'serious' work for the past year or so, and I still regularly discover ways in which this setup simplifies things, makes development faster and more fun, and saves me from various potential security flaws or 'busiwork'.
Imagine that your store (Redux, whatever) and view (React) ran in the same place as your backend.
Direct access to the database and the rest of the backend, no need to carefully consider whether it's really worth it to increase your js payload with library x, no constant context switching, no building and maintaining of, essentially, two completely separate applications, no need to make sure your API endpoints are properly versioned, or that they don't expose data that shouldn't be exposed, or that they send only the data you need. Little to no need for rube-goldberg js pipelines, and significant less time spent dealing with synchronizing state between server and client.
I'm probably forgetting some other advantages.
There are some things where LiveView doesn't seem ideal, but I've found that even in those cases I prefer using LiveView wherever I can anyways, and then I do the specific javascripty bits wherever I need them.