On Elixir's identity 1. Language goals
364 views
Skip to first unread message
Alexei Sholik
Apr 9, 2013, 5:19:48 AM4/9/13
to elixir-lang-core
Hello everyone,
In this document, I'm going to take a look at Elixir as a product (with its goals and target audience) and try to start a discussion to try and answer the following questions:
* which goals is it pursuing?
* does it do a good job at it?
* what can be improved?
All the views and opinions here are my own and are not necessarily shared by Elixir authors or other members of the community, although José did take a look at this document before and suggested a few corrections regarding Elixir's goals, and I'd like to thank him for that.
## TL;DR ##
This is a long message. You may prefer to read it on the wiki here -- https://github.com/alco/elixir/wiki/Elixir-Identity
Here are the main points I'm going to discuss in the following sections:
* the need to identify the steps needed to lower the entry barrier to Elixir
* insufficient examples for Elixir's meta-programming features that make it stand out
* lack of code in the wild (libraries and examples)
* hide Erlang from the docs for as long as possible at first so that newcomers can begin building OTP applications with zero knowledge of Erlang
If you're curious about the reasoning behind those points, read on.
I would like to note here the I'm going to be saying things like "we need more docs" or "we need more examples". That's certainly easier said that done, but the purpose of the present document is to make sure we're all on the same page and that we acknowledge that issues discussed here are indeed real issues. The next step will then be to define a set of tasks for Elixir developers and other members of the community to help improve the situation. Those are going to be discussed in a future document.
## Intro
I got to know Elixir about a year ago. Read through the getting started guide, wrote some toy programs. Then I learned the basics of Erlang, contributed a little to Elixir's libraries, docs, and tutorials. This all happened over the course of two month, then I dropped out of Elixir community completely for almost year.
Recently, I've got an opportunity to start playing with the language again. I was glad to discover that it has matured, became rather stable (no significant breaking changes for the last months, maybe even half a year?). The docs got improved too: it's now easy to start a new project or get and build someone else's project using mix. The mailing list and IRC channel got a bit livelier. All in all, Elixir has been growing at a steady pace during the last year.
In this document, I'm going to argue that it could go faster than that. And I don't mean merely growing raw number of users that start learning Elixir (that's the domain of SEO). I'm talking about natural growth of the community that will help the language itself and the ecosystem around it to grow faster on all fronts: core language, documentation, available libraries, projects in production, etc.
After all, that's the ultimate goal of the project -- spread the awareness of its existence and encourage more people to learn and use it for great good. And not only encourage but provide pragmatic reasons and benefits of doing so.
## What is the purpose of Elixir?
So, let us think about just how clearly Elixir states its purpose to new users. Judging from the site, it's meant to provide a different approach to building reliable, concurrent, and distributed systems using Erlang VM as its foundation and, consequently, making OTP more accessible to general audience.
Erlang itself is a niche language. It has very concrete and narrow goals of building highly reliable distributed systems and it implements those goals rather well, judging from general satisfaction of its user base. But the language itself hasn't got much traction in the modern development community, web development in particular because that's the domain that tends to welcome the ability to build highly concurrent and scalable distributed systems, and Erlang has been designed to do just that.
There's a number of reasons for why Erlang ended up where it is, at the moment, let us not worry about that. For the purposes of this document, it's just the way things happened.
What we should be worried about, however, is that Elixir wouldn't end up in a situation where it's used by a handful of people that mostly come from a relatively small Erlang community. Because the intent behind Elixir is to provide the goodness of the Erlang VM and its OTP ecosystem to the mainstream development community. In other words, Elixir aims to open up Erlang's magic box of tricks to a wider audience, in the fashion of what Ruby on Rails did for Ruby.
## Are we moving in the right direction?
Let's talk about Erlang a bit more. It is undeniably what made Elixir's existence possible in the first place. But at the same time it can harm Elixir's adoption among the broader developer audience that Elixir is targeting.
There's really not that much one can do with Elixir alone when it comes to building OTP applications. And not only web applications, there is enough space in software development landscape where Elixir could be a great fit. However, most of the docs are targeting Erlang the language. Many frameworks and libraries are written in Erlang, which by itself is actually one of the things Elixir is striving to achieve -- seamless compatibility with Erlang ecosystem. But it's a fact that there is no comprehensive documentation written specifically for Elixir that would describe how to use cowboy, for instance, or other often recommended libraries. And this is actually hurting Elixir's adoption.
Elixir doesn't fully deliver the promise of a more productive and accessible Erlang/OTP. Accessible for the mainstream community, that is.
## Improving the "getting started" experience
Let's see how we can improve the experience of starting out with Elixir.
Due to its nature, there are two kinds of users coming to Elixir: 1) those who have been using Erlang professionally and know what OTP is and how it helps make their job easier; 2) those who have background in other programming languages, having only heard of or even with no knowledge of Erlang at all.
We'll focus on the second group for the time being. Those who have background in other languages may simply not know much about the properties and advantages of the Erlang VM and niceties Elixir adds on top of that. It is in the best interest of Elixir's authors and community to educate those people and guide them through their first steps with this marvelous language.
### Educating people coming from other languages
The biggest entry barrier for people coming from other languages than Erlang is, paradoxically, the Erlang itself. Although it forms a solid foundation for Elixir, it should not be pitched as Elixir's primary selling point to this group of users. After all, Erlang is a niche language, and Elixir tries to open the Erlang VM/OTP combo to a larger audience. So while Erlang's strong points are recognized by those who are already using it (and they need other reasons for switching to Elixir, see above), to a wider audience outside of Erlang's ecosystem it is not as clear what's this all about.
So what I'm proposing instead is that Erlang should not be exposed to newcomers early in their learning process. In other words, Elixir has to show that it's self-sustainable enough to harvest the power of OTP and build real working applications in it without the need to dive into Erlang. Of course, this doesn't mean dumping cowboy, for instance. But writing a good doc that covers most of cowboy's use cases in Elixir's context and at the same time targets the audience coming to Elixir with zero knowledge of Erlang should definitely be considered.
Here are some bullet points listing the things that would demonstrate Elixir's maturity to be used for development without learning too much of Erlang along the way:
* 1st-class native support for all of the OTP (that's commonly used) in Elixir with comprehensive documentation. Yes, there is GenX which provides a great high-level abstraction on top of OTP behaviors. It's lacking the docs though. At present, our best advice for a novice starting with OTP in Elixir is to go and read the relevant chapters from Learn You Some Erlang. In order to support my arguments above, we need to provide a guide to OTP written specifically for Elixir, using its best practices and providing higher abstractions where it helps understanding and reducing the code size.
* IEx shell being able to do everything erl does and more. It may already do so, sorry if I've missed this fact. But the documentation is mostly that of erl, if I understand correctly. We don't need to replace `man erl`, but we need a guide that would show all the different ways of using IEx with a working app, written with Elixir users in mind.
* Make it easy to add Erlang libs to Elixir project. Just add a line to `mix.exs` and you're good to go. This too might already be implemented. Still, we're lacking in examples that would show how to use commonly recommended Erlang libs in Elixir.
* A comprehensive guide of practical applications of Elixir's features. Getting started guide shows the basics only. We need a guide that would assume the basics have already been learned and would delve into more advanced topics. This is in line with the point I made earlier about demonstrating the goodies of Elixir's macros and protocols to Erlang programmers.
* Examples of doing common tasks in Elixir (like building a web service) and using concurrency with OTP to do them (in the form of talks, articles, code, screencasts). Rob Pike, for example, has done a stellar job presenting many talks that demonstrate Go's concurrency primitives and how they help build reliable concurrent programs with very little effort.
I'd like to mention Dynamo here which is an excellent project to demonstrate exactly how the approach to writing a web service in Elixir is going to be different from that of Erlang's. But it's not finished and not documented enough. To move this project forward, a number of tasks can be defined that will allow newcomers that have found their own motivations to learn Elixir to come and help with Dynamo's progress.
* Lack of libraries written in Elixir that could boast less code that does more or simply better code that is easier to write, read, test, and maintain.
* Lack of real applications out there that could demonstrate Elixir's best practices and serve as role models for others that are only starting with Elixir. I'm not saying there are none (see here[1] for some), but still not many of those.
I'm mostly talking about documentation, because it's critical for newcomers with no background in Erlang or concurrent languages in general. There is still other kind of things Elixir is lacking like pointers to how one can contribute to Elixir as a whole and help grow its ecosystem.
We need an outline of all the different things newcomers can do to help move the project forward. Most of the points above are aimed at attracting users and educating them, but there are also programmers that like to delve straight into the code and figure it out themselves. Those people can help by contributing to the language or its libraries directly, but there's a lack of general guidance for them.
---
Footnotes with links:
[1]: https://github.com/elixir-lang/elixir/wiki/Projects-in-the-wild
## Conclusion
So let us reiterate on the issues present in this document and what we can take out from it.
What's hindering Elixir's adoption?
* Erlang burden. We can't require knowledge of Erlang if we want for Elixir to become popular. In short, learning Elixir shouldn't mean learning Erlang as well. At least, not at first.
* Insufficient examples for Elixir's meta-programming features that make it stand out.
* Little code in the wild (libraries and examples).
* Not clear what to do if I want to contribute.
Elixir has much potential and we still have much room to try harder making more accessible and growing the community. Afterwards, the community will be growing the language (provided that the language becomes stable in the long term and has an enhancement process in place).
Thanks for reading.
--
Best regards
Alexei Sholik
In this document, I'm going to take a look at Elixir as a product (with its goals and target audience) and try to start a discussion to try and answer the following questions:
* which goals is it pursuing?
* does it do a good job at it?
* what can be improved?
All the views and opinions here are my own and are not necessarily shared by Elixir authors or other members of the community, although José did take a look at this document before and suggested a few corrections regarding Elixir's goals, and I'd like to thank him for that.
## TL;DR ##
This is a long message. You may prefer to read it on the wiki here -- https://github.com/alco/elixir/wiki/Elixir-Identity
Here are the main points I'm going to discuss in the following sections:
* the need to identify the steps needed to lower the entry barrier to Elixir
* insufficient examples for Elixir's meta-programming features that make it stand out
* lack of code in the wild (libraries and examples)
* hide Erlang from the docs for as long as possible at first so that newcomers can begin building OTP applications with zero knowledge of Erlang
If you're curious about the reasoning behind those points, read on.
I would like to note here the I'm going to be saying things like "we need more docs" or "we need more examples". That's certainly easier said that done, but the purpose of the present document is to make sure we're all on the same page and that we acknowledge that issues discussed here are indeed real issues. The next step will then be to define a set of tasks for Elixir developers and other members of the community to help improve the situation. Those are going to be discussed in a future document.
## Intro
I got to know Elixir about a year ago. Read through the getting started guide, wrote some toy programs. Then I learned the basics of Erlang, contributed a little to Elixir's libraries, docs, and tutorials. This all happened over the course of two month, then I dropped out of Elixir community completely for almost year.
Recently, I've got an opportunity to start playing with the language again. I was glad to discover that it has matured, became rather stable (no significant breaking changes for the last months, maybe even half a year?). The docs got improved too: it's now easy to start a new project or get and build someone else's project using mix. The mailing list and IRC channel got a bit livelier. All in all, Elixir has been growing at a steady pace during the last year.
In this document, I'm going to argue that it could go faster than that. And I don't mean merely growing raw number of users that start learning Elixir (that's the domain of SEO). I'm talking about natural growth of the community that will help the language itself and the ecosystem around it to grow faster on all fronts: core language, documentation, available libraries, projects in production, etc.
After all, that's the ultimate goal of the project -- spread the awareness of its existence and encourage more people to learn and use it for great good. And not only encourage but provide pragmatic reasons and benefits of doing so.
## What is the purpose of Elixir?
So, let us think about just how clearly Elixir states its purpose to new users. Judging from the site, it's meant to provide a different approach to building reliable, concurrent, and distributed systems using Erlang VM as its foundation and, consequently, making OTP more accessible to general audience.
Erlang itself is a niche language. It has very concrete and narrow goals of building highly reliable distributed systems and it implements those goals rather well, judging from general satisfaction of its user base. But the language itself hasn't got much traction in the modern development community, web development in particular because that's the domain that tends to welcome the ability to build highly concurrent and scalable distributed systems, and Erlang has been designed to do just that.
There's a number of reasons for why Erlang ended up where it is, at the moment, let us not worry about that. For the purposes of this document, it's just the way things happened.
What we should be worried about, however, is that Elixir wouldn't end up in a situation where it's used by a handful of people that mostly come from a relatively small Erlang community. Because the intent behind Elixir is to provide the goodness of the Erlang VM and its OTP ecosystem to the mainstream development community. In other words, Elixir aims to open up Erlang's magic box of tricks to a wider audience, in the fashion of what Ruby on Rails did for Ruby.
## Are we moving in the right direction?
Let's talk about Erlang a bit more. It is undeniably what made Elixir's existence possible in the first place. But at the same time it can harm Elixir's adoption among the broader developer audience that Elixir is targeting.
There's really not that much one can do with Elixir alone when it comes to building OTP applications. And not only web applications, there is enough space in software development landscape where Elixir could be a great fit. However, most of the docs are targeting Erlang the language. Many frameworks and libraries are written in Erlang, which by itself is actually one of the things Elixir is striving to achieve -- seamless compatibility with Erlang ecosystem. But it's a fact that there is no comprehensive documentation written specifically for Elixir that would describe how to use cowboy, for instance, or other often recommended libraries. And this is actually hurting Elixir's adoption.
Elixir doesn't fully deliver the promise of a more productive and accessible Erlang/OTP. Accessible for the mainstream community, that is.
## Improving the "getting started" experience
Let's see how we can improve the experience of starting out with Elixir.
Due to its nature, there are two kinds of users coming to Elixir: 1) those who have been using Erlang professionally and know what OTP is and how it helps make their job easier; 2) those who have background in other programming languages, having only heard of or even with no knowledge of Erlang at all.
We'll focus on the second group for the time being. Those who have background in other languages may simply not know much about the properties and advantages of the Erlang VM and niceties Elixir adds on top of that. It is in the best interest of Elixir's authors and community to educate those people and guide them through their first steps with this marvelous language.
### Educating people coming from other languages
The biggest entry barrier for people coming from other languages than Erlang is, paradoxically, the Erlang itself. Although it forms a solid foundation for Elixir, it should not be pitched as Elixir's primary selling point to this group of users. After all, Erlang is a niche language, and Elixir tries to open the Erlang VM/OTP combo to a larger audience. So while Erlang's strong points are recognized by those who are already using it (and they need other reasons for switching to Elixir, see above), to a wider audience outside of Erlang's ecosystem it is not as clear what's this all about.
So what I'm proposing instead is that Erlang should not be exposed to newcomers early in their learning process. In other words, Elixir has to show that it's self-sustainable enough to harvest the power of OTP and build real working applications in it without the need to dive into Erlang. Of course, this doesn't mean dumping cowboy, for instance. But writing a good doc that covers most of cowboy's use cases in Elixir's context and at the same time targets the audience coming to Elixir with zero knowledge of Erlang should definitely be considered.
Here are some bullet points listing the things that would demonstrate Elixir's maturity to be used for development without learning too much of Erlang along the way:
* 1st-class native support for all of the OTP (that's commonly used) in Elixir with comprehensive documentation. Yes, there is GenX which provides a great high-level abstraction on top of OTP behaviors. It's lacking the docs though. At present, our best advice for a novice starting with OTP in Elixir is to go and read the relevant chapters from Learn You Some Erlang. In order to support my arguments above, we need to provide a guide to OTP written specifically for Elixir, using its best practices and providing higher abstractions where it helps understanding and reducing the code size.
* IEx shell being able to do everything erl does and more. It may already do so, sorry if I've missed this fact. But the documentation is mostly that of erl, if I understand correctly. We don't need to replace `man erl`, but we need a guide that would show all the different ways of using IEx with a working app, written with Elixir users in mind.
* Make it easy to add Erlang libs to Elixir project. Just add a line to `mix.exs` and you're good to go. This too might already be implemented. Still, we're lacking in examples that would show how to use commonly recommended Erlang libs in Elixir.
* A comprehensive guide of practical applications of Elixir's features. Getting started guide shows the basics only. We need a guide that would assume the basics have already been learned and would delve into more advanced topics. This is in line with the point I made earlier about demonstrating the goodies of Elixir's macros and protocols to Erlang programmers.
* Examples of doing common tasks in Elixir (like building a web service) and using concurrency with OTP to do them (in the form of talks, articles, code, screencasts). Rob Pike, for example, has done a stellar job presenting many talks that demonstrate Go's concurrency primitives and how they help build reliable concurrent programs with very little effort.
I'd like to mention Dynamo here which is an excellent project to demonstrate exactly how the approach to writing a web service in Elixir is going to be different from that of Erlang's. But it's not finished and not documented enough. To move this project forward, a number of tasks can be defined that will allow newcomers that have found their own motivations to learn Elixir to come and help with Dynamo's progress.
* Lack of libraries written in Elixir that could boast less code that does more or simply better code that is easier to write, read, test, and maintain.
* Lack of real applications out there that could demonstrate Elixir's best practices and serve as role models for others that are only starting with Elixir. I'm not saying there are none (see here[1] for some), but still not many of those.
I'm mostly talking about documentation, because it's critical for newcomers with no background in Erlang or concurrent languages in general. There is still other kind of things Elixir is lacking like pointers to how one can contribute to Elixir as a whole and help grow its ecosystem.
We need an outline of all the different things newcomers can do to help move the project forward. Most of the points above are aimed at attracting users and educating them, but there are also programmers that like to delve straight into the code and figure it out themselves. Those people can help by contributing to the language or its libraries directly, but there's a lack of general guidance for them.
---
Footnotes with links:
[1]: https://github.com/elixir-lang/elixir/wiki/Projects-in-the-wild
## Conclusion
So let us reiterate on the issues present in this document and what we can take out from it.
What's hindering Elixir's adoption?
* Erlang burden. We can't require knowledge of Erlang if we want for Elixir to become popular. In short, learning Elixir shouldn't mean learning Erlang as well. At least, not at first.
* Insufficient examples for Elixir's meta-programming features that make it stand out.
* Little code in the wild (libraries and examples).
* Not clear what to do if I want to contribute.
Elixir has much potential and we still have much room to try harder making more accessible and growing the community. Afterwards, the community will be growing the language (provided that the language becomes stable in the long term and has an enhancement process in place).
Thanks for reading.
--
Best regards
Alexei Sholik
Patrick Mulder
Apr 9, 2013, 7:28:54 AM4/9/13
to elixir-l...@googlegroups.com
Hi Alexei,
interesting write up.
* What I like on Elixir is the promise of easy access to the patterns of distributed systems from Erlang. Ruby-on-Rails is well known for MVC (application-controller/frontend controllers combined with ActiveRecord), and Erlang/OTP has this nice idea of 'let it fail'. I am not sure if I would look at Elxir/Dynamo for a Ruby-on-Rails replacement, but just as a better solution to transaction sensitive services, e.g. in API use cases.
* Evt. it is helpful to discuss a bit the pro/cons of other possibles competitors too: Go lang ( http://golang.org/ ) and https://github.com/celluloid/celluloid (also the issues with Celuloid might be interesting: https://github.com/celluloid/celluloid/issues ). Also, I wonder if NodeJS has similar discussions going on.
Hope this input helps.
Patrick
--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Jeremy Huffman
Apr 10, 2013, 8:13:26 PM4/10/13
to elixir-l...@googlegroups.com
I think Elixir can eventually develop an ecosystem that would make it possible to "shield" newcomers from Erlang, but right now that is so far away it doesn't really seem worth talking about it yet. Those people are not going to bootstrap this ecosystem and write the libraries and docs needed to engage the masses. To me a more useful question is "how do we get more of the enthusiasts that will help bootstrap the community?" They don't have to come from Erlang. I learned Erlang at the same time I learned Elixir and it was no more difficult that way than learning any single language by itself. I'm sure most people would be sceptical of that though, so it is kind of a tough sell.
Erlang probably strikes a lot of people as being very dogmatic: absolutely no mutability. Most programmers really cannot conceive of useful programs without mutability. Once you understand how that sort of thing works in practice then that is no longer such a big deal. And suddenly gen_server seems brilliant because it manages state without breaking this rule. Actors are not so different from objects in many respects. 
Dave Thomas
Apr 10, 2013, 8:39:10 PM4/10/13
to elixir-l...@googlegroups.com
But once you appreciate FP, once you become fixated on solving problems of concurrency, once you decide you need a stable and reliable platform to provide that and that you want a language that is dynamically typed, friendly and fun you are almost completely out of options and for me at least, there is already enough of a case to be made that Elixir is the best one.
That feels like a somewhat defensive argument to me. I'd put it differently.
It's clear (to me, at least) that the idea of programming is not longer the art of maintaining state. Instead, we're moving towards coding as a means of transforming state. Object Orientation has served us well with state-based programming. But now we need to move on.
Some folks label this new style "functional programming". I don't like the moniker. Partly it's because functional programming paradigms to date have all been too abstract—almost mathematical—and dogmatic. Haskell is a cool language, but the fact that no one has been able to produce an accessible book on it says to me that it is not right for real world use. I also don't like "functional programming" as a name because there is definitely a role for state mutation in the problems we face every day; and the solution isn't monads. That's where the Erlang server approach appeals to me—wrap the state in a separate process and interact with it via pure messages.
So I feel that Elixir embodies much of what I see to be the future of programming. Erlang abstractions clearly leak through, but at the same time that is clearly a manageable issue long term.
My experience with Ruby is that the early adopters don't mind rough edges. In fact, they rather like them, as it gives them something to work on. And, along the way, those folks will help to develop the idioms and libraries that make the language accessible to more and more people.
So I don't think you can plan for world domination. Instead, I think you have to stay true to your values, implement accordingly, and respond to the feedback you get. If your vision is good, and your implementation reflects it, then folks will come.
Dave
Jeremy Huffman
Apr 10, 2013, 9:12:32 PM4/10/13
to elixir-l...@googlegroups.com
My experience with Ruby is that the early adopters don't mind rough edges. In fact, they rather like them, as it gives them something to work on. And, along the way, those folks will help to develop the idioms and libraries that make the language accessible to more and more people.
So I don't think you can plan for world domination. Instead, I think you have to stay true to your values, implement accordingly, and respond to the feedback you get. If your vision is good, and your implementation reflects it, then folks will come.
Yes, this is very much how I feel and you said it much better than me. You should be a writer :)
Simon St.Laurent
Apr 11, 2013, 6:18:03 AM4/11/13
to elixir-l...@googlegroups.com, da...@pragprog.com
Finding this paragraph waiting in my inbox has made getting up early to work on Elixir all the more valuable.
On Wednesday, April 10, 2013 8:39:10 PM UTC-4, Dave Thomas wrote:
It's clear (to me, at least) that the idea of programming is not longer the art of maintaining state. Instead, we're moving towards coding as a means of transforming state. Object Orientation has served us well with state-based programming. But now we need to move on.
Thank you for phrasing that so cleanly! I've been stumbling through various iterations of the same story. That is perfect, the opening of a much larger conversation.
So I feel that Elixir embodies much of what I see to be the future of programming. Erlang abstractions clearly leak through, but at the same time that is clearly a manageable issue long term.My experience with Ruby is that the early adopters don't mind rough edges. In fact, they rather like them, as it gives them something to work on. And, along the way, those folks will help to develop the idioms and libraries that make the language accessible to more and more people.
There are rough edges, and then there are rough edges. Or perhaps it's that there are different categories of early adopters.
Elixir may not be finished yet, but except for the error messages, it seems to me like it's finished enough to be exciting to a broad audience.
(To those in the "who cares about error message camp? Erlang barely had them and it was great!" camp, you are a different kind of early adopter than I am...)
Thanks,
--
Simon St.Laurent
http://simonstl.com/
Simon St.Laurent
Apr 11, 2013, 7:03:29 AM4/11/13
to elixir-l...@googlegroups.com
I'm very pleased to see conversation and concern about how to bring a wide variety of people into Elixir.
I wrote Introducing Erlang partly because the features of the language were powerful and intriguing, but also because Erlang seemed much more explainable that many of its competitors. Loose typing and relatively few choices to make within the language itself were big pluses. Because the existing books were aimed at audiences with far more programming ability (and that is most of who comes to Erlang), there seemed to be a nice opening for a _very_ basic text.
Then I found Elixir. At first it seemed like it might be fun to translate Introducing Erlang, but it quickly proved more than a simple conversion, at least in the opening chapters. Mostly that is because languages are never as similar as they might seem on the surface, and Elixir often offers more ways to do things than Erlang. It's not easy to choose among those ways to present a coherent introduction to people whose programming experience may be minimal.
Introducing Elixir is in progress, however - not yet formally announced, but approved by O'Reilly (my employer), and with J. David Eisenberg (Etudes for Erlang, SVG Essentials) providing tremendous help. I'm guessing and hoping that Dave Thomas' presence here means that the Pragmatic Programmers also have something in the works, or are at least considering it. Hopefully the first few book-length tutorials, whatever their source, will offer enough options to various kinds of beginners to give Elixir something of a jumpstart.
On Tuesday, April 9, 2013 5:19:48 AM UTC-4, alco wrote:
I hope Elixir morphs less rapidly than Rails, but yes, absolutely. I got excited about functional programming because it clearly addresses programming pain that a lot of people suffer. It's not precisely new technology, more like Old Magic. However, Elixir puts a more familiar face on that magic and offers an additional layer of abstraction.
It might be. It's certainly made writing Introducing Elixir trickier, because it's not very possible to write it without mentioning Erlang. Anything beyond simple calculations, of course, requires the Erlang math library. I don't think Elixir needs its own version of math.pi(), but it does mean that I have to say a bit about where it comes from and how to get to other similar things.
It can't yet. It's early. Documentation is unfortunately less popular a project than programming, at least to programmers, and the prospect of writing a second set of docs in a language that's substantially different and not yet broadly adopted... yeah. I can see where that might take people a while to get going.
Yes. I think (1) is easier - so far as I can tell the folks who use Erlang professionally are both especially bright and reasonably flexible. Many of them will stay in Erlang, but the ones who come over shouldn't have too rough a time.
Actually, I'd even go further. Background in other languages may in fact be a disadvantage, making it harder to adapt to the process-oriented approach and the discipline of functional design. I didn't start out intending Introducing Erlang to be an introduction to programming, but I quickly found that making comparisons to other languages created its own problems.
Overall, though, you're right. First steps are important.
Partly. It would be great to have Elixir-only cowboy docs without the distraction of bouncing back and forth through Erlang. At the same time, though, the presence of Erlang needs to be acknowledged to get things done. Once readers can get through a few examples of math.pi() becoming :math.pi, they can deal with at least the simple cases.
(I am greatly relieved that Elixir chose its own path on strings in particular, though...)
The Erlang shell is a strange mix of brilliant and limited Given the amount of praise I've heard lately heaped on REPLs and command lines generally, there's an opportunity to make Elixir more accessible as an environment as well as a language.
There's definitely more to be done. I don't at all want to say "rest on your laurels", but what is there so far is a great start. I'm wondering if it might make sense to have these pieces together in time for the 1.0 release, whenever that may be?
Thanks,
Simon St.Laurent
http://simonstl.com
I wrote Introducing Erlang partly because the features of the language were powerful and intriguing, but also because Erlang seemed much more explainable that many of its competitors. Loose typing and relatively few choices to make within the language itself were big pluses. Because the existing books were aimed at audiences with far more programming ability (and that is most of who comes to Erlang), there seemed to be a nice opening for a _very_ basic text.
Then I found Elixir. At first it seemed like it might be fun to translate Introducing Erlang, but it quickly proved more than a simple conversion, at least in the opening chapters. Mostly that is because languages are never as similar as they might seem on the surface, and Elixir often offers more ways to do things than Erlang. It's not easy to choose among those ways to present a coherent introduction to people whose programming experience may be minimal.
Introducing Elixir is in progress, however - not yet formally announced, but approved by O'Reilly (my employer), and with J. David Eisenberg (Etudes for Erlang, SVG Essentials) providing tremendous help. I'm guessing and hoping that Dave Thomas' presence here means that the Pragmatic Programmers also have something in the works, or are at least considering it. Hopefully the first few book-length tutorials, whatever their source, will offer enough options to various kinds of beginners to give Elixir something of a jumpstart.
On Tuesday, April 9, 2013 5:19:48 AM UTC-4, alco wrote:
What we should be worried about, however, is that Elixir wouldn't end up in a situation where it's used by a handful of people that mostly come from a relatively small Erlang community. Because the intent behind Elixir is to provide the goodness of the Erlang VM and its OTP ecosystem to the mainstream development community. In other words, Elixir aims to open up Erlang's magic box of tricks to a wider audience, in the fashion of what Ruby on Rails did for Ruby.
I hope Elixir morphs less rapidly than Rails, but yes, absolutely. I got excited about functional programming because it clearly addresses programming pain that a lot of people suffer. It's not precisely new technology, more like Old Magic. However, Elixir puts a more familiar face on that magic and offers an additional layer of abstraction.
There's really not that much one can do with Elixir alone when it comes to building OTP applications. And not only web applications, there is enough space in software development landscape where Elixir could be a great fit. However, most of the docs are targeting Erlang the language. Many frameworks and libraries are written in Erlang, which by itself is actually one of the things Elixir is striving to achieve -- seamless compatibility with Erlang ecosystem. But it's a fact that there is no comprehensive documentation written specifically for Elixir that would describe how to use cowboy, for instance, or other often recommended libraries. And this is actually hurting Elixir's adoption.
It might be. It's certainly made writing Introducing Elixir trickier, because it's not very possible to write it without mentioning Erlang. Anything beyond simple calculations, of course, requires the Erlang math library. I don't think Elixir needs its own version of math.pi(), but it does mean that I have to say a bit about where it comes from and how to get to other similar things.
Elixir doesn't fully deliver the promise of a more productive and accessible Erlang/OTP. Accessible for the mainstream community, that is.
It can't yet. It's early. Documentation is unfortunately less popular a project than programming, at least to programmers, and the prospect of writing a second set of docs in a language that's substantially different and not yet broadly adopted... yeah. I can see where that might take people a while to get going.
## Improving the "getting started" experience
Let's see how we can improve the experience of starting out with Elixir.
Due to its nature, there are two kinds of users coming to Elixir: 1) those who have been using Erlang professionally and know what OTP is and how it helps make their job easier; 2) those who have background in other programming languages, having only heard of or even with no knowledge of Erlang at all.
Yes. I think (1) is easier - so far as I can tell the folks who use Erlang professionally are both especially bright and reasonably flexible. Many of them will stay in Erlang, but the ones who come over shouldn't have too rough a time.
We'll focus on the second group for the time being. Those who have background in other languages may simply not know much about the properties and advantages of the Erlang VM and niceties Elixir adds on top of that. It is in the best interest of Elixir's authors and community to educate those people and guide them through their first steps with this marvelous language.
Actually, I'd even go further. Background in other languages may in fact be a disadvantage, making it harder to adapt to the process-oriented approach and the discipline of functional design. I didn't start out intending Introducing Erlang to be an introduction to programming, but I quickly found that making comparisons to other languages created its own problems.
Overall, though, you're right. First steps are important.
So what I'm proposing instead is that Erlang should not be exposed to newcomers early in their learning process. In other words, Elixir has to show that it's self-sustainable enough to harvest the power of OTP and build real working applications in it without the need to dive into Erlang. Of course, this doesn't mean dumping cowboy, for instance. But writing a good doc that covers most of cowboy's use cases in Elixir's context and at the same time targets the audience coming to Elixir with zero knowledge of Erlang should definitely be considered.
Partly. It would be great to have Elixir-only cowboy docs without the distraction of bouncing back and forth through Erlang. At the same time, though, the presence of Erlang needs to be acknowledged to get things done. Once readers can get through a few examples of math.pi() becoming :math.pi, they can deal with at least the simple cases.
(I am greatly relieved that Elixir chose its own path on strings in particular, though...)
* IEx shell being able to do everything erl does and more. It may already do so, sorry if I've missed this fact. But the documentation is mostly that of erl, if I understand correctly. We don't need to replace `man erl`, but we need a guide that would show all the different ways of using IEx with a working app, written with Elixir users in mind.
The Erlang shell is a strange mix of brilliant and limited Given the amount of praise I've heard lately heaped on REPLs and command lines generally, there's an opportunity to make Elixir more accessible as an environment as well as a language.
I'm mostly talking about documentation, because it's critical for newcomers with no background in Erlang or concurrent languages in general. There is still other kind of things Elixir is lacking like pointers to how one can contribute to Elixir as a whole and help grow its ecosystem.
We need an outline of all the different things newcomers can do to help move the project forward. Most of the points above are aimed at attracting users and educating them, but there are also programmers that like to delve straight into the code and figure it out themselves. Those people can help by contributing to the language or its libraries directly, but there's a lack of general guidance for them.
There's definitely more to be done. I don't at all want to say "rest on your laurels", but what is there so far is a great start. I'm wondering if it might make sense to have these pieces together in time for the 1.0 release, whenever that may be?
Thanks,
Simon St.Laurent
http://simonstl.com
Alexei Sholik
Apr 11, 2013, 4:37:36 PM4/11/13
to elixir-lang-core
Thanks everyone for your input!
At the same time, I'm not trying initiate some kind of marketing plan to achieve that. What I'm proposing instead is to consolidate our energy and efforts to help Elixir improve faster while still doing what we like doing. In short, we need a roadmap. When I first came to Elixir a year ago, it wasn't clear how exactly one could contribute to it. And it's not much clearer today either.
By writing down things that are needed or are nice to have, we will get a better picture of the direction the project is moving in and of ways to help it on its way. And it doesn't mean we will start assigning specific tasks to do specific things to achieve the ultimate mind domination in the end. That's definitely not what it's all about, roadmap is just a good thing to have, to be able to look at it from time to time.
Say, I'm feeling like writing some Elixir code today. I could go to a page with a list of libraries that we have put together and start coding away. I would have fun and help Elixir at the same time.
Ideas for GSoC are a great starting point, by the way. We could wait for students to tackle some tasks, but I think it'll be perfectly fine for anyone to choose a task they're interested in and start hacking away.
Thanks again for your comments, everyone. Really appreciate the community that has formed around the language.
--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Alexei Sholik
Apr 11, 2013, 4:40:19 PM4/11/13
to elixir-lang-core
> I'm guessing and hoping that Dave Thomas' presence here means that the
Pragmatic Programmers also have something in the works, or are at least
considering it.
Dave simply loves playing with languages :) The one thing his presence implies for sure is that he's having fun with Elixir. Like all of us here.
Patrick Mulder
Apr 11, 2013, 4:52:38 PM4/11/13
to elixir-l...@googlegroups.com
On Thu, Apr 11, 2013 at 10:40 PM, Alexei Sholik <alcos...@gmail.com> wrote:
Dave simply loves playing with languages :) The one thing his presence implies for sure is that he's having fun with Elixir. Like all of us here.> I'm guessing and hoping that Dave Thomas' presence here means that the Pragmatic Programmers also have something in the works, or are at least considering it.
Yes, agree! Playing is what lot of programming is about. Also, on a side-note, the first publication of Ruby must have been around 199. Rails in around 2005, and my personal first realy 'wow' effect on Rails should have been around 2008, and Heroku helped a lot in that.
For me, the 'wow' effect in Elixir is that distributed nodes can so easily talk to each other. Now, in a second stage, I really love how processes can exit with exceptions in Erlang, and it will not bring down the whole system. This is really a new kind of processing we are entering, and I am looking forward for the discoveries that will be made.
Reply all
Reply to author
Forward
0 new messages