I've been toying on and off with Elixir for a while now, and generally found it to be a fun language. You hear good things about Erlang's design, but the lack of familiarity lowers its approachability. On the other hand, Elixir is a much easier sell, since it's like a functional-Ruby.
One of the many nice thing about Elixir is Mix, the default build tool. Since everyone is using the same tools for config, dependency management, tasks, etc. you can find your way around new projects very quickly.
It's a great time to pick up Elixir if you're looking to build a web app. Phoenix released 1.3.0 [0] a few days back. The project structure changes along with Ecto 2.0 seem like a good step in the right direction, helping you separate the domain model from the persistence layer, and group related features together.
My biggest complaint with Phoenix is that they don't treat JavaScript as a first-class citizen. But as long as you're just writing small scripts to glue stuff together, it's probably fine to avoid writing tests. They've also gone with Brunch as their build tool, while I'd prefer Webpack for most cases. Although I recognize both have their use-cases.
Umbrella project support was also added to Phoenix in the latest release, so you can embrace the monolith while still breaking stuff up when it makes sense. I'd be interested in reading other's experiences with umbrella projects, as I haven't had any good use-cases, so I've only been able to speculate on the matter.
It is not. I understand why people from Ruby really what it to be "like a Ruby", but it is a completely different language. People confuse this by not understanding the erlang runtime and end up writing really poor code.
This is, incidentally, one of the oldest arguments Erlang proponents had about the positives of Erlang's generally unfamiliar syntax: it is different because you should approach it differently, and it helps the programmer do a full context switch when working in Erlang. When Elixir came out, I think a lot of Erlang regulars had similar words of warning about it.
For the most part it hasn't proven to be too critical of a problem from my observer point of view. Mostly, it appears that Ruby tends to be slow enough that even if you write suboptimal "ruby in Elixir" rather than properly working to the VM's strengths, you may still get a speedup over the Ruby baseline you had before.
> it appears that Ruby tends to be slow enough that even if you write suboptimal "ruby in Elixir" rather than properly working to the VM's strengths, you may still get a speedup over the Ruby baseline you had before.
This is why frameworks like Phoenix are good for onboarding newbies even though they are pretty heavy and require a steeper learning curve than just a language.
You can approach Phoenix like Rails initially and survive pretty easily. Plus you still get a lot of the gains if you use the standard best practices.
But eventually you're app will grow, you'll have more complex requirements than simple CRUD/channel based interfaces. You'll also come across other apps and blog posts like the above "Spawn or Not". Then you can dig deeper into what it means to program on the Erlang/Elixir VM.
So the fact Elixir isn't as similar to Ruby is indeed true, the gap isn't wide enough top make the transition difficult. You can still fake it till you make it.
I was previously a ruby dev as well and I learned Erlang before Elixir (and other FP languages before that) so it was easier to wrap my head around the major differences with Ruby. But I already felt at home when I started to use Phoenix later on that I'm sure others will have a similar experience and they don't necessarily have to be worried that Elixir is fundamentally different.
Basically the only integration with Brunch is these two lines[0] that come with the default template, along with the .js files. Just switch those bad boys out to whatever tool you want, make sure the tool outputs to the directory Phoenix wants and you are good to go!
I really really don't understand why people replace Brunch with Webpack while I keep seeing complaining about Webpack problem. Except the React mobs make that happen. I wonder how many people need what Brunch can't do which are specified in http://brunch.io/docs/why-brunch. Not sure if including Webpack by default would "treat JavaScript as a first-class citizen".
Also, Elixir is not Ruby, not even "it's like". Don't talk about what's going behind the scene yet. Even on the surface - syntax, can you list what similar syntax except def(do)end? I can't think of any, maybe i miss something but I'm sure there aren't many or maybe it's just that def(do)end.
> Since everyone is using the same tools for config
I don't think so in terms of releases. There are controversial ways of configuring `sys.config` and environment variables. No consensus here.
There are designed similarities in the naming of modules and functions. Many mimic the names of modules/classes and methods of Ruby code and standard libs.
Past the naming and def do end layers they are very different languages, as one should expect. The main basic difference is due to pattern matching, which pops up everywhere even in function definitions. If then else is the first casualty.
A word about JS. I'm working in a project with an Phoenix backend and A React front end. The (mainly) front end developer chose Webpack. I had to fiddle with the configuration files and man, it's not a language for DSLs. It's no Ruby. I don't want to say those files are inherently messy, but for a moment I tried to remember if Java's configuration XMLs were as bad as that.
I've come around to Brunch, and I think it's the right choice for Phoenix.
I used Webpack for a while, but every time I needed to setup a new project I had to go back to the docs to figure out what I wanted. I tried using a generator, and it was awful... maintaining all the generated Webpack configurations was like trying to maintain a whole project within my project.
I wish Brunch had some more in-depth documentation, but I like not wasting so much time on getting that stuff setup.
> maintaining all the generated Webpack configurations was like trying to maintain a whole project within my project
That's true to me too. I'm not happy leaving a bunch of generated configuration I hesitate to touch in my project folder. It includes too many of what aren't supposed to be changed, and freedom is not an excuse for this case.
I played around with Phoenix a bit a while ago, and it wasn't actually difficult to integrate webpack. There are a bunch of posts around the web on how to do that, and I found it pretty straightforward.
So while you get Brunch out of the box, if you already know a different build system, you don't have to switch.
Does elixir only have 'int'? In that intro section I'd like to see mention of 8, 16, 24, 32, 64, and 128 bit ints/complex (if they exist). Nothing big, just mention that they exist and I won't have to abandon the language for higher maths.
No, not 32, 64, 128 bit floats/doubles (though I'm glad it has those as well). I meant plain ints. Do I have to do binary math or can I make use of large numbers natively?
It is a while I don't code in elixir however when I was learning the complex part definitely wasn't the one in this course.
The complex part is to start to think about decompose a big problem into smaller problems solvable by different Erlang modules.
When to spawn another process or when to re architecture the code.
Really great work but I would go a little bit ahead and add some more specific Elixir/Erlang part.
Also what really really helped me was to understand how a GenServer was written, it may be worthed to make the student write its own limited version of a GenServer...
Yeah, the difference between "this is suitable for a library (that is then called from within the context of someone else's process)" and "this is suitable to be its own process (that is called via message passing)" is something that takes a while to fully grok from an architectural perspective.
Howdy @siscia! When I wrote Elixir School the intention was never to be a full fledged tutorial or to "hand hold". The purpose of the site is to get you familiar with the topics, wet your appetite, and enable you to go out and learn more on your own.
We're working hard on some big changes this year including additional lessons and a blog. The blog will allow us to cover topics and material that don't fit well without our current lessons. Check back!
I read through this a little while ago when trying to decide if I should try out Elixir for a side project. The language is really intriguing, but I don't want to start a project without grokking how a more complicated project is laid out. Can anyone provide an open source example of a relatively complex project?
I'm working with a couple other contributors to Elixir School on new material that will go into more detail with regards to designing more involved applications.
I agree that resource is sorely missing from the Elixir community.
Phoenix will lay it out automatically for you, but changing project layout depending on the requirements of your objectives is really common in the community.
However, one prominent example, is Hex.pm, the site behind the package manager for Elixir. You can find its repo here: https://github.com/hexpm/hexpm
I'm doing a fairly complex one, Serverboards[1]. It is a monitoring, administration and automation framework. And so far without Elixir it would have taken me four times more to develop the backend.
Anyway it does not use Phoenix (the most beloved web framework), but a simple Web server based on Cowboy and JSON-RPC via websockets, so it may not be a canonical example.
Of course, and thank you for all of the work you've done. I'd love more than anything for Elixir to take off so there's more Elixir jobs out there, and educating developers is a key part of making the language more popular. I used ElixirSchool a lot (and still do now) while I was ramping up on the language, great job with it!
One of the many nice thing about Elixir is Mix, the default build tool. Since everyone is using the same tools for config, dependency management, tasks, etc. you can find your way around new projects very quickly.
It's a great time to pick up Elixir if you're looking to build a web app. Phoenix released 1.3.0 [0] a few days back. The project structure changes along with Ecto 2.0 seem like a good step in the right direction, helping you separate the domain model from the persistence layer, and group related features together.
My biggest complaint with Phoenix is that they don't treat JavaScript as a first-class citizen. But as long as you're just writing small scripts to glue stuff together, it's probably fine to avoid writing tests. They've also gone with Brunch as their build tool, while I'd prefer Webpack for most cases. Although I recognize both have their use-cases.
Umbrella project support was also added to Phoenix in the latest release, so you can embrace the monolith while still breaking stuff up when it makes sense. I'd be interested in reading other's experiences with umbrella projects, as I haven't had any good use-cases, so I've only been able to speculate on the matter.
[0] http://phoenixframework.org/blog/phoenix-1-3-0-released