71–80 of 228 posts
Earlier quoted context omitted.
The latter. The virtues of Elixir is that it is a functional language with immutable data structures, and that it does not support object oriented programming (which I consider a feature).
Erlang processes have state and you interact with them by sending them messages. You can do OO if you want :P
When people choose to build on a more esoteric language such as Elixir (and to lesser extent Erlang) is it because what they want to do simply is not possible in Ruby/Python/Go/JavaScript/etc or just less efficient, elegant, productive, etc?
There are several key distinctions about Elixir vs the other languages you mentioned. These are things that are basically not going to happen in Ruby, Python, Go, Javascript, or etc.:
1) You get the benefits of Erlang/OTP as others have mentioned in their replies.
2) You also get the amazing macro capabilities (runtime code execution and runtime code generation, a la LISP) that Elixir brings to the table. Many of the language features of Elixir are written in macros in Elixir. The source to both Elixir and Phoenix are quite elegant and educational to browse, and demonstrate this runtime code generation aspect very well. It's straightforward in Elixir to introspect code, represent that code as data structures, manipulate those data structures, then generate or execute that code, as you can in LISP.
3) Immuatable data and functional style leads to better code in lots of ways. This is what really makes the benefits of OTP possible (updating the code without restarting the servers, easily migrating state between servers, and so on). But it also makes certain kinds of situations easier to understand and fix, since all state in the system can be expressed as parameters to functions.
After spending nearly 7 years in the Ruby and Rails ecosystem, I changed jobs and have been working in with Elixir and Phoenix for nearly 3 months. I have been very satisfied with the process. The community is amazing, the tooling is unbeatable, and the quality and availability of open source libraries is great, especially for such a young project. The future looks very bright for Elixir and Phoenix!
Do you mind sharing what kind of project you develop? And even maybe what company you work for?
Earlier quoted context omitted.
Do you have any blog posts on task-queues and email sending/receiving? I'm trying to learn Phoenix and Elixir by rewriting an app I have that does just this. Sidekiq has been great as a background worker, but I'd like to try concurrency elsewhere.
If you're curious about the framework as well, here's the source for an app I made for peer-to-peer file sharing in Phoenix: https://github.com/hayesgm/fuego . You can try it out here: https://fuego.link Phoenix has really been exciting to use. It's a great way to get introduced into the OTP system from Erlang (plus all of Erlang's modules), it's incredibly fast, and the immutable data structures make it easy to reas…
Slightly off-topic, but can someone familiar with both Elixir and Erlang explain what Elixir provides in comparison to Erlang. I'm looking into using Erlang for a new project that requires extensive scaling and concurrency and am coming from a functional background so may be more comfortable with the traditional Erlang syntax. However it seems that perhaps more development and activity is happening on the Elixir side…
The syntax is nicer, but that's just a bonus. The real game-changer to me about Elixir vs Erlang is its macro system. This gives you runtime code execution and runtime code generation, similar to what makes LISP to powerful.
There's a large amount of boilerplate involved in creating an OTP server, as you know if you've done any Erlang. Elixir's macro capabilities completely eliminate all the boilerplate.
The source to both Elixir and Phoenix are quite elegant and educational to browse, and demonstrate this runtime code generation aspect very well. It's straightforward in Elixir to introspect code, represent that code as data structures, manipulate those data structures, then generate or execute that code, as you can in LISP.
Elixir also gives a number of excellent tools that streamline the support process over vanilla Erlang. For example, Elixir's runtime tooling automatically manages dependencies for you (similar to node's npm), and automatically maintains the application string that you need to provide for all OTP applications. It also has improved capabilities for testing, which are also made possible by the amazing macro generation capabilities.
> I'm looking into using Erlang for a new project that requires extensive scaling and concurrency and am coming from a functional background so may be more comfortable with the traditional Erlang syntax
Elixir's syntax is still just as functional. They support a regular if statement, unlike Erlang, but generally it's just as functional as Erlang. Elixir eliminates a number of needless chores from Erlang, such as having to end some lines of code with a comma, and others with a period, and then shuffling punctuation around whenever you add or remove lines of code. That's a task I used to do literally a hundred times a day in Erlang that I don't have to do at all any more.
Earlier quoted context omitted.
We use readme.io to host our guides and blog. They use angular I believe, so maybe a hiccup on their end? Phoenix itself targets html/form, spa's, and api's alike.
Interesting. Any reason why it's not built with Phoenix? It seems like docs would be a perfect use case for such a framework.
After spending nearly 7 years in the Ruby and Rails ecosystem, I changed jobs and have been working in with Elixir and Phoenix for nearly 3 months. I have been very satisfied with the process. The community is amazing, the tooling is unbeatable, and the quality and availability of open source libraries is great, especially for such a young project. The future looks very bright for Elixir and Phoenix!
That being said, I do miss active_support though; Elixir's utility libraries (fox, pipe, croma, etc.) doesn't yet have all the easy automagic that made rails so simple to develop on.
Slightly off-topic, but can someone familiar with both Elixir and Erlang explain what Elixir provides in comparison to Erlang. I'm looking into using Erlang for a new project that requires extensive scaling and concurrency and am coming from a functional background so may be more comfortable with the traditional Erlang syntax. However it seems that perhaps more development and activity is happening on the Elixir side…
> can someone familiar with both Elixir and Erlang explain what Elixir provides in comparison to Erlang. The syntax is nicer, but that's just a bonus. The real game-changer to me about Elixir vs Erlang is its macro system. This gives you runtime code execution and runtime code generation, similar to what makes LISP to powerful. There's a large amount of boilerplate involved in creating an OTP server, as you know if y…
I've looked at OTP the Elixir way and I do not see any real boilerplate reduction. The application-project dichotomy and the opinionated integration with a tool like Mix is also policy over mechanism.
rebar3 does fine dependency management given its constraints of having to unify packages coming from disparate sources.
The syntax is not nicer. It is a jarring conceptual mismatch to put Smalltalk-ish Ruby syntax over a language that eschews excessive monkey patching and dynamism like Erlang.
Congrats to the Phoenix folks; I'm pretty sure it's the first Elixir framework to hit that 1.0 milestone, and that's a pretty big deal.
Getting to 1.0 is really awesome. Although I have a lot of 'framework fatigue' at this point, what would be really helpful for me would be why this framework is better than the dozen other frameworks along any number of axes, say "time to develop", "spinning up new developers", "obsolecence protection", anything which would provide a compelling story why this instead of Angular or React or Bootstrap or Eve or anythin…
This doesn't compare to the frameworks you mentioned in that regard. It's a framework for the Elixir language, not another JS framework.
Sure it is, but "framework for building apps using language X which is run by virtual machine Y" is the basic pattern for JavaScript, Clojure, Scala, Java, and others. There are a lot of them, they have varying levels of integration.
Can I build a discussion forum in Phoenix? Sure, it has all the tools. Can I build it using PHP or Ruby? Sure those have tools too. Can I create an integrated IDE with my langauge and my execution environment? Sure we can do that too like Light Table.
So is it just Visual Basic all over again? Thinking of it that way is probably not conducive to polite conversation :-) but in many ways it is. We have a scripted language (Elixir), a virtual machine (Erlang), a "window" system (HTML5), and a set of APIs we can call on.
That is great, doesn't solve a new problem but solves an existing problem in a new way. And I watched Chris' talk and read the documentation, and I still don't feel like I have a good feel for why its better than what came before.