This seems to be the dominant use case for Elixir; migrate legacy Rails code to Elixir. When deciding between Go and Elixir for our startup I looked at both ecosystems. Go was significantly ahead in all categories: traction, articles on the web, packages on git, git activity, editor support ... I don't regret choosing Go but I always keep an eye out on Elixir. Pattern matching, pipe operator, immutability, supervisors ... I can only dream about that in Go.
I LOVE the pattern-matching/deconstruction/guards stuff. It eliminates SO much boilerplate logic. Just the function head of an Elixir function eliminates a dozen input validation and assignment lines in most other languages. It wouldn't be nearly as spectacular if it didn't pervade the entire language, though (for example, I'm sure you could get partway there in many other languages using a DSL)
Same thing with immutability. If it doesn't pervade the entire language, it feels slapped-on, and you basically lose most (all?) of the guarantees (like removing an entire class of bugs caused by mutability).
I saw what you saw in Go, but in doing my homework, I also saw an astonishing amount of ugliness[1][2][3], and additionally I took a bit of actual offense to the core philosophy of Go's design as stated by Rob Pike himself[4][5] so I am betting on (hoping for?) spectacular Elixir adoption I guess lol, as my current and all future projects for the foreseeable future will be in Elixir.
About the only wart I've seen so far in Elixir is the pin operator[6], but that was necessary to preserve the name-rebinding ability in a pattern-matching context, and it stops seeming like a wart fairly quickly, once you realize why it's necessary.
>About the only wart I've seen so far in Elixir is the pin operator[6], but that was necessary to preserve the name-rebinding ability in a pattern-matching context, and it stops seeming like a wart fairly quickly, once you realize why it's necessary.
I'm interested in hearing more on this, because I find elixir's pattern matching phenomenal. Fully embracing it feels like such a paradigm shift, and along with the rest of elixir it feels like I'm learning programming all over again (and I've been doing this for over a decade). I love it.
Back to the pin operator - the syntax is very light, and it's conceptually simple. As you said it's a natural consequence of pattern-matching. I'm not trying to start bikeshedding here, just wondering if there are some other problems or perspectives with the pin operator I'm not aware of. Thanks.
> I LOVE the pattern-matching/deconstruction/guards stuff. It eliminates SO much boilerplate logic.
I recently ported some simple plaintext operational transform code to Go and Swift to compare the languages, and this is so true. A lack of parameterised enums and a decent match block resulted in the Go code being about 50% larger than the swift equivalent. And the extra size bought me nothing! I find the Go code to be less readable and it had more bugs out of the gate.
Its a shame too, because I adore Go's concurrency features and APIs. Server side swift seems barbaric, and I lust over Go's scheduler and networking APIs.
Maybe its time to give Elixir a try. It sounds like it might be at a nice sweet spot of modern language features, concurrency and a mature ecosystem.
(NB: I'm new at both languages. A more experienced Go programmer might write that code differently. I don't find myself wondering that with Swift because its much more idiomatic.)
Go doesn't quite have the right level of abstraction for building CRUD apps. In particular, working with relational databases is very manual. Even using things like sqlx.
For an improvement of 2 orders of magnitude while maintaining the same level of developer complexity, I'm hard pressed to think of any other web framework besides Phoenix that can deliver this.
Java and C# easily outclass Phoenix i performances, if only because they are statically typed, but also because they run on VM's that are more advanced (and admittedly older, so more optimized) than BEAM.
Java and C# outclass performance in raw CPU work certainly. Phoenix does not do raw CPU work however, it is primarily a web dispatcher on top of cowboy and the BEAM will run circles around both Java and C# systems if they are programmed to anywhere near the same quality of failure handling that the BEAM implicitly supplies (/me has worked with both Java and the BEAM for over 10 years).
Also, the Erlang VM is older than the JVM, initially created in the late 1980's. The JVM, according to wikipedia, was introduced in 1994. Also the BEAM has significantly better GC handling that both the JVM and .NET both since it has a segmented memory model (each actor has segmented memory) unlike the JVM and .NET's monolithic Heap's, this allows it to perform vast optimizations that ensure that the GC is almost never called yet memory is properly and fully reclaimed due to the bounds of the individual Actor heaps, and even when the GC is called it does not stop-the-world or anything of the sort and has multiple layers of GC's that run for specific cases, the system stays running even as the GC's (rarely) runs. The average GC run time even when it does run is measured in the single-digit 'micro'seconds. If anything the BEAM VM is not only just much older than the JVM and .NET VM's, but also more advanced.
Java and C# incur more much more developer complexity for web development than Phoenix.
And as the the sibling comment points out, raw CPU performance isn't the only measure of efficiency. The JVM loves to eat memory, and if you get 100x CPU efficiency but use 10x the RAM, you're still bounded on machine resource usage by that memory usage.