Elixir – The next big language for the web
11–20 of 85 posts
Re: Elixir – The next big language for the web
#12I think the next big thing is Meteor. Here's why: 1. Real-time baked in. 2. Uses Javascript (tons and tons of developers know at least enough to use Meteor) 3. Sane templating engine. 4. Same wow effect I had when I first started Rails. 5. Fantastic build system. Pheonix and Elixir may be the bees knees, but unfortunately because it uses a functional language, it drastically cuts down the mindshare of developers. I d…
Javascript has functional features too.
A lot of Elixir developers come from platforms such as Python, Ruby, node.js
Re: Elixir – The next big language for the web
#13I think the next big thing is Meteor. Here's why: 1. Real-time baked in. 2. Uses Javascript (tons and tons of developers know at least enough to use Meteor) 3. Sane templating engine. 4. Same wow effect I had when I first started Rails. 5. Fantastic build system. Pheonix and Elixir may be the bees knees, but unfortunately because it uses a functional language, it drastically cuts down the mindshare of developers. I d…
plus, you can use (or mix&match) other languages that compile to JS if you want. Coffeescript is the most popular choice (I code in literate coffeescript by myself), but stuff like livescript adds some more functional features as well.
Re: Elixir – The next big language for the web
#14Does dialyzer work with elixir?
Re: Elixir – The next big language for the web
#15Does dialyzer work with elixir?
yes
Re: Elixir – The next big language for the web
#16Not about Elixir specifically, but don't people get tired of switching languages? What, people will now have to port all Ruby libraries to Elixir (or, at the very least, relearn them), and then a few years down the line to the next thing? Isn't this a huge waste of effort? Not to mention the poor CTO who gets a job at such an early-adopter company in 15 years, and finds out the codebase is made up of 7 different languages, four of them have been defunct for years? I mean, a language's benefit must at least cover all the switching costs, the fractured codebase costs and then some to justify adoption. Are all the new languages such huge advances over older ones that they do that?
Re: Elixir – The next big language for the web
#17This isn't a criticism of Elixir (I've never used it, so I can't do that), but how can one just declare something "The Next Big" thing?
Did you read the article? The first sentence is literally:
"In this article I will explain why I think the Elixir language will make a big impact in the world of web development."
Re: Elixir – The next big language for the web
#18I think part of it is that with Erlang it is not as easy to get up and running with a new website.
I'm doing this at present and there is no special difficulty.
And things like package management, build tools, meta-programming, unicode handling and web frameworks are not as straight forward as in languages such as Ruby.
Erlang's module system means that a chunk of the raison d'etre behind language-specific package managers is already alleviated. The rest - dependency management and building, is handled quite well by tools like Rebar. One can also leave Rebar as a dependency tool strictly (which is its primary purpose anyway) and use whatever they like for a build system. Plain old Makefiles can work just fine, and it's not like most language-targeted build systems aren't some shiny variation of make, anyway.
Metaprogramming isn't quite as easy as in many OO languages, but it's hardly out of reach. The parser, the lexical scanner and other components are all exposed as Erlang modules, and there are projects such as the BossDB ORM that use parser transforms to provide features such as parameterized modules, which allow for using Rails-like ActiveRecord patterns, among other things.
Unicode handling? I think this might be a knock on Erlang's string handling. Strings are represented as iolists of Unicode points (integers) which goes with much of Erlang's philosophy in lists and tuples as being the prime data types. Space efficiency and real-world usage usually has strings passed as binaries, but most web frameworks and libs can handle them plainly nonetheless.
Web frameworks? Chicago Boss for a Rails-like, Nitrogen and N2O for real-time and extremely high load applications, or even just plugging in to web servers like Cowboy or Yaws can be enough for a RESTful backend.
Re: Elixir – The next big language for the web
#19Not about Elixir specifically, but don't people get tired of switching languages? What, people will now have to port all Ruby libraries to Elixir (or, at the very least, relearn them), and then a few years down the line to the next thing? Isn't this a huge waste of effort? Not to mention the poor CTO who gets a job at such an early-adopter company in 15 years, and finds out the codebase is made up of 7 different lang…
I think the issue is that many CTO's don't take all of these factors into account when they do decide to switch to or add a new language to the companies codebase. It seems many are shortsighted and simply see A > B without evaluating all of the costs of switching from B to A.
Re: Elixir – The next big language for the web
#20I think the next big thing is Meteor. Here's why: 1. Real-time baked in. 2. Uses Javascript (tons and tons of developers know at least enough to use Meteor) 3. Sane templating engine. 4. Same wow effect I had when I first started Rails. 5. Fantastic build system. Pheonix and Elixir may be the bees knees, but unfortunately because it uses a functional language, it drastically cuts down the mindshare of developers. I d…
1. "Realm-time" isn't baked in. It certainly comes easier to write real-time programs (for some definitions of real-time) than in some other environments, but real time programming doesn't come for free in any environment. You're overreaching with this claim.
2. Tons of programmers know JavaScript well enough to avoid it. A language originally thrown together "to make the monkey dance" is generally a poor choice.
3. Sane templating engines are a dime a dozen. I could probably find 5 in Python alone.
4. Same later realization that it's really good at a few things at the expense of others, I'd bet.
5. Okay I'll cede one point.
> Pheonix and Elixir may be the bees knees, but unfortunately because it uses a functional language, it drastically cuts down the mindshare of developers. I don't even know any developers in real life that use functional languages. Looks interesting but that's the reality.
That says more about you than about the quality of tools involved. I'd rather have quality of mindshare than quantity.