This article suggests it does
4 Likes
Even if Elixir pulls some members from each of those communities, obsoletes is an awfully strong word.
Regarding Erlang, I actually think Elixir will help it grow. Assuming (wrongly, I believe) all people new to the Elixir/Erlang community choose Elixir for new projects, working within this ecosystem will almost certainly increase contributions to existing Erlang projects.
Ruby has a lot of strong libraries and frameworks and an extremely strong presence in several areas (security and devops comes to mind). Until similar yet better (because why switch if its just ‘as good’) tools come along I don’t see ruby going anywhere anytime soon.
I can’t speak much to Clojure from personal experience, but I have seen no indication that the JVM is going anywhere anytime soon, or even that its use (vs, perhaps, popularity) is on the decline, so having a strong functional language in that ecosystem can only be a good thing.
All that said, I’m loving elixir, and haven’t run into enough pain points to not use it for any of the projects I have in mind to write in the near future.
12 Likes
On a related note, I’ve been following the Scala wave for a few years now. It has corporate backing (Lightbend nee Typesafe), and even if you don’t buy into all the FP stuff can be just a ‘better Java’. You can use existing Java libs directly - half the time you don’t even know your using Java libs until a function returns NULL 
. Yet, it has still only made a small dent in Java usage. Despite loving it myself, I’ve had little luck convincing co-workers of its benefits so we still use Java.
I am not a Ruby user or follower, but if you believe in the TIOBE Index, it has about 10% of the following of Java. Smaller, but still quite significant. Erlang makes the top 50. Elixir may steal some of the popularity and may even make them obsolete, but that doesn’t mean people will quit using them and jump to Elixir. Don’t forget corporate inertia, either.
There have been dozens of ‘killer languages’ in recent years each stealing a little popularity, but even obsolete languages are still hanging out at the top.
3 Likes
I’d echo the above two posts as well.
Even languages that rise to fame, like Ruby, don’t really make other languages obsolete - well apart from previous incarnations of themselves. So Ruby 2 made Ruby 1 obsolete, and Ruby 3 will make Ruby 2 obsolete.
I also see Elixir, complementary to Ruby and Erlang - in that those who use either of those may also add Elixir to their toolbox.
For me personally I see Ruby, Elixir and Crystal as part of a gang of languages that share something that I find appealing - programmer happiness. Each language has its strengths too:
- Ruby for how easy and quickly you can put things together (partly because of the libraries and partly because of how intuitive the language is)
- Elixir for when you need highly concurrent and scalable backends
- Crystal for when you need CPU intensive things like image and audio processing
5 Likes
I don’t think so the one language ‘can rule them all’ 
You need to know proper tool to solve specific problem. If you need proper integration with java ecosystem you probably choose Clojure over Elixir.
If you need to play with Big Data you probably choose Scala language to use Apache Spark
There is nice talk how knowing some language can affect programming in other langauge Functional Geekery Episode 45 – Brooklyn Zelenka
3 Likes
Hey, article author here!
Thanks eDev for linking and to others for your comments.
Just wanted to clear up a few things.
Will Elixir strenghten Erlang community? Of course it will as ckhrysze nicely explained.
Will Elixir be more popular than Ruby in a few years? Very unlikely. It is extremely hard even for the finest contenders to get into top10 of programming languages, popularity wise.
Can Ruby, Erlang and Clojure die because of Elixir? Of course not. Even COBOL still hangs around pretty well 
Mainstream languages never die. They simply get obsolete. Obsolete means there are better ways to do it today.
And just to be extra clear - of course the article title is a slight overstatement. This is on purpose: a wake up call.
8 Likes
@qertoip but Ruby has been declining steadily these last couple of years (since 2010/2011 I think?) and Elixir is rising in popularity, although still slow of course.
Don’t know if you saw the new Stackoverflow survey
Elixir is in front of Erlang in the Other Technologies used and is the second most popular language in the wanted technologies.
I really hope, and believe, that Elixir will replace Ruby in the future, both in terms of popularity and by just being the ‘better way to do it’.
2 Likes
I find some of those stats peculiar - Rust, Swift, F, Scala, Go as the most loved languages? Ugh, all those semi colons and brackets 
2 Likes
I’ve been getting very interested in Rust lately @AstonJ. Its popularity is skyrocketing and I’ve seen people go as far as claiming it to be the new ‘C’ 
After I finish most of my thesis and have a good grasp of Elixir I’ll probably look into learning it.
3 Likes
But it looks like this 
fn main() {
let program = "+ + * - /";
let mut accumulator = 0;
for token in program.chars() {
match token {
'+' => accumulator += 1,
'-' => accumulator -= 1,
'*' => accumulator *= 2,
'/' => accumulator /= 2,
_ => { /* ignore everything else */ }
}
}
println!("The program \"{}\" calculates the value {}",
program, accumulator);
}
I really dislike brackets and semi-colons in a language. Tho I appreciate not everyone feels the same way…
2 Likes
Rust, Swift and Go are languages which do aim at very different targets than Elixir and Ruby do.
These 3 are system level languages. In each of these you can code operating systems, that’s impossible using Elixir or Ruby.
Syntax-wise, of course, you are right. Semicolons are such an eighties thing, and I really think one can really do better these days. But I really don’t care if I have brackets, do/end, or begin/end to enclose blocks of code, everything is better than the whitespace stuff done by Python, Haskell or SASS. It always is causing problems in projects which have multiple contributors and a single one has an editor which isn’t configured correctly and from then on tabs and spaces get mixed and everything blows up…
7 Likes
I am not sure I would ever need a system-level language. The most I can see (with my future projects in mind) would be image/audio/video manipulation for which I might look at Crystal. Soundcloud are using Crystal (and Ruby).
What kind of things would you guys use Rust for?
2 Likes
Rust has some very strong guarantees about memorysafety due to its ownership/borrowing model. As long as you keep your hands off of C-libraries or unsafe calls, it is impossible to have memory leeks in Rust.
So there are as big and well known (inside the Rust community) projects:
- Servo: This is meant to be a replacement for the firefox browsing engine. It does handle even large DOMs very well as far as I’ve heard, but I do also think, that it will take another two or three years of development until it catches up. It does fail some of the modern CSS3/HTML5/JavaScript stuff, but the things that work do better in benchmarks than gecko (performance and memory)
- Redox-OS: A next gen operating system that is in a very early stage of development, but already on the watchlist of some people that do have requirements on safety. This OS is able to guarante some things Linux and Windows never can, and this mostly due to the way of how Rust handles allocations.
To be honest, sometimes I do some things in Rust, because I do like it more than C because of traits and immutability, and also because you can implement many things in a functional way. But after I did a day or two in Rust, I am frustrated and wish me my GC’d languages back
Also there are Graphic-Engines, you can probably use them from BEAM, but I don’t think that you can code an efficient graphic engine in any BEAM-language. I am sure there are many things that you will have problems too.
5 Likes
like @NobbZ said, Rust is really strong because of the ownership model.
In my case, I’m really interested in using it for computer graphics (which I’ve got a huge interest if you have read my Unreal Engine thread ). I’ve recently found this project: Glium which is an OpenGL wrapper for Rust. I really want to learn Rust to use that wrapper and to learn more about systems programming which I’ve always have been really weak at (my worst grades at university were all in systems programming/low level courses 
)
4 Likes
In general I want o say, that there will never be a language that makes other languages obsolete.
There will always be some special need for a certain language.
Only exception I think is when there are multiple languages which have the same goal and similar syntax which do combine their effort into a single project.
2 Likes
Yes, I agree. Really old languages like FORTRAN or COBOL are still relevant because they’re still used in some companies and industries.
Of course, if it’s a really obscure language then you may consider the language as being ‘dead’, but not obsolete maybe.
Or if you consider languages like Malebolge or Brainfuck
1 Like
Rust looks like a natural companion to Elixir for doing low-level memory and computation tasks. There is Rustler, an Erlang NIF (Native Implemented Function) written in Rust - so no need to write C again!
I haven’t written any Rust, but I have wanted to contribute to the Servo project. That project does a fantastic job of creating & labeling GitHub issues, so beginner-level issues are clearly labeled E-Easy, and then C-Assigned. I think that system is worth emulating for other projects.
3 Likes
If there’s a language that makes other language obsolete, it’s Wolfram Language: it hits all the programming paradigms…
Does anybody have any exposure to it? I know it is available on Raspberry Pi now.
1 Like
Can you think of any particular use cases or situations where Elixir and Rust would be really useful together? You got me interested
3 Likes
Especially for you:
Define your games logic in Elixir using an actor based network while implementing the games graphics in Rust. Connect both using NIFs or C-Ports.
Even if NIFs are beeing treated better by the scheduler, they have some restrictions: A NIF is not allowed any longer than a single millisecond or it will confuse the scheduler, also if the NIF crashes, it will crash the whole VM. C-Ports are treated as every other Port by the VM and there is only a single instance available which might become a bottleneck as message receiver. But on the other hands site, it is allowed to run as long as it needs for its computation without affecting the scheduler.
Perhaps a mix of both might be possible?
4 Likes
