I do have such a day job with Elixir, and I utterly love it. It may rose-colored glasses, but considering I came to Elixir from Erlang (instead of Ruby/etc…) and that I’ve been doing this stuff for almost 30 years across innumerable languages, so I hope I am at least decent enough to identify a good language that should be sustained. Elixir has a couple of warts of course (and I wish it made one ‘big’ change, but I do not see that happening), but as it is, it is well worth it.
4 Likes
Scala was not functional, at all. It had some good libraries built on it, but it was not functional at all, the JVM is antagonistic to that style, but it helped when it could. Scala instead was just a better syntax of Java, it had the same functions, could call back and forth with java with ease, same styles, etc… It literally was just Java with a significantly less wordy syntax. Kotlin is what is inching into Scala right now, not be any fault of Scala really, Kotlin just does the same thing as Scala (full compat with Java but a simple syntax), and it just has ‘less’, less new libraries, less new features. You can think of Scala as being Kotlin but with an expanded standard library (really nice standard library, but still it added code you may not have needed).
Again a good illustration that any generalisation is flawed 
C# is horrible for backend stuff. Functional is better then object oriented in my opinion no concern about side effects and state.
Let’s not get too dogmatic please. StackOverflow runs on .NET and it’s one of the fastest and best responsive sites out there. While I also prefer functional programming, any paradigm works under great developers.
I thought they had a massive bank of servers with huge CDN use and mostly static content? ^.^
Although to get crazy, I’ve made a website in C++ before. It actually worked really well, I did all rendering server-side and sent diff updates to the client over long-polling (websockets did not exist yet) to javascript that applied it. I was surprised at how well it worked.
My point is, I don’t want the Elixir community to be a bunch of “FP is the only way everything else sucks!!!”. I hate that attitude 
1 Like
Hyperglot-programming for the win!!11!
Consequently I just setup a blog that I hope to post interesting code stuff on. I need to make the theme somewhat less horrid on the eyes, but I’m mostly playing around at this point. ^.^
I like the sensible discussions of Erik Meijer. About this subject:
(Static Typing Where Possible, Dynamic Typing When Needed:The End of the Cold War Between Programming Languages):
2 Likes
This article might interest you (The Curse of the Excluded Middle “Mostly functional” programming does not work): http://queue.acm.org/detail.cfm?ref=rss&id=2611829
Btw I do not know of very strictly defined boundaries between oo, fp etc. Elixir / erlang themselves are called impure fp languages often.
Scala is OO + FP.
Sometimes you need to write some boilerplate code to get some FP. This code can look ugly.
There are functional libraries to help you program FP in Scala:
But there will be always limitation of JVM. Are there any better alternatives on JVM? I don’t know.
Is Scala better than Java? In my opinion yes.
Wery nice presentation
(Functional Programming is Terrible … in Scala)
1 Like
I love Erik Meijer 
I agree with @OvermindDL1 to a large extent, though not necessarily to the extent of forcing strong typing on the language (which I don’t see happening). The main pain point is compile-time analysis, which effectively comes down to tooling.
Right now, to the best of my knowledge, Emacs and Vim (and variants) are the most popular IDEs. I come from the Windows world to Elixir/Erlang because of the natural concurrency model of the BEAM being the best of the FP + OOP worlds. I’ve become pretty decent at Vim, but Emacs was just too different. (I don’t want to start a war here over the various qualities of these - If you’re ninja in your stack, then that’s great.)
My point is that there is a huge investment in just being able to edit a file. Elixir/Erlang has the superb architecture and infrastructure. And I have repeatedly said that I think Elixir’s documentation is top-notch and may be my favorite aspect (and the community genuinely rocks!). The next big goal, IMO, should not be language improvements (though I love and welcome them hehe). It should be tooling for us mainstream-ish-ers, with these particulars: solid, and reliable intellisense, jump-to-def and back, and refactoring. Oh how I miss refactoring (but it’s not worth it trying to program asynchronously in any other language).
That’s my two-cents. Lots of luv.
1 Like
I don’t know what’s most popular (old school Erlanglist prefer Emacs, that’s all I know) but Elixir has awesome Atom plugins and linter and just works like a “regular” editor. Sublime is not far behind. It’s no VS Code intellisense for C#, but it does just fine (Atom autocompletes my own and the standard modules).
You’re right that most, if not all pretty much all but a few, Elixir devs use a simple text editor. Not many people use IDEs.
2 Likes
Yes, I am currently using the atom-elixir package and it’s great. But it’s basically one awesome dev in his free time, and not a team of devs. Consequently, it’s a bit on the buggy side and it doesn’t have refactoring. (I can’t seem to get my user-generated code to code-complete even half of the time recently, but I’ve just set up a new environment so we’ll see.)
And I’m well aware that elite devs have no problem coding without intellisense. But it’s a productivity loss. And no refactoring - that is a huge productivity loss for anyone, no matter their skill level. Fortunately, the language is so good it outweighs the missing tooling…plus observer is pretty freaking awesome!
But I still think that this should be a focus in the near future for Elixir.
Intellisense is always useful.
4 Likes
Indeed!
While there are certainly people who have blinders in regard to FP, there is a real benefit to adopting at least a hybrid form of FP. The removal of default mutability removes a significant source of accidental complexity–unintentional changes to data.
I certainly agree that being so chauvinistic about a choice of language paradigm just turns a lot of people off but there are real benefits to adopting FP just as OO offered real benefits over the structured programming that preceded it.
1 Like
for tooling:
-
I would like to have IDE like clojure has (cursive ide). But I hope that intellij-elixir will get there.
-
Integration of Dialyxir/Dialyzer into IDE
-
Refactoring
1 Like
When Elixir grows big enough JetBrains will do official IDE
4 Likes
Elixir’s biggest competitor in terms of adoption is Go based on my observations over the last year. The Go team thought that it was going to appeal to people who were using C and C++. Instead it’s adoption has come largely from teams that were/are using Ruby/Python/Perl/Javascript that needed a solution for heavy concurrency and faster performance that the limitations of those languages. Go adoption skyrocketed and in the right use cases it shined.
People found out fairly quickly that it is not a “virtually all use cases” solution. Full stack web development is pretty painful with it. The community push towards “if it’s not in the standard library it doesn’t really count” mentality combined with the package management complaints has created a lot of difficulty and tedium around it for a lot of people. To be clear, I’m not bashing Go because it really is a great language when it fits your use case.
What I’m getting at here is that the Ruby/Python/Perl/Javascript developers who needed a solution went to Go because it was the best available option with the lowest barrier to entry at that time. In my opinion, virtually all of those developers were really looking for Elixir. Elixir best bet for continued adoption and growth will come from those communities.
I see a lot of discussion about stricter static typing in this thread and that’s not going to help much with getting those types of developers to adopt. Dynamic vs Static is a much bigger debate that is worth having in this forum but the preference largely boils down to what you’re used to. As fast as Elixir is, you’re not going to win over Java developers with arguments about speed or concurrency because people in Java shops have invested heavily in Java peripheral infrastructure. Ditto .NET shops. If the architectural arguments were going to win over those communities Erlang could have done it.
Where Elixir fits is as the best of breed solution for productivity and concurrency as a dynamic language. It takes Python/Perl/Ruby/PHP/Javascript by a landslide compared to those stacks and those stacks also come with very low infrastructure investments, meaning cost of switching or adding in a new language is very low.
That’s the growth market for Elixir because it’s the market where Elixir presents the biggest solution to a problem. The other is the case when Erlang/BEAM was the ideal solution and the team was more comfortable with Elixir. I don’t know that Elixir will cannibalize the Erlang world as much as expand it though.
6 Likes
