Comment by TheAceOfHearts | Hacker News Reader

Comment by TheAceOfHearts | Hacker News Reader

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.

[0] http://phoenixframework.org/blog/phoenix-1-3-0-released

> functional-Ruby.

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 should be one of first articles new people to elixir should read. http://theerlangelist.com/article/spawn_or_not

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!

[0] https://github.com/phoenixframework/phoenix/blob/20e2826587b...

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.

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.

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.

This Webpack movement makes more sense. https://medium.com/webpack/webpack-awarded-125-000-from-moss...

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.

Reply on news.ycombinator.com