Live data from Hacker News

Joy of Elixir

joyofelixir.com

61–70 of 92 posts

Re: Joy of Elixir

#61
post #12

Another book by someone with no experience in the language. Typical vultures latching onto a community and trying to monetize it.

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…

Hey! :wave:

Yes that's me on both GitHub and Freenode IRC. I've been doing Elixir for roughly two years now. It's been fun.

I am not planning on jumping fulltime Elixir any time soon, because my company is currently doing a mixture of Ruby + Elixir. It's likely that I'll still straddle that particular divide for the foreseeable future :)

Thank you for leaping to my defence so eagerly!

Re: Joy of Elixir

#62
post #14

Earlier quoted context omitted.

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.

Which the JOE folks make quite clear. Why would anyone assume this was not for complete novices new to programming in general? It seems odd to me. I find it a very good start for someone new to programming with zero experience and wishing to start with elixir. There are hardly any books that approach programming elixir from a complete lack of programming knowledge POV. I'm happy to see this!

Thank you for the validation! :) It really helps to see support like this for the project.

Re: Joy of Elixir

#63

I've been seeing a lot about Elixir lately. I am curious are people seeing a demand for Elixir in the market? Or has anyone recently hired for it? If so what did it look like from the hiring side?

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.

Re: Joy of Elixir

#64
post #8

There seems to be an unfortunate number of "TODO: Add image here"-type blocks in this. Other than that, a quick glance seems good to me.

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.

Re: Joy of Elixir

#65
post #40
post #29

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…

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 E…

Learning how the BEAM works and the architectural decisions that make sense for running your system on it is the realistic growth path for any serious BEAM developer. This has nothing to do with any of the languages on the BEAM, but with what makes sense on the VM.

Your assertion that abstraction is somehow not needed in "large complex systems" (this being completely undefinable, by the way) seems silly and I can refute it with about as many objective reasons as I suspect you have for making that comment. Our current code base would be significantly shorter if we used Elixir (on the order of 50% less code, conservatively approximated) and is an absolute bitch to spelunk in specifically because it's just Erlang.

There is no reason to create a new project in Erlang (instead of Elixir/LFE) outside of reasons like handing it off to clients or the like and the focus should never be on learning Erlang, but on the BEAM. Any knowledge gained through that is trivially used in one of the more productive languages on the BEAM.

Re: Joy of Elixir

#66
post #29

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…

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.

Re: Joy of Elixir

#67
post #65
post #40

Earlier quoted context omitted.

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 E…

Learning how the BEAM works and the architectural decisions that make sense for running your system on it is the realistic growth path for any serious BEAM developer. This has nothing to do with any of the languages on the BEAM, but with what makes sense on the VM. Your assertion that abstraction is somehow not needed in "large complex systems" (this being completely undefinable, by the way) seems silly and I can ref…

50% less code? Can you provide some more specifics? That seems like a bold claim.

Re: Joy of Elixir

#68

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 lear…

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 cod…

> 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

The thinking behind that is usually a bit fallacious, though.

Say the department has been teaching Java in the introductory programming course, and noticed that some people already know most concepts. Then they decide to use a different language to "level the playing field".

First of all, what kind of attitude is that? If some people already know the stuff, just let them take the exam without attending the course, so they can take "Advanced Programming Paradigms" or wherever FP is taught.

I can understand teaching FP first if you think it's conceptually easier, but counting prior experience of some students as a reason to restructure the curriculum for everyone is silly.

Second, using Haskell instead of Java isn't actually leveling the playing field. It just changes who has an advantage from game modders and people who coded their own website to the more mathy types (or people who learned Haskell in high school, like me), who will have an easier time with higher-order functions and the rigid formality of the type system.

When they announced in my OOP course that there'd be a few sessions on other paradigms, I was a bit disappointed to find out that this meant only a bit of Haskell and Prolog, when I'd already written a simple Prolog interpreter in Haskell. Should they have changed the curriculum just because of me? Definitely not.

Re: Joy of Elixir

#69

I've been seeing a lot about Elixir lately. I am curious are people seeing a demand for Elixir in the market? Or has anyone recently hired for it? If so what did it look like from the hiring side?

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....

Re: Joy of Elixir

#70
post #6

This doesn't improve the current docs or tutorials.

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.

Aha, then add more fun through pictures (the drop of elixir thing at the homepage could be the spokesperson). How many people are working on this?
Post reply on HN