I've certainly enjoyed Elixir as an nth programming language and the idea of Elixir as a 1st programming language is really interesting.
I know I've seen at least one educator in the community speculate that Elixir (or FP languages in general) could potentially make great 1st programming languages because they're often conceptually easier than OOP languages and in many ways the difficulties people associate with learning them come from the difficulty of unlearning some of the things they already know.
I have first hand experience with this actually...
Over the last 6 months or so a good friend of mine has learned to code from scratch. After much deliberation I took a gamble and set him up with Elixir as his first language (largely because he wanted to code so he can work with me on some projects, which use Elixir).
I am really happy with this choice and so is he. Elixir is a language with very consistent ideas throughout and I think concepts like functional transformations, immutability, pattern matching and actor based concurrency are both extremely useful to learn early and very accessible to beginners in Elixir.
Edit:
I didn't think of it when I wrote this comment, but I think the single most helpful thing for beginners (and me!) in Elixir, is the 'h' function. If you run it with any function as an argument in iex (Elixir's repl) you'll get documentation and an example of how to use that function:
iex(2)> h Enum.map
def map(enumerable, fun)
Returns a list where each item is the result of invoking fun on each
corresponding item of enumerable.
For maps, the function expects a key-value tuple.
## Examples
iex> Enum.map([1, 2, 3], fn(x) -> x * 2 end)
[2, 4, 6]
iex> Enum.map([a: 1, b: 2], fn({k, v}) -> {k, -v} end)
[a: -1, b: -2]
I find it an interesting idea too. I mentor people at Culture Amp in Ruby and Elixir and I'm definitely finding Elixir easier to teach for a couple of main reasons:
* It's Just Functions And Data™
* Inheritance isn't a thing
* Functions either come from within the same module if they don't have a module prefix
* Functions from other modules _must_ have a module prefix.
* Immutability, immutability, immutability.
It just _feels_ like there's less to learn with Elixir (foundational wise) than Ruby. It's been pretty nice.
When I went to university for CS, Haskell was used in the introductory programming courses and this was one of the main reasons we were told about.
Another goal was to take the people who had been learning to code in their spare time and put them on more even footing with those who were totally new, force them to think about things from first principles rather than lean on acquired habits, etc.
I had already been coding for a long time by that point but it was the first time I saw a functional language and I think it addressed both goals very well.
I've actually been discussing this with a couple of people within the community. Been hacking with Elixir for a bit, and in an effort to teach it to people around me who've never programmed I've started compiling my notes into a book.
Would love to share it here in a bit when I have some time to finish things up and get some feedback.
I will say, writing from the perspective of it being one's first language is really interesting, because you just can't assume anything.
While I applaud creating documentation, books, and guides for those new to the language, there's still a significant accessibility gap in resources. I already know the language, I've already done some basic stuff in phoenix, I've even made my own HTTP API wrapper as its own library. But when it comes to architecting backend systems that aren't tied to phoenix or playing around with IEx, I really feel like I am on my own.
There are erlang books, of which I am reading, though it feels like there's always emphasis on history for backwards compatibility and the other warts that Erlang has with its age. I'd like to design reliable systems that operate outside of the classic HTTP -> Elixir -> Database pattern. Things that involve working in memory, processing queues, managing sessions and state, patterns for fallbacks and breakers for services, and so on, that is where I seek more content.
Unfortunately I hear the big BEAM player around, Basho, is shutting the lights--so I can't expect to witness the wonderful presentations their engineers provide at conferences or through recordings of such conferences.
I'm actually working on a book which I think covers a lot of what you're looking for (and was what I wanted back when I got started with Elixir a few years ago). I'm covering architectural patterns for the items you mentioned as well as flow control and digging in deep on how to really leverage the fault isolation mechanisms of OTP. I'm the maintainer of Distillery, the release tooling in Elixir, so I'm also covering a lot of the gritty details involved there, such as how to work with hot upgrades and such, as well as dealing with issues in production using some of the excellent operational tooling available.
Unfortunately I probably won't be done until the end of this month, but if you're interested, keep an eye out on ElixirForum.com, since I'll announce it there when it's available.
I feel that Erlang adoption is probably the most realistic growth path for most serious Elixir developers. All of these topics you mentioned (breakers, message routing, etc) have been discussed and developed in the Erlang community for years. The only new thing that Elixir brings to the table in these areas is abstraction and syntax - both of which are arguably not needed in large complex systems.
Source: full-time Erlang developer of 7 years who spent a full year coding Elixir in its v1.0.x days
Definitely recommend reading "The Little Elixir & OTP Guidebook"
The focus of the book sounds like pretty much what you're asking for. The first few chapters cover Elixir basics, but its really just a primer -- easily skippable if you already know it. Starts with implementing OTP features from scratch so you can see what they do and why they exist, then dives into how to do it using OTP.
> I'd like to design reliable systems that operate outside of the classic HTTP -> Elixir -> Database pattern.
Then use Erlang. I like and prefer Erlang to Elixir for example. It has a simpler syntax, it's consistent just like Elixir. And you'd be surprised that Erlang for being what 30 years old is being regularly updated and improved Most importantly things are deprecated regularly from the the language and the standard library, as new stuff is added. That's how it managed to still say small and simple. Plus you'll get a lot of resources and reference already created for it.
If you like Elixir, start with it as so many concepts overlap and then you'd pick the Erlang syntax and some conventions later without that much hassle.
is there any news recently about Elixir? I'm asking since recently Im seeing a lot of articles about how to get into Elixir which is really nice since I just started pickup the language as well.
Erlang/OTP 20.0, Elixir 1.5 and Phoenix framework 1.3 were all released in a timespan of 2 months or so - huge improvements to the already great ecosystem.
I've spent the last year building[1] an open source side project with elixir and phoenix. It's honestly been a pleasure to work with once you get over some of the initial hurdles.
I happened to mention interest in Elixir on my LinkedIn page, and now I get hit up by recruiters for it every so often, so it seems so. I haven't heard too much outside of this personal anecdote, however.
At the london meetup last week, when ask if their company recruit and search for elixir devs, everyone raised their hands. Approx 60 to 80 devs. So probably 20 to 30 company....
Ryan Bigg (github: https://github.com/radar) has been active in the Ruby community for years (and is seriously intelligent, at least based on his many past IRC responses to my Ruby questions, assuming he's also named Radar on there), has apparently been working with Elixir on the side for a while, and IMHO can definitely handle an Elixir book intended for new programmers. He would be a very significant asset to the community were he to jump ship and go fulltime Elixir.
Your skepticism (which is otherwise probably warranted) is quite wrong in this case. I'm sorry if someone defecated into your Cheerios this morning, though.
Sometimes the best way to learn is to teach, and sometimes the best way to teach is to make money teaching. :P
Hi. Nice to meet you. Clearly you know who I am, but I am not sure who you are. Care to inform me? Maybe we've met before. Commenting anonymously in a venemous way like this is surely below someone like you. Come out of the shadows and come and play with me. This'll be fun!
----
The book is released for free, however I charge for the PDF because it takes time + energy to generate that (and typesetting, omg) _and_ it gives people a way to financially support the project (if they want to).
Joy of Elixir will _always_ be free because I think having the bar of entry as low as possible for newbie programmers is a nice thing to do. As I say on Joy of Elixir's about page, I want this book to be the equivalent to Learn to Program, but for Elixir. So in that same vein, it will always be free.
---
Regarding my Elixir experience: I have been happily using it for two years "for fun" and one year in production _almost_ full-time. I have built several parts of my workplace's microservice's architecture using Elixir in a small team of Elixir developers. I've learned a crap load and made some frankly _awesome_ mistakes.
In the last four months I've started mentoring a junior developer in the ways of Elixir and that's what led me down this path of writing a book directed at newbie developers.
---
Brown-nosing on IRC? Hardly. I've been active on Freenode #rubyonrails for at least 10 years and #elixir-lang on-and-off for at least the past 2.
> IMHO someone which actually contributes high quality libraries or code to said community should be valued more, yet these are usually the last people you would ever see slapping their name on a book. They are happy to just improve the existing documentation and contribute that way.
I wrote https://github.com/radar/elastic. Sorry if this is not up to your high-quality bar. Patches welcome. Open source is great, yeah?
And by the way: I am strongly (so strongly) in the camp of documentation being more important than the code itself. For without documentation, who can understand how to use the code? Who can understand the _reasons_ behind the code?
---
> This is all just A self promotional stunts. The author has done this before in the Rails community.
I started contributing documentation fixes / entire guides to the Rails community in 2008. I started using Rails in 2004. I felt it was one of the best ways that I could possibly give back to the community that has kept me very, very safely employed since 2006. 543 commits to Rails, at least: http://contributors.rubyonrails.org/contributors/ryan-bigg/c.... All for free.
In terms of self-promotional work, I spent at least two years of my free time writing books. Probably closer to three, but let's not brag too much. And yes, I _do_ use the books I wrote for self-promotion. It would be pretty ridiculous to spend all that time writing a book, selling it and then _not_ using them for self-promotion, dontyathink? I use them as more of an example of what I am capable of teaching people, more than "hey, look at how STUPENDOUSLY AMAZING I AM". Although, I admit, sometimes I act that way too.
---
Anyway, it's been nice rebuffing your attacks today. I'm very happy to continue to play this game for as long as you wish. I guarantee you I have more patience.
And I implore you again: come out from the shadows, little troll.
Yup, sorry about that! I am a _horrible_ artist and so I'm hoping to rope a good friend of mine in to help with that. He's recently started a new job and so he's been busy. One day there'll be some great images in the book.
It does if you are an absolute beginner to programming. If you are already seasoned then yes it doesn't add much, it just means you aren't the target audience.
> They are setting up their users for disillusionment and disappointment.
There's nothing wrong with communities promoting themselves. If people don't know about your thing, they can't try it to make their own decisions about whether or not it is worth using.
And it isn't yours or a community leader's or a maintainer's job to protect users from disillusionment and disappointment. If someone actually has a hard fall from realizing that a programming language isn't as great as people said it might be, there are way bigger issues there than the programming language at play -- on the side of the disillusioned, not the language/community.
I too feel there is a generational hype cycle at HN. However, I don't see much in the way of "language N sucks" as a precursor to "everyone should use language N1!" Maybe I am just blind to the negativity, but in general, what I see with each hype generation is only the positive side: "everyone should use language N1!"
I suspect with any given hype generation—with each trending language—we're going to see a lot of positive messaging as the fans up-vote articles pertaining to the new hotness. Meanwhile, those who disagree (or simply don't care) probably don't see much value in taking the time to evangelize their disagreement. I'm not upvoting Elixir content, but I'm certainly not going to downvote it either. Why should I care if other people enjoy a platform I don't care about? Good for them!
Also, perhaps as everyone is hyping language N1, those who are using N are simply too busy using N and making a living to keep layering on the hype.
don't understand why you got downvoted, it's a pretty legitimate concern.
You may however see the whole thing a bit differently :
- node popularized single loop event on the server side, which is great for fast low cpu request processing
- go evangelized simple design, coroutines , unique code formating, and has arguably one of the best stdlib. That's still true today and it's great
- Rust made people realize writing concurrent truelt safe code was possible. Huge advance.
- Elixir helped the community focus again on actor + message passing concurrency. It's fantastic.
All of those concepts are beneficial to learn, for you as a programmer, no matter which language you use.
If for example look at swift evolution, you'll see the current threading model (based on event loops, like node, because of iOS) discussed and compared to the actor model ( like erlang / elixir), but also that some web framework reimplemented go-style concurrency.
You'll also see that they're talking about adding semantic for detecting memory sharing patterns (much like rust).
If you've followed all the discussions on those languages for the last two years you know exactly why those conversations are taking places. So all in all it's a good thing communities are advocating the strenghts of their language. It helps everyone improve.
[+] [-] adamkittelson|8 years ago|reply
I know I've seen at least one educator in the community speculate that Elixir (or FP languages in general) could potentially make great 1st programming languages because they're often conceptually easier than OOP languages and in many ways the difficulties people associate with learning them come from the difficulty of unlearning some of the things they already know.
[+] [-] zensavona|8 years ago|reply
Over the last 6 months or so a good friend of mine has learned to code from scratch. After much deliberation I took a gamble and set him up with Elixir as his first language (largely because he wanted to code so he can work with me on some projects, which use Elixir).
I am really happy with this choice and so is he. Elixir is a language with very consistent ideas throughout and I think concepts like functional transformations, immutability, pattern matching and actor based concurrency are both extremely useful to learn early and very accessible to beginners in Elixir.
Edit:
I didn't think of it when I wrote this comment, but I think the single most helpful thing for beginners (and me!) in Elixir, is the 'h' function. If you run it with any function as an argument in iex (Elixir's repl) you'll get documentation and an example of how to use that function:
[+] [-] ryanbigg|8 years ago|reply
I find it an interesting idea too. I mentor people at Culture Amp in Ruby and Elixir and I'm definitely finding Elixir easier to teach for a couple of main reasons:
* It's Just Functions And Data™
* Inheritance isn't a thing
* Functions either come from within the same module if they don't have a module prefix
* Functions from other modules _must_ have a module prefix.
* Immutability, immutability, immutability.
It just _feels_ like there's less to learn with Elixir (foundational wise) than Ruby. It's been pretty nice.
[+] [-] jaylynch|8 years ago|reply
Another goal was to take the people who had been learning to code in their spare time and put them on more even footing with those who were totally new, force them to think about things from first principles rather than lean on acquired habits, etc.
I had already been coding for a long time by that point but it was the first time I saw a functional language and I think it addressed both goals very well.
[+] [-] urs2102|8 years ago|reply
Would love to share it here in a bit when I have some time to finish things up and get some feedback.
I will say, writing from the perspective of it being one's first language is really interesting, because you just can't assume anything.
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] cordite|8 years ago|reply
There are erlang books, of which I am reading, though it feels like there's always emphasis on history for backwards compatibility and the other warts that Erlang has with its age. I'd like to design reliable systems that operate outside of the classic HTTP -> Elixir -> Database pattern. Things that involve working in memory, processing queues, managing sessions and state, patterns for fallbacks and breakers for services, and so on, that is where I seek more content.
Unfortunately I hear the big BEAM player around, Basho, is shutting the lights--so I can't expect to witness the wonderful presentations their engineers provide at conferences or through recordings of such conferences.
[+] [-] bitwalker|8 years ago|reply
Unfortunately I probably won't be done until the end of this month, but if you're interested, keep an eye out on ElixirForum.com, since I'll announce it there when it's available.
[+] [-] jah|8 years ago|reply
Source: full-time Erlang developer of 7 years who spent a full year coding Elixir in its v1.0.x days
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] lojack|8 years ago|reply
The focus of the book sounds like pretty much what you're asking for. The first few chapters cover Elixir basics, but its really just a primer -- easily skippable if you already know it. Starts with implementing OTP features from scratch so you can see what they do and why they exist, then dives into how to do it using OTP.
[+] [-] tarr11|8 years ago|reply
https://news.ycombinator.com/item?id=14621359
[+] [-] rdtsc|8 years ago|reply
Then use Erlang. I like and prefer Erlang to Elixir for example. It has a simpler syntax, it's consistent just like Elixir. And you'd be surprised that Erlang for being what 30 years old is being regularly updated and improved Most importantly things are deprecated regularly from the the language and the standard library, as new stuff is added. That's how it managed to still say small and simple. Plus you'll get a lot of resources and reference already created for it.
If you like Elixir, start with it as so many concepts overlap and then you'd pick the Erlang syntax and some conventions later without that much hassle.
[+] [-] beedn|8 years ago|reply
[+] [-] pawelduda|8 years ago|reply
[+] [-] kureikain|8 years ago|reply
https://www.youtube.com/channel/UCFKQ85T69sYhifDHF7dnPgw/vid...
Kind of like a quick guide:
https://elixirschool.com http://elixirbridge.org/02_Intro_to_Elixir/01-why-program-wh...
I think Elixir isn't that hard about syntax. Just start to do something and learn it on the go, see how people do it.
I have experience with it, quite nice: https://github.com/yeo/betterdev.link/tree/master/community/...
Which power: http://one.betterdev.link
[+] [-] bostonvaulter2|8 years ago|reply
https://elixirforum.com/c/elixir-news
[+] [-] achariam|8 years ago|reply
[1]: http://www.achariam.com/elyxel (It's a self plug but I genuinely think it will be helpful to folks)
[+] [-] bogomipz|8 years ago|reply
Or has anyone recently hired for it? If so what did it look like from the hiring side?
[+] [-] andythemoron|8 years ago|reply
[+] [-] di4na|8 years ago|reply
[+] [-] dgjuuff|8 years ago|reply
[deleted]
[+] [-] pmarreck|8 years ago|reply
Your skepticism (which is otherwise probably warranted) is quite wrong in this case. I'm sorry if someone defecated into your Cheerios this morning, though.
Sometimes the best way to learn is to teach, and sometimes the best way to teach is to make money teaching. :P
[+] [-] bjz_|8 years ago|reply
[+] [-] ryanbigg|8 years ago|reply
----
The book is released for free, however I charge for the PDF because it takes time + energy to generate that (and typesetting, omg) _and_ it gives people a way to financially support the project (if they want to).
Joy of Elixir will _always_ be free because I think having the bar of entry as low as possible for newbie programmers is a nice thing to do. As I say on Joy of Elixir's about page, I want this book to be the equivalent to Learn to Program, but for Elixir. So in that same vein, it will always be free.
---
Regarding my Elixir experience: I have been happily using it for two years "for fun" and one year in production _almost_ full-time. I have built several parts of my workplace's microservice's architecture using Elixir in a small team of Elixir developers. I've learned a crap load and made some frankly _awesome_ mistakes.
In the last four months I've started mentoring a junior developer in the ways of Elixir and that's what led me down this path of writing a book directed at newbie developers.
---
Brown-nosing on IRC? Hardly. I've been active on Freenode #rubyonrails for at least 10 years and #elixir-lang on-and-off for at least the past 2.
> IMHO someone which actually contributes high quality libraries or code to said community should be valued more, yet these are usually the last people you would ever see slapping their name on a book. They are happy to just improve the existing documentation and contribute that way.
I wrote https://github.com/radar/elastic. Sorry if this is not up to your high-quality bar. Patches welcome. Open source is great, yeah?
And by the way: I am strongly (so strongly) in the camp of documentation being more important than the code itself. For without documentation, who can understand how to use the code? Who can understand the _reasons_ behind the code?
---
> This is all just A self promotional stunts. The author has done this before in the Rails community.
I started contributing documentation fixes / entire guides to the Rails community in 2008. I started using Rails in 2004. I felt it was one of the best ways that I could possibly give back to the community that has kept me very, very safely employed since 2006. 543 commits to Rails, at least: http://contributors.rubyonrails.org/contributors/ryan-bigg/c.... All for free.
In terms of self-promotional work, I spent at least two years of my free time writing books. Probably closer to three, but let's not brag too much. And yes, I _do_ use the books I wrote for self-promotion. It would be pretty ridiculous to spend all that time writing a book, selling it and then _not_ using them for self-promotion, dontyathink? I use them as more of an example of what I am capable of teaching people, more than "hey, look at how STUPENDOUSLY AMAZING I AM". Although, I admit, sometimes I act that way too.
---
Anyway, it's been nice rebuffing your attacks today. I'm very happy to continue to play this game for as long as you wish. I guarantee you I have more patience.
And I implore you again: come out from the shadows, little troll.
[+] [-] shocks|8 years ago|reply
What evidence do you have?
[+] [-] johnny22|8 years ago|reply
[+] [-] amorphid|8 years ago|reply
https://www.drupal.org/files/druplicon-small.png
[+] [-] notamy|8 years ago|reply
[+] [-] ryanbigg|8 years ago|reply
[+] [-] puuush|8 years ago|reply
[+] [-] bostonvaulter2|8 years ago|reply
[+] [-] jondubois|8 years ago|reply
HN shouldn't be used as a propaganda hype machine. I've seen all the language hype cycles,
Year 1:
PHP sucks! Node.js is awesome! Everyone must use Node.js!
Year 2:
Node.js sucks! Go is awesome! Everyone must use Go!
Year 3:
Go sucks! Rust is awesome! Everyone must use Rust!
Year 4:
Rust sucks! Elixir is awesome! Everyone must use Elixir!
... And of course you get the odd Haskell article every so often.
Communities are promoting their stuff too hard - They are setting up their users for disillusionment and disappointment.
[+] [-] obstacle1|8 years ago|reply
There's nothing wrong with communities promoting themselves. If people don't know about your thing, they can't try it to make their own decisions about whether or not it is worth using.
And it isn't yours or a community leader's or a maintainer's job to protect users from disillusionment and disappointment. If someone actually has a hard fall from realizing that a programming language isn't as great as people said it might be, there are way bigger issues there than the programming language at play -- on the side of the disillusioned, not the language/community.
[+] [-] bhauer|8 years ago|reply
I suspect with any given hype generation—with each trending language—we're going to see a lot of positive messaging as the fans up-vote articles pertaining to the new hotness. Meanwhile, those who disagree (or simply don't care) probably don't see much value in taking the time to evangelize their disagreement. I'm not upvoting Elixir content, but I'm certainly not going to downvote it either. Why should I care if other people enjoy a platform I don't care about? Good for them!
Also, perhaps as everyone is hyping language N1, those who are using N are simply too busy using N and making a living to keep layering on the hype.
[+] [-] bsaul|8 years ago|reply
You may however see the whole thing a bit differently :
- node popularized single loop event on the server side, which is great for fast low cpu request processing
- go evangelized simple design, coroutines , unique code formating, and has arguably one of the best stdlib. That's still true today and it's great
- Rust made people realize writing concurrent truelt safe code was possible. Huge advance.
- Elixir helped the community focus again on actor + message passing concurrency. It's fantastic.
All of those concepts are beneficial to learn, for you as a programmer, no matter which language you use.
If for example look at swift evolution, you'll see the current threading model (based on event loops, like node, because of iOS) discussed and compared to the actor model ( like erlang / elixir), but also that some web framework reimplemented go-style concurrency. You'll also see that they're talking about adding semantic for detecting memory sharing patterns (much like rust).
If you've followed all the discussions on those languages for the last two years you know exactly why those conversations are taking places. So all in all it's a good thing communities are advocating the strenghts of their language. It helps everyone improve.
[+] [-] pessimizer|8 years ago|reply
Hacker News is interested in Erlang; it should be in the rules.
Also - just judging by the head of the linked list - PHP programmer?
[+] [-] acjohnson55|8 years ago|reply
[+] [-] dcu|8 years ago|reply
[+] [-] 43224gg252|8 years ago|reply