21–30 of 85 posts
http://elixir-web.github.io/weber/
But... the last commit was 9 months ago. Weber is dead. If you're interested in doing web stuff with Elixir today Phoenix is what you want.
I 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) Once upon a time, almost no one used object oriented languages except for Smalltalk weirdos.
2) Ruby, javascript and a host of other languages have "functional" features. Does your language have a "lambda" feature, where you can define nameless functions and pass them around as arguments to other functions? Then you are already working with functional language paradigms. There's nothing really "magically hard" about it, you're overselling how hard it is. This is not rocket science. Most existing programmers can handle it.
The hardest thing I had to wrap my mind around when switching my work to Elixir was letting go of mutable state. And attributes and methods on objects. And guess what... It seems that it's a good idea, generally!
If you see enough bugs that are only there because something modified an attribute in some unpredictable way which impacted upstream code... You will realize mutable state is bad.
If you still aren't convinced that mutable state is evil, watch this Rich Hickey presentation http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic... which basically proves that mutable state actually makes state a function of a hidden/conflated "time" variable, proving it's not just wrong from a practical standpoint (in the form of extra bugs that are hard to reason about, and all this brittle mutex code) but from a theoretical one, too. Mutable state comes from a time when memory was expensive, and it's time to ditch the training wheels so we can get the real work done.
Both Javascript and Ruby use mutable state extensively, and it's unfortunately not something you can just slap onto the language after the fact (although ClojureScript must make a valiant effort!) And if the high-level language wasn't built with it from the get-go, then you're stuck dealing with legacy libraries using the poorer-written code (see: Ruby gems).
Not 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 don't know about other languages, but having personally migrated from Perl and Ruby to Erlang/Elixir, I at least believe that to be the case in that particular circumstance.
A big part of it is that parallel programming is starting to catch on as mainstream rather than something to be shunned or avoided; whereas in the past folks were conditioned to avoid having to deal with threading or forking because of having to think about thread safety, there are now languages like Erlang (and its kids Elixir and LFE), Rust, Go, Scala, Julia, etc. that are meant to make parallel computing easier to reason about or less dangerous (or sometimes even both).
On top of this, though, Erlang-and-kids' reliability features allow them to achieve the legendary "nine-nines" of uptime (99.9999999%) relatively easily (I say "relatively" because - while you certainly still have to think about it (particularly if you're trying to push a change to, say, how data is represented on the (D)ETS or Mnesia or CouchDB or SQL or whatever side of things) - it's much easier than with a lot of other languages). That level of availability has huge implications for a company's bottom line, particularly those companies that measure downtime in "thousands of dollars per second" instead of just seconds. A well-written Erlang/OTP (or Elixir/OTP or LFE/OTP or anything/OTP) application can do this on the software side rather effectively (on the hardware side, you'd still want redundancy wherever possible/feasible, including on the network side of things; most well-run hospitals, for example, will have connections with at least two different ISPs so that if one goes out, they still have the other, and will only lose connectivity in very extreme circumstances).
In the case of Elixir, it makes for a very solid migration target from, say, a Rails codebase; the syntax is a bit more modern (I personally prefer Erlang's in many cases, but Elixir's pipe operator is a godsend) and familiar to Rubyists ("do" blocks, more flexible pipelining with the |> operator, etc.), while being fully compatible with the existing Erlang and growing Elixir ecosystems.
http://elixir-web.github.io/weber/
I used Weber when I first got into Elixir a little over a year ago. It was a cool framework and I even contributed to it (mostly keeping it up to date as new versions of Elixir were released). But... the last commit was 9 months ago. Weber is dead. If you're interested in doing web stuff with Elixir today Phoenix is what you want. http://www.phoenixframework.org/
http://sugar-framework.github.io/
(disclaimer: I'm one of the collaborators on the project)
Given some were touting Go as the next big language what - 12-18 months ago - can anyone enlighten me why Elixir would be different to Go. Or where Go didn't live up to its promises?
Not 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…
Are you a developer because you don't want to keep learning? Maybe you walked into the wrong room? ;)
> 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?
In this case, Elixir actually has a selling point, as Erlang has existed for over 20 years and has its own fairly mature box of tools (which are all easily accessed from Elixir).
From a bigger picture, a lot of code construction of late has moved to a SOA paradigm, in which case you can still call into perfectly-working Ruby codebases, except as a client from another language.
I wanted to know which direction Elixir is going to take? Will Elixir be mostly compatible enough with Ruby so that Rails can run directly off on Elixir?
Is there a plan to change Rails enough to run on Elixir?
How does the community feel about Elixir? I'm certainly interested in the concurrency aspects of Elixir (ie. no GIL) and everything else that Erlang has to offer.
The developers of Elixir were core Rails developers so please forgive me if I'm getting the wrong impression here.
Given some were touting Go as the next big language what - 12-18 months ago - can anyone enlighten me why Elixir would be different to Go. Or where Go didn't live up to its promises?
1. elixir is less strongly typed than go
2. elixir is more purely functional
3. elixir has a smaller community and is less backed
I've been monitoring Elixir on HN for a while now, looks like an interesting direction to take. I wanted to know which direction Elixir is going to take? Will Elixir be mostly compatible enough with Ruby so that Rails can run directly off on Elixir? Is there a plan to change Rails enough to run on Elixir? How does the community feel about Elixir? I'm certainly interested in the concurrency aspects of Elixir (ie. no G…
Elixir is not even approximately compatible with Ruby, nor is it intended to be. It just has syntax that is very loosely reminiscent of Ruby. Someone might one day write a Rails-like framework for Elixir, but it will never be the same Rails that runs on Ruby.
OTOH, if you want something no GIL that can run Rails, there is always JRuby.