I've certainly enjoyed Elixir as an nth programming language and the idea of Elixir as a 1st programming language is really interesting.
I know I've seen at least one educator in the community speculate that Elixir (or FP languages in general) could potentially make great 1st programming languages because they're often conceptually easier than OOP languages and in many ways the difficulties people associate with learning them come from the difficulty of unlearning some of the things they already know.
I have first hand experience with this actually...
Over the last 6 months or so a good friend of mine has learned to code from scratch. After much deliberation I took a gamble and set him up with Elixir as his first language (largely because he wanted to code so he can work with me on some projects, which use Elixir).
I am really happy with this choice and so is he. Elixir is a language with very consistent ideas throughout and I think concepts like functional transformations, immutability, pattern matching and actor based concurrency are both extremely useful to learn early and very accessible to beginners in Elixir.
Edit:
I didn't think of it when I wrote this comment, but I think the single most helpful thing for beginners (and me!) in Elixir, is the 'h' function. If you run it with any function as an argument in iex (Elixir's repl) you'll get documentation and an example of how to use that function:
iex(2)> h Enum.map
def map(enumerable, fun)
Returns a list where each item is the result of invoking fun on each
corresponding item of enumerable.
For maps, the function expects a key-value tuple.
## Examples
iex> Enum.map([1, 2, 3], fn(x) -> x * 2 end)
[2, 4, 6]
iex> Enum.map([a: 1, b: 2], fn({k, v}) -> {k, -v} end)
[a: -1, b: -2]
How does your friend deal with Processes, OTP, Supervision trees and so on?
I'm a huge Elixir fan, but always thought it would be a hard first language because of OTP, the benefits of which are kinda hard to appreciate without some experience making production software. Happy to be wrong on that though.
Having the example is really cool. I tend to provide examlme in docstrings for functions I personally write. Would be nice if core functions of other languages did too.
As does Clojure with doc. However, neither of these include examples as standard. Idiomatic docstrings tend to be a short string; one sentence or paragraph.
I find it an interesting idea too. I mentor people at Culture Amp in Ruby and Elixir and I'm definitely finding Elixir easier to teach for a couple of main reasons:
* It's Just Functions And Data™
* Inheritance isn't a thing
* Functions either come from within the same module if they don't have a module prefix
* Functions from other modules _must_ have a module prefix.
* Immutability, immutability, immutability.
It just _feels_ like there's less to learn with Elixir (foundational wise) than Ruby. It's been pretty nice.
* Inheritance isn't a thing, but behaviors and protocols are.
* Functions from other modules _must_ have a module prefix, except if the current module has `import` statements at the top or, worse, `use` statements which happen to run macros that in turn `import` stuff again. Phoenix does this with controllers, and it's a mess. A million unprefixed functions available and no clue where they come from. Also, you forgot about `Kernel`.
* Immutability, except when you inherit code that uses Agents all over (which is really just a Java Bean, a mutable object, or whatever you want to call it) and you lose it all again. Process state is mutable, and the smaller your processes are, the more your code starts to smell imperative.
In all honesty, if you add import, use, macros, behaviors and protocols to your list, then all in all there really is pretty much to learn. It's no C++, but I have a hard time calling Elixir simpler than Ruby.
Now, I think these are all good features (except Agents). They just make Elixir less simple, that's all.
I would say the difference is that you can start small. You can start thinking about functions and data and you can build a large amount of software with the simpler abstractions. I would say this is not specific to Elixir but to functional languages. A good amount of my code is just functions and data. Processes, macros, protocols, etc come only when strictly necessary.
When I went to university for CS, Haskell was used in the introductory programming courses and this was one of the main reasons we were told about.
Another goal was to take the people who had been learning to code in their spare time and put them on more even footing with those who were totally new, force them to think about things from first principles rather than lean on acquired habits, etc.
I had already been coding for a long time by that point but it was the first time I saw a functional language and I think it addressed both goals very well.
> Another goal was to take the people who had been learning to code in their spare time and put them on more even footing with those who were totally new
The thinking behind that is usually a bit fallacious, though.
Say the department has been teaching Java in the introductory programming course, and noticed that some people already know most concepts. Then they decide to use a different language to "level the playing field".
First of all, what kind of attitude is that? If some people already know the stuff, just let them take the exam without attending the course, so they can take "Advanced Programming Paradigms" or wherever FP is taught.
I can understand teaching FP first if you think it's conceptually easier, but counting prior experience of some students as a reason to restructure the curriculum for everyone is silly.
Second, using Haskell instead of Java isn't actually leveling the playing field. It just changes who has an advantage from game modders and people who coded their own website to the more mathy types (or people who learned Haskell in high school, like me), who will have an easier time with higher-order functions and the rigid formality of the type system.
When they announced in my OOP course that there'd be a few sessions on other paradigms, I was a bit disappointed to find out that this meant only a bit of Haskell and Prolog, when I'd already written a simple Prolog interpreter in Haskell. Should they have changed the curriculum just because of me? Definitely not.
It was a long while ago now, if you had learnt anything before you got there it was pretty much guaranteed that you'd seen either BASIC or C. :)
The internet wasn't what it is now either so most people who had done some coding before were indeed lacking in understanding of the fundamental principles of what they were doing – I know I certainly was. There may have been outliers yet beyond the "I've been playing with code" crew but I didn't meet any.
I'm not at all suggesting it would be good reasoning today, but I think it helps to show that the underlying idea that FP is a good way to introduce people to code whilst ensuring they develop a strong theoretical understanding was true then and should still be today.
I've actually been discussing this with a couple of people within the community. Been hacking with Elixir for a bit, and in an effort to teach it to people around me who've never programmed I've started compiling my notes into a book.
Would love to share it here in a bit when I have some time to finish things up and get some feedback.
I will say, writing from the perspective of it being one's first language is really interesting, because you just can't assume anything.
While I applaud creating documentation, books, and guides for those new to the language, there's still a significant accessibility gap in resources. I already know the language, I've already done some basic stuff in phoenix, I've even made my own HTTP API wrapper as its own library. But when it comes to architecting backend systems that aren't tied to phoenix or playing around with IEx, I really feel like I am on my own.
There are erlang books, of which I am reading, though it feels like there's always emphasis on history for backwards compatibility and the other warts that Erlang has with its age. I'd like to design reliable systems that operate outside of the classic HTTP -> Elixir -> Database pattern. Things that involve working in memory, processing queues, managing sessions and state, patterns for fallbacks and breakers for services, and so on, that is where I seek more content.
Unfortunately I hear the big BEAM player around, Basho, is shutting the lights--so I can't expect to witness the wonderful presentations their engineers provide at conferences or through recordings of such conferences.
I'm actually working on a book which I think covers a lot of what you're looking for (and was what I wanted back when I got started with Elixir a few years ago). I'm covering architectural patterns for the items you mentioned as well as flow control and digging in deep on how to really leverage the fault isolation mechanisms of OTP. I'm the maintainer of Distillery, the release tooling in Elixir, so I'm also covering a lot of the gritty details involved there, such as how to work with hot upgrades and such, as well as dealing with issues in production using some of the excellent operational tooling available.
Unfortunately I probably won't be done until the end of this month, but if you're interested, keep an eye out on ElixirForum.com, since I'll announce it there when it's available.
I hope you don't mind if I just copy my reply to Hates_: "I don't yet, as I've been pretty heads down. I'll put one together this week and reply back once it's up."
I feel that Erlang adoption is probably the most realistic growth path for most serious Elixir developers. All of these topics you mentioned (breakers, message routing, etc) have been discussed and developed in the Erlang community for years. The only new thing that Elixir brings to the table in these areas is abstraction and syntax - both of which are arguably not needed in large complex systems.
Source: full-time Erlang developer of 7 years who spent a full year coding Elixir in its v1.0.x days
Learning how the BEAM works and the architectural decisions that make sense for running your system on it is the realistic growth path for any serious BEAM developer. This has nothing to do with any of the languages on the BEAM, but with what makes sense on the VM.
Your assertion that abstraction is somehow not needed in "large complex systems" (this being completely undefinable, by the way) seems silly and I can refute it with about as many objective reasons as I suspect you have for making that comment. Our current code base would be significantly shorter if we used Elixir (on the order of 50% less code, conservatively approximated) and is an absolute bitch to spelunk in specifically because it's just Erlang.
There is no reason to create a new project in Erlang (instead of Elixir/LFE) outside of reasons like handing it off to clients or the like and the focus should never be on learning Erlang, but on the BEAM. Any knowledge gained through that is trivially used in one of the more productive languages on the BEAM.
We use REST for both internal and external calls to services (a mistake, in my opinion) and while Erlang actually has frameworks for this, none of them are good and cowboy_rest requires lots of boilerplate. Doing it with Phoenix would cut out lots of entire modules and replace them with functions without paying any real cost.
I like Erlang, but there's no upside to using it instead of something else that runs on the BEAM, apart from making a basic library that you want to use both from Erlang and Elixir (I don't know what the situation for compiling Elixir with rebar3 is).
Effectively, Erlang is to Elixir what Java is to Kotlin, except there are even less performance differences and no compatibility issues. It makes perfect sense to learn Erlang syntax and learning the semantics of it will mean you've learned BEAM semantics, but you might as well do that in Elixir and actually have a better road to it.
Edit: I'd like to add that I find a general lack of tools for dealing with boilerplate in Erlang. It also has a generally outdated functional programming skew in that it doesn't at all facilitate pipelining and this makes it less attractive to make nice abstractions like Plug(0), for example. This is exacerbated by the fact that collections aren't abstracted over, so whenever you end up dealing with them there's lots of sighing and docs checking to see what the argument order was the week they designed that particular module and that particular function in that particular collection module.
I told myself I'd avoid Erlang at all costs. Then I decided I needed to know how leex and yecc work, so I got down and dirty w/ Erlang. It's close enough to Elixir that I can stumble through my way through it.
Just the reply I was looking for. I do not have your years of Erlang experience but I've done enough to think I have a feel for the language itself as well as the fundamentals of OTP.
I've looked at Elixir and my feeling is that "it's probably great if you're coming from Ruby but what's the point if you're already invested in Erlang?"
As many others said in the thread, forget about the relationship between Ruby and Elixir, and give Elixir a try. It is much more than syntax: structs, protocols, the test framework, documentation, tooling... even the new error messages and debugger make a big difference on every day development.
There are reasons for picking Erlang over Elixir but if the reason is that "Elixir does not offer anything beyond syntax", it is likely the person has not been paying much attention.
Yup, I actually hate the Elixir syntax. I've never been a fan of ruby syntax. Granted I find the elixir syntax a step up on ruby. Anyways, Elixir is nice because of its abstractions. While I understand most people come to it from ruby for its familiar syntax.
Definitely recommend reading "The Little Elixir & OTP Guidebook"
The focus of the book sounds like pretty much what you're asking for. The first few chapters cover Elixir basics, but its really just a primer -- easily skippable if you already know it. Starts with implementing OTP features from scratch so you can see what they do and why they exist, then dives into how to do it using OTP.
> I'd like to design reliable systems that operate outside of the classic HTTP -> Elixir -> Database pattern.
Then use Erlang. I like and prefer Erlang to Elixir for example. It has a simpler syntax, it's consistent just like Elixir. And you'd be surprised that Erlang for being what 30 years old is being regularly updated and improved Most importantly things are deprecated regularly from the the language and the standard library, as new stuff is added. That's how it managed to still say small and simple. Plus you'll get a lot of resources and reference already created for it.
If you like Elixir, start with it as so many concepts overlap and then you'd pick the Erlang syntax and some conventions later without that much hassle.
is there any news recently about Elixir? I'm asking since recently Im seeing a lot of articles about how to get into Elixir which is really nice since I just started pickup the language as well.
Erlang/OTP 20.0, Elixir 1.5 and Phoenix framework 1.3 were all released in a timespan of 2 months or so - huge improvements to the already great ecosystem.
The Phoenix team was waiting for Elixir 1.5 to release the new version of the framework (or at least one of the devs said as much in a talk I watched a while ago).
Erlang/OTP 20 came out June 21[0], so about 5 weeks ago.
Makes sense though, Eliir 1.5 was waiting for final release of OTP, and Phoenix was waiting on final release of Elixir, but they'd all had very stable preview releases for a while, so it wasn't a ton of work left on any of them, just finalizing and testing I imagine. I'm super excited to get my side project[1] upgraded to 1.5 and see the new dev conveniences!
Wow http://elixirbridge.org seems really interesting! I'm following the official tutorial right now to get the basic down and will go through the book Programming Phoenix
Don't sleep on your Erlang literature: Learn You Some Erlang, Erlang in Anger, Design for Scalability with OTP. Also Little Elixir and OTP Guidebook is pretty short. I haven't read it yet, but Elixir in Action is supposed to be very good, too.
I've spent the last year building[1] an open source side project with elixir and phoenix. It's honestly been a pleasure to work with once you get over some of the initial hurdles.
I happened to mention interest in Elixir on my LinkedIn page, and now I get hit up by recruiters for it every so often, so it seems so. I haven't heard too much outside of this personal anecdote, however.
At the london meetup last week, when ask if their company recruit and search for elixir devs, everyone raised their hands. Approx 60 to 80 devs. So probably 20 to 30 company....
Ryan Bigg (github: https://github.com/radar) has been active in the Ruby community for years (and is seriously intelligent, at least based on his many past IRC responses to my Ruby questions, assuming he's also named Radar on there), has apparently been working with Elixir on the side for a while, and IMHO can definitely handle an Elixir book intended for new programmers. He would be a very significant asset to the community were he to jump ship and go fulltime Elixir.
Your skepticism (which is otherwise probably warranted) is quite wrong in this case. I'm sorry if someone defecated into your Cheerios this morning, though.
Sometimes the best way to learn is to teach, and sometimes the best way to teach is to make money teaching. :P
Yes that's me on both GitHub and Freenode IRC. I've been doing Elixir for roughly two years now. It's been fun.
I am not planning on jumping fulltime Elixir any time soon, because my company is currently doing a mixture of Ruby + Elixir. It's likely that I'll still straddle that particular divide for the foreseeable future :)
> (I'm well aware of what Ryan Bigg is and isn't, it's why I'm pointing this out)
So you're taking your personal issue with him, here. That's nice.
> There's no need for that.
Says the person who's quite frankly being a dick towards this guy without presenting any justification or evidence whatsoever, and I know for a personal fact that this guy has aided me on many occasions. I think you should check yourself before you wreck yourself any further, person. If you have a personal problem with him, take it up personally and not in a public forum. I have zero tolerance for evidence-less public humiliation, and so should all of you.
> IMHO someone which actually contributes high quality libraries or code to said community should be valued more
I think you're underestimating a number of things that are not visible on github yet can definitely have a positive effect on the community:
1) evangelizing a technology you believe in (something I've been known to do, on here and elsewhere)
2) organizers of meetings, confs and get-togethers
3) guys who help all the time on IRC and Slack in the relevant channels (something I've also been known to do, because I enjoy mentoring yet sort of abhor the spotlight)
4) book authors... has Dave Thomas been a big committer of elixir code? I don't think so, and yet his Programming Elixir book is considered one of the best
5) a lot of other stuff that is simply not very visible, such as Jose trying to make the community more inclusive
I googled Dave Thomas, and was not disappointed by the images of Dave Thomas of Wendy's fame with a description of the computer programmer and author underneath.
Hi. Nice to meet you. Clearly you know who I am, but I am not sure who you are. Care to inform me? Maybe we've met before. Commenting anonymously in a venemous way like this is surely below someone like you. Come out of the shadows and come and play with me. This'll be fun!
----
The book is released for free, however I charge for the PDF because it takes time + energy to generate that (and typesetting, omg) _and_ it gives people a way to financially support the project (if they want to).
Joy of Elixir will _always_ be free because I think having the bar of entry as low as possible for newbie programmers is a nice thing to do. As I say on Joy of Elixir's about page, I want this book to be the equivalent to Learn to Program, but for Elixir. So in that same vein, it will always be free.
---
Regarding my Elixir experience: I have been happily using it for two years "for fun" and one year in production _almost_ full-time. I have built several parts of my workplace's microservice's architecture using Elixir in a small team of Elixir developers. I've learned a crap load and made some frankly _awesome_ mistakes.
In the last four months I've started mentoring a junior developer in the ways of Elixir and that's what led me down this path of writing a book directed at newbie developers.
---
Brown-nosing on IRC? Hardly. I've been active on Freenode #rubyonrails for at least 10 years and #elixir-lang on-and-off for at least the past 2.
> IMHO someone which actually contributes high quality libraries or code to said community should be valued more, yet these are usually the last people you would ever see slapping their name on a book. They are happy to just improve the existing documentation and contribute that way.
I wrote https://github.com/radar/elastic. Sorry if this is not up to your high-quality bar. Patches welcome. Open source is great, yeah?
And by the way: I am strongly (so strongly) in the camp of documentation being more important than the code itself. For without documentation, who can understand how to use the code? Who can understand the _reasons_ behind the code?
---
> This is all just A self promotional stunts. The author has done this before in the Rails community.
I started contributing documentation fixes / entire guides to the Rails community in 2008. I started using Rails in 2004. I felt it was one of the best ways that I could possibly give back to the community that has kept me very, very safely employed since 2006. 543 commits to Rails, at least: http://contributors.rubyonrails.org/contributors/ryan-bigg/c.... All for free.
In terms of self-promotional work, I spent at least two years of my free time writing books. Probably closer to three, but let's not brag too much. And yes, I _do_ use the books I wrote for self-promotion. It would be pretty ridiculous to spend all that time writing a book, selling it and then _not_ using them for self-promotion, dontyathink? I use them as more of an example of what I am capable of teaching people, more than "hey, look at how STUPENDOUSLY AMAZING I AM". Although, I admit, sometimes I act that way too.
---
Anyway, it's been nice rebuffing your attacks today. I'm very happy to continue to play this game for as long as you wish. I guarantee you I have more patience.
And I implore you again: come out from the shadows, little troll.
The author has been hanging around the community for the past few months, if they wanted to make it a better place, they should work on improving the already amazing documentation. This is all just A self promotional stunts. The author has done this before in the Rails community
I'm not familiar with the author, but writing a programming book has got to have the worst possible effort to return value ratio if one's goal is solely self-promotion. I'm disinclined to believe anyone would put in that kind of time if that's what they were going for.
Yup, sorry about that! I am a _horrible_ artist and so I'm hoping to rope a good friend of mine in to help with that. He's recently started a new job and so he's been busy. One day there'll be some great images in the book.
It does if you are an absolute beginner to programming. If you are already seasoned then yes it doesn't add much, it just means you aren't the target audience.
> They are setting up their users for disillusionment and disappointment.
There's nothing wrong with communities promoting themselves. If people don't know about your thing, they can't try it to make their own decisions about whether or not it is worth using.
And it isn't yours or a community leader's or a maintainer's job to protect users from disillusionment and disappointment. If someone actually has a hard fall from realizing that a programming language isn't as great as people said it might be, there are way bigger issues there than the programming language at play -- on the side of the disillusioned, not the language/community.
I too feel there is a generational hype cycle at HN. However, I don't see much in the way of "language N sucks" as a precursor to "everyone should use language N1!" Maybe I am just blind to the negativity, but in general, what I see with each hype generation is only the positive side: "everyone should use language N1!"
I suspect with any given hype generation—with each trending language—we're going to see a lot of positive messaging as the fans up-vote articles pertaining to the new hotness. Meanwhile, those who disagree (or simply don't care) probably don't see much value in taking the time to evangelize their disagreement. I'm not upvoting Elixir content, but I'm certainly not going to downvote it either. Why should I care if other people enjoy a platform I don't care about? Good for them!
Also, perhaps as everyone is hyping language N1, those who are using N are simply too busy using N and making a living to keep layering on the hype.
Adding more programming languages just fragments the job market further. That might mean fewer jobs available for other languages and allow software developers less movement between companies.
How many times have you seen a job advert and you think oh wow that looks interesting, I'd like to work there... Oh wait, they use X on the backend, I don't have any previous commercial experience with X so damn, I can't join the company. The more programming languages there are, the more often this will happen. The time for creating and promoting new programming languages is over, we have to move forward and work with the languages whose ecosystems have had 20 years to evolve - This is where the real value is.
I'm certain that using Elixir over Haskell, Go or even JavaScript/Node.js adds no extra value to any given project... It only restricts the pool of potential job candidates.
If you use any programming language for long enough, eventually, you will be very productive with it - The language itself doesn't really matter.
Its just a waste because there are already so many languages optimized for the server-side use cases which Elixir aims for and which are already doing a great job.
> [...] allow software developers less movement between companies.
> How many times have you seen a job advert and you think oh wow that looks interesting, I'd like to work there... Oh wait, they use X on the backend, I don't have any previous commercial experience with X so damn, I can't join the company.
Wait, just who are you, then? An intern fresh out of high school? Or do your circumstances impair your ability to learn (I hope I'm not being insensitive)? Are you a programmer?
I ask because it never happened to me, and I never even heard of something like this from non-junior programmers. If the company I'd like to work at uses a language that I don't know (there's actually pretty decent chance if they use something mainstream) I believe in most cases it would be enough to tell them I'll learn the language in a week and after a month I'll be writing decent quality production code. There is no reason - except if I do bad in the interview, maybe? - to not believe me, as that's generally accepted as a standard timeframe for such things. In my case that's a lie, as I can get started with a language in a matter of hours and start writing production code after a few days - but I admit I'm unusual on this.
> I'm certain that using Elixir over Haskell, Go or even JavaScript/Node.js adds no extra value to any given project...
Programming languages are being created for a reason and "adding value" in some kinds of programming tasks is a prime concern when designing them. Different languages make different choices and in effect work better or worse in given circumstances.
Replacing Node with Elixir (any BEAM lang) would immediately give you a true SMP support without using spawned processes, for example, and could possibly shorten and simplify your code if you have many communicating, long-lived services in there. That's an added value, right? The saying "use the right tool for the job" fits here perfectly.
> If you use any programming language for long enough, eventually, you will be very productive with it - The language itself doesn't really matter.
Exactly - so why limit yourself to a single language? How long do you think you will be working? What will you do once you've mastered a language and realize that you have 20 more years to work with it? Wouldn't that make you bored after a while?
> Its just a waste because there are already so many languages optimized for the server-side
There is not a single language which offers the same mix of features as Elixir. It's perfectly possible to have a system which would benefit from the just right mix of features and then not having these features is a tremendous waste as well.
It's not like I don't understand where you're coming from: in my youth, when I was learning C++, I also was frightened by the complexity and believed that it will take years to master it. And it did take years, mostly because it's C++ and I was alone. However, the next language I learned - PHP if memory serves - took me just a couple of months to get good at. Then, when I passed the 20 "langs known" mark, I realized that learning languages is no longer a problem at all and instead made it into a hobby.
In other words, yes, you need some level of understanding of programming to be able to efficiently learn new languages. I think it is better to strive to reach this understanding instead of assuming new languages are bad.
I've been programming for 14 years in about 10 different programming languages... It's a struggle for me to list them all (let alone learn them). I only really needed two of them; all the others were a waste of time because they're so similar to each other.
Learning new languages is not hard for me, I can pick up a new one in a single day and my code could fool someone into thinking that I've been doing it for a while (if you ignore development speed)... But unfortunately that's not true mastery, you can only truly master a language or framework after working with it full time for a couple of years.
It takes a long time to absorb all the intricacies of a language to produce really good software.
You could spend a few years studying French and think that you know it all by the end just because you can talk fluently, but in reality you couldn't even write a basic child's novel, let alone a top-seller, or a Pulitzer prize novel.
It depends on what kind of work you want to produce.
> 10 different programming languages... It's a struggle for me to list them all (let alone learn them).
That's still very little. You can take a look at my site (in profile, the "Languages" page) where I listed PLs which I learned. There's 126 entries on that list (to save you a couple of clicks). I'm not boasting - just offering a different perspective.
> all the others were a waste of time because they're so similar to each other.
If they are so similar, then learning them should be very easy and quick, no?
> I can pick up a new one in a single day and my code could fool someone into thinking that I've been doing it for a while (if you ignore development speed)...
In a single day? So it's not that much effort, is it? Assuming, of course, you won't hit the language which is different enough and your intuitions and experience become useless.
> you can only truly master a language or framework after working with it full time for a couple of years.
You're wrong, in part.
It takes a lot of time to master your first language and a few others in the beginning. Later it can take quite a lot of time to learn your first language with a paradigm you're unfamiliar with.
But languages are similar to each other, can be classified into types and studied in bulk. With enough languages (and frameworks) learned you develop an intuition of what happens and how. With enough different languages known, you develop an intuitive feel for what's the best way of solving a problem in a given language. There's also a bit of theory to be learned, but once you have it down there's really nothing that can surprise you.
Personally, I've had the hardest time when learning J. There are exactly two other languages which are similar (APL and K) and they both are even harder to get into. So the reverse is also true: if you don't know enough about a certain kind of languages, you're going to have a hard time.
In the end, I think we disagree on what we consider mastery. I don't believe you have to remember all the finest details of implementation to say you've mastered the language - as long as you can easily drop down to the compiler or interpreter source, read it and understand without effort. It's all pretty easy then, believe me.
don't understand why you got downvoted, it's a pretty legitimate concern.
You may however see the whole thing a bit differently :
- node popularized single loop event on the server side, which is great for fast low cpu request processing
- go evangelized simple design, coroutines , unique code formating, and has arguably one of the best stdlib. That's still true today and it's great
- Rust made people realize writing concurrent truelt safe code was possible. Huge advance.
- Elixir helped the community focus again on actor + message passing concurrency. It's fantastic.
All of those concepts are beneficial to learn, for you as a programmer, no matter which language you use.
If for example look at swift evolution, you'll see the current threading model (based on event loops, like node, because of iOS) discussed and compared to the actor model ( like erlang / elixir), but also that some web framework reimplemented go-style concurrency.
You'll also see that they're talking about adding semantic for detecting memory sharing patterns (much like rust).
If you've followed all the discussions on those languages for the last two years you know exactly why those conversations are taking places. So all in all it's a good thing communities are advocating the strenghts of their language. It helps everyone improve.
I know I've seen at least one educator in the community speculate that Elixir (or FP languages in general) could potentially make great 1st programming languages because they're often conceptually easier than OOP languages and in many ways the difficulties people associate with learning them come from the difficulty of unlearning some of the things they already know.