Elixir wouldn't exist without Ruby, so I have nothing but gratitude.
My question angles more toward learning functional programming first, and I doubt it'll ever happen at bootcamps (though - my understanding is that's exactly what happens at Berkeley/MIT with Lisp/Scheme in CS101 (I'd argue with decent results)) - so it's very much a hypothetical.
Is it decent results because of functional programming? Or decent results because those colleges select for the people who generally have the most intellectual aptitude and you could have them write Cobol on tape for CS101 and they'd still be great
Existing Elixir shops probably aren't looking for fresh bootcamp grad level coders, and those grads' skillsets don't hold any weight until there's enough to start affecting new project decisions, which probably wouldn't have happened. Even Ruby is a stretch as a one-trick skillset for new developers without CS degrees, and it was quite popular well before bootcamps were: that's why they taught it. I mean, I love me some Elixir, but the result is that most of the schools would have closed within months and the graduates would probably not have gained much from them.
Oh, I don't think there's a universal "better" when it comes to such things, and I'm not implying that one is universally better than the other.
I discovered the Elixir runtime (BEAM) a few years before Elixir was created (we were using the Erlang language then), and for my specific use cases, when I understood the principles of concurrency, error handling, and introspection in BEAM, it caused quite an epiphany. It was also scary, because I had to unlearn pretty much everything I knew :)
From a purely esthetic perspective, I find that pattern matching and tail recursion-enabled programming patterns are more concise, easier to comprehend, and are less error-prone than those offered by the more mainstream languages that don't have those features.
In my experience - and I'm not a particularly great programmer, so it was welcome - I found that I produced code with signifcantly fewer dumb errors when I no longer had access to imperative programming paradigms and was forced to come up with more "functional" solutions.
I don't believe that functional programming is inherently more complex than what we learn in school/college/work with conventional languages. My question really stems from the idea of learning functional first - and I do wonder what that would look like.
That's a fine perspective but the way you worded your comment was evocative of the typical "X is objectively better than Y" tech comment. Are you aware that Ruby includes a lot of functional programming features (including pattern matching)?
I think it’s great that functional programming is making its way into traditional imperative languages - even JavaScript (I recently came across https://gcanti.github.io/fp-ts/ as a pretty extreme example)
Elixir/Erlang has function-level pattern matching, which I really like. I’ve yet to see it anywhere else, though my understanding is it came from Prolog.
I worked at a ruby on rails startup and currently am 5 years into a stint as CTO and lead engineer of a startup using elixir.
Ruby shines where you need to just pull some off the shelf libraries and get something together. you save on developer time but your devops setup needs to be a bit more complicated to handle scaling issues which will come sooner. That said, ruby is a lovely language to work in for the most part.
Havign said that, I personally think elixir is the winner for reliability and maintainability. yes, there aren't as many libraries for elixir and they don't have the same level of "drop in and use" functionality that ruby has. elixir's ecosystem's whole approach is to make everythign standardized lego pieces so there's a little but more work up front.
Once you are actually writing your own code however, i find there's less bugs as immutable data structures eliminate whole classes of bugs you find in ruby. Its not as air tight as a fully typed language but I do get descent warnings at compile time to catch plenty of low hanging fruit when it comes to runtime errors. to be sure, you definitly have to think differently about how you code as you haev to think in a more functional style.
Of course elixir's real claim to fame is going to be a combination of concurrency and performance. elixir's metaprogramming happens at compile time and in my experience, elixir systems just run faster than the equvalent ruby code. at my startup, all scaling conversations end up being around pushing postgresql and optomizing our queries. We have yet to really hit the ceiling of our api server.
Ecto, phoenix's db library, is just a better abstraction for database interaction than activerecord. it doesn't try to shoehorn database queries into objects. database records map to elixir records and you write queries using a set of macros that map pretty cleanly to sql with easy escape hatches if you need to use soe nonstandard sql. The result is that we don't spend much time tryign to debug how a db query in elixir maps to the output sql. its easy to tell at a glance. of course this does require that you actually understand how sql works.
lastly, if you want to build anything on top of websockets. there's no comparison. elixir is just better. comparing ror to elixir in terms of websockets is like comparing a cesna to an f16.
> Once you are actually writing your own code however, i find there's less bugs as immutable data structures eliminate whole classes of bugs you find in ruby. Its not as air tight as a fully typed language but I do get descent warnings at compile time to catch plenty of low hanging fruit when it comes to runtime errors. to be sure, you definitly have to think differently about how you code as you haev to think in a more functional style.
This is my experience too - Elixir might not be statically typed, but it's not nearly as big of a problem as you'd think. Immutability, pattern matching, and the general functional style all give you some strong guardrails that avoid a lot of the usual pitfalls of a dynamic language. Plus you also get the benefits of dynamic typing too (flexibility, more succinct code, faster iteration time.)
Sure, it's not as foolproof as a full static type system, but it's good enough in my experience. It's not even close to the uber-fragile NoMethodError clusterfuck that is Ruby development.
Also, "lorry" is such a great word, too bad there's no use for it in the US.