Hacker News Reader

Comment by acconrad | Hacker News Reader

All of my pet projects are run on Elixir/Phoenix. If there is a language/framework to learn, this would be it. As approachable as Rails with the benefits of handling real time applications (chats are trivial with Channels) and faster runtimes than Rails (by orders of magnitude).

Happy to help anyone out if they're interested in learning!

View on HN

Serious question, though I know it will sound negative... I really don't like Rails and don't like Ruby or VB.NET, either (syntactically), which means Elixir is off-putting for me, at least in how it's been marketed. Do you know of anyone like me who has come to Elixir and liked it?

Note: I like Clojure, F#, and other functional languages, so that's not a hurdle.

The syntax is bad (just like ruby), and there are some annoying limitations with macros, but the semantics are very good, and the ability to keep thousands (or hundreds of thousands, or even millions if you know what you're doing) of stateful connections to clients is very useful in practice.

> The syntax is bad (just like ruby)

Any interest in qualifying that opinion?

Not the OP, but I share the opinion. I strongly prefer a precise syntax over ones where parens are optional, but required in some circumstances, etc. I don't like Ruby's block syntax at all. (Incidentally, I wish Ruby had better first-class function support instead of blocks.) I don't like "end" littered everywhere. I find the `=>` for hashes/dictionaries to be annoying, given how often I use that data structure (granted, I now mostly can do `{foo: :bar}`).

There're other things I don't love, but that's a good chunk. Philosophically, I prefer explicit code to implicit (so, Rails is out). And I prefer functional programming to OOP in general, and find that Ruby greatly favors mutable OOP. I've had a tough time navigating around the Ruby parts of most code-bases I've found, largely due to the implicit nature, and annoying language features that allow clever generation of methods in a way that makes them impossible to search for (delegate ... prefix: true for example).

Yes.

Superficially, `do ... end` blocks look like English, because they are English words. On the other hand, they don't really correspond to any real grammar construct of the English language. They live in the the uncanny valley where you try to read it like English, but you can't actually read it as such. For some reason, the use of keywords like `def`, `defmodule` or `defmacro` doesn't bother me as much. Maybe because they are not block delimiters?

In my opinion, braces, delimiters or parenthesis create less visual noise than endless cascades of `end` keywords:

    def f(x) do
      ...        
          end
        end
      end
    end

There are other block keywords besides `end`, which serve no purpose other than simplify some keyword list arguments at the cost of higher complexity.

In general there is too much syntax sugar for things that don't really benefit from it.

Parenthesis in function calls are optional in some places but not others, which creates some unnecessary confusion.

The syntax for anonymous functions is

    fn arg -> do ... end

The `end` keyword is strange and I keep forgetting it (that's more a problem with me than the syntax, I know).

The language is subtly whitespace sensitive in some places, while being mostly whitespace insensitive.

Macros can't take a variable number of arguments, which leads to the proliferation of Special Forms (it's a kind of macros that is treated as special by the compiler) which could perfectly be macros if it weren't for this limitation.

For a situation where this causes problems and requires some extra weirdness in what should be a simple DSL, look at this Github issue in the new testing library scheduled for inclusion in the standard library: https://github.com/whatyouhide/stream_data/issues/21

> Macros can't take a variable number of arguments, which leads to the proliferation of Special Forms which could perfectly be macros if it weren't for this limitation.

This is not true.

We have only two variadic special forms: "for" and "with".

"for" needs to be implemented as a special form as it emits some optimizations that are only available at the Core Erlang level.

"with" needs to be implemented as a special form as it has different lexical properties than a bunch of nested cases.

None of those could be implemented with macros.

Regarding whitespace sensitiveness, most languages have subtle issues, to varying degrees but especially if you have optional line terminators. Although it is true one or two extra cases appear in Elixir due to optional parentheses.

> "for" needs to be implemented as a special form as it emits some optimizations that are only available at the Core Erlang level.

That's interesting. I wonder if a future Elixir version could have a way of defining macros which sould emit these optimizations. Is this a likely direction for future developments?

> "with" needs to be implemented as a special form as it has different lexical properties than a bunch of nested cases.

Could you expand on this a little? What are those different lexical properties?

> That's interesting. I wonder if a future Elixir version could have a way of defining macros which sould emit these optimizations. Is this a likely direction for future developments?

To do so, we would need to compile to core, and that means tools like Cover and the Erlang debugger would no longer work with Elixir. It is unlikely we will go to this direction.

> Could you expand on this a little? What are those different lexical properties?

If you compile a "with" to a bunch of cases, a variable from the outer case would be available to both success and failure cases. Take this code:

    a = true
    with true <- a = false do
      a
    else
      _ -> a
    end

In Elixir it returns true because `a = false` has no impact on else. But if it compiled to a bunch of cases, we would get:

    a = true
    case a = false do
      true -> a
      _ -> a
    end

And that returns false.

The macro limitations are necessary to maintain solid concurrency. Yes, it can be annoying, but much less so than trying to track down an intermittent concurrency bug.

If you're not fond of the syntax (and I don't blame you at all, I'm no fan) then you should give Erlang a try.

I have, and quite liked it. The problem seems to be that Elixir has much more momentum and better tooling (from a web-dev perspective). Am I wrong about that?

That definitely appears to be the case. Erlang gives you the same semantics and better syntax, Elixir gives you improved tooling and wider audience.

Elixir definitely has more momentum at the moment (mostly due to an influx of Rails refugees IMHO), but as someone who came over to Elixir from Erlang rather than from Ruby I think you will find that it is not hard to switch back and forth between Elixir and Erlang once you get used to it. Elixir, if you can get past the Ruby -ish syntax, lifted a lot from Clojure as far as what is happening underneath the surface and you can call back and forth between Erlang and Elixir at eny time. This lets you do things like write large chunks of your app in Erlang and then glue everything together using Elixir/Phoenix to take advantage of the larger Elixir web-dev community. Phoenix itself is based upon a lower-level HTTP library written in Erlang.

Not perfect, but it does allow you to leverage the advantages of Elixir (e.g. Phoenix and the related web-dev community) while still letting you get most of your work done in Erlang.

Good information. There's also Lisp-flavored Erlang and other options worth exploring:

https://gist.github.com/macintux/6349828#alternative-languag...

There is no reason to use LFE. It doesn't add anything that Erlang does not have (besides macros) and it is very poor on the documentation side.

Even if you don't like Elixir, it brings more to the table than just syntax and macros, such as tooling, Unicode support, protocols, better error messages, better debugging, tasks, etc.

If Elixir is not your cup of tea, definitely Erlang all the way.

> I have, and quite liked it. The problem seems to be that Elixir has much more momentum and better tooling (from a web-dev perspective). Am I wrong about that?

No, you're not wrong. Elixir also supports meta-programming, whereas Erlang does not. I like both languages though, primarily due to the BEAM VM. You can't go wrong with either one.

Erlang has been around for many many years though, and is not going anywhere. Elixir who knows? It's popular now but where will it be in five years?

I learned ruby on a big project about...5 years ago. I've been using it ever since at work and I definitely understand the pain points. With Ruby you really have to learn to understand and appreciate where its strengths are to be productive with it (how close it can bring you to Aspect Orient Programming is probably the biggest).

The only similarity that Elixir honestly has with Ruby is clean syntax and general emphasis on productivity. Everything else is different. Same with Phoenix. On the web side of things it has routes, controllers and views...but there's no magic involved. It's all very clear, explicit and flexible in how it does things. The view layer is honestly one of it's biggest strong points because the way it's handled is the core reason for all of those "My site was faster without caching" articles...but you don't have to work differently to enjoy those gains.

Big Nerd Ranch did a solid write up on the ins and outs of why.

https://www.bignerdranch.com/blog/elixir-and-io-lists-part-2...

This Choosing Elixir for the Code post that came out last month does a really good job of emphasizing a lot of it.

https://pragtob.wordpress.com/2017/07/26/choosing-elixir-for...

Phoenix is completely unnecessary though. I have gone away from it and just use good old Plug and Elixir. Works amazing for me.

Different strokes. One of the big Phoenix perks is that using it instead of just raw Plug has very little performance drop off. It's not a Rails vs Sinatra situation.

The Phoenix Channels implementation for websockets and the view layer for web requests are pretty phenomenal IMHO.

Isn't Phoenix just Plug + Ecto + generators and a folder structure? I always saw it as "how to use Plugs" rather than a separate project.

There are some unique bits too. Phoenix Channels is a beautiful, shit-simple pub/sub abstraction on WebSockets and provides both JS and Elixir libraries. And then came Phoenix Presence, which can track shared state (like a user's online status) in a durable and fault-tolerant way.

Both are useful libraries, but the fact that they work in server clusters as well as single-node deployments is the real kicker. That's just how Erlang rolls.

That's just genservers though right? All of this stuff is just Elixir and generally can be done in Elixir in a few lines of code.

We're experimenting with a truly OTP driven web application right now(No API) where we connect the React app directly to the Elixir backend and only persist to a database on log out. Everything else is persisted in memory and run through genservers which are self healing and self hydrating.

Pretty much anything of value in the Elixir ecosystem is "just" genservers. OTP remains the star of the show.

I came to Elixir from Clojure and was not a big fan of Elixir's syntax, but I've found that after a while it mostly fades into the background (much in the same way that Clojure's parens do).

The language and Erlang's virtual machine are generally a joy to work with, and I have no regrets pushing past the syntax.

That's good to hear. It felt kind of arbitrary the handful of times I tinkered with it.

Can I ask what you use on the front-end (if anything)?

(If you're asking about what flavor of Javascript I use) I just use plain JS for the bits of JS I need, but nothing I have been working on needs a heavy front-end.

There's not really an Elixir equivalent of Clojurescript to Clojure (there is an Elixirscript, but it's a work in progress and I'm curious whether it can ever capture the nice experience of using the Erlang VM). I've seen interest in the Elixir community in Elm and Bucklescript(OCaml) and other compiled-to-js languages, but I think a lot of people just use JS.

I know you weren't asking me, but Elm on the front end, communicating to Elixir on the back end, has made my life so much nicer. I loathe JavaScript, and this Elm/Elixir combination has made me like web programming again.

It's a functional language! And it's based off of Erlang, so if you like Erlang, you can use call Erlang directly in Elixir. And if you like piping things / pattern matching (common in F#), I think you'd enjoy it :)

I disliked Rails and did not get into Ruby but I love Elixir. YMMV

I’m a Python guy who strongly dislikes Rails, feels meh about Ruby, yet loves Elixir (and likes Phoenix).

Same same. I should send you a digital pinch.

I also come from Clojure and Erlang and, tbh, couldn't get into Elixir for various reasons (I've followed the development closely since its inception):

* Most of the Elixir community comes from the Rails world, so most of the libraries focus on the web.

* Coming from the Ruby world, a lot of these new developers tend to be ignorant of the underlying Erlang machinery, believing that Elixir is the magic that makes Erlang a "modern" and usable language, which is simply not true.

* The tendency to favor frameworks over libraries.

* I'm probably alone in this one, but I find the syntax off-putting. It adds lots of sigils and complexity to Erlang's very succinct syntax.

* In the end, I think Elixir adds very little besides the excellent tooling to the Erlang ecosystem.

You're definitely not alone in disliking the syntax.

I agree with most of your points, from what I've seen, except the last one.

One thing that Elixir seems to get right is a sane string implementation out of the box.

Not only strings, but better error messages, the new breakpoint support, functions for working with collections, protocols, tasks, etc. It goes quite beyond tooling.

I think your second point is unfair. It has nothing to do with Ruby but the fact a lot of people are joining the platform. It takes time for them to understand how everything fits together. Most experienced developers I talk to are actually appreciative of Erlang. Elixir also helps a lot since it points developers to use the Erlang libraries instead of wrapping them.

But mostly you shouldn't expect people to grasp functional programming, concurrency and OTP when they are just getting started.

> Coming from the Ruby world, a lot of these new developers tend to be ignorant of the underlying Erlang machinery, believing that Elixir is the magic that makes Erlang a "modern" and usable language, which is simply not true.

This sounds very subjective, and doesn't agree with my experience. I don't know a single Elixir dabbler that doesn't give Erlang credit where credit is due. It's just that the syntax looks like Prolog and ML got into a nasty car wreck sometime in the 1980's, and the tooling is more like a box of parts that can be assembled into various tools. That's why I use Elixir instead, anyway.

> The tendency to favor frameworks over libraries.

I know of exactly one framework in Elixir; I assume you mean Phoenix. Phoenix is little more than a few blobs of glue around other, mostly core Elixir, libraries. The Elixir community at large is quite wary of language and framework magic. The fact that lots of us did time with Rails means we've been hurt by the downsides of that approach like few others. :)

> In the end, I think Elixir adds very little besides the excellent tooling to the Erlang ecosystem.

That's good enough for me!

First of all, Elixir's relationship to Ruby is only skin deep. The languages aren't as similar as some like to suggest, in my opinion.

Personally, I like Elixir better than Clojure because memory in the BEAM VM is isolated. The JVM uses shared memory, which has caused me issues before. I also like the tooling and build tools for Elixir a lot better. Clojure is weak in this area, I think. I like Elixir's syntax much better too. For me, it feels a lot cleaner and easier to type, but that is subjective.

Regarding Rails vs. Phoenix, I cannot really speak to that. I don't do monolithic apps anymore, so I don't use Rails or Phoenix. Elixir has a library called Plug built into it that lets me easily make REST APIs for micro-services, so that is what I typically use. For me, this eliminates a lot of the issues I had with Rails.

You should hear Chris McCord (Phoenix author) talk sometime -- he is extremely wary of sprawling design in a way that might please you.

I came to Elixir from Scala but also having a Rails background. I was quite sick of Railsy magic, because I'd gone deep with the Ruby metacrap and I got to taste the other edge of the sword. Elixir was a breath of fresh air.

If you enjoy concurrent programming with nice syntax and few surprises, you might end up liking it. Elixir is basically Erlang with modern syntax and vastly improved tooling.

Elixir seems much more like Clojure without the parens to me than Ruby. (Yes, I know Clojure can actually use fewer parens than the equivalent Java, just referring to the Lispy syntax in general.)

Dynamically typed, functional language with immutable data structures and a strong philosophy about how to best handle concurrency and scaling.

The key difference is JVM vs. Erlang VM as the base and all that implies.

The problem with nice backend systems is that it just makes the switch to frontend work even worse.

(Say what you will about Struts, but at least it makes JavaScript/React almost palatable by comparison.)

You can look into drab, an elixir server-side DOM manipulation library: https://github.com/grych/drab. I've never used it, but many people in the Elixir community think it holds a lot of potential.

This project seems really interesting, I guess it could pretty much replace SPAs (and related javascript fatigue) in a lot of use cases. Am I missing some significant limitation other than moving some computation back to the servers?

I'm not qualified to answer that, as I haven't used Drab, but you can ask on the proper topic at the elixir forum: https://elixirforum.com/t/drab-phoenix-library-for-server-si...

The only real limitation I can see for now is a response time for the actions, which might be done locally, without requesting anything from the server. Eg, you don't want to do animation loop with Drab, for this just use the ol' good JS.

Holy @#$% that's amazing.

May I cite you in the testimonials? :)

"Holy @#$% that's amazing." - notamy

Haha, go right ahead! :)

Boy, am I glad I read the HN comments today. Never knew Drab existed. It’s fantastic!

I would love to use Elixir, I find the language to be the natural successor to Ruby, given the trends in languages today. However, everything I've read says that it's pretty hard to deploy. That the cloud options are limited (or take away the advantages of Erlang VM like code hot swapping). Any progress on this front?

I think one of the difficulties here is that much of the functionality that comes from, for example, Docker + Kubernetes exists as part of the BEAM VM. A lot of the development being done today in deployment is around Docker and Docker clustering technology, which means that it often feels like you are doing things the old fashioned way when using BEAM clustering & networking technology.

There are ways to set up these systems in symbiotic configurations, like having an Elixir/Erlang/BEAM cluster that has auto-joining thanks to external service discovery. However, to use the hot-swap functionality, you are going to be working with the BEAM VM directly, which means going through the Docker container boundary.

Know that if you choose to go with BEAM and no Docker, you will still have access to amazing deployment features (like hot swapping, as you mentioned), but also clustering, service discovery, monitoring, etc. You're just going to be spending a lot more time at the command line without the pretty interfaces and the sleek modern tools.

To get a better understanding of running BEAM, I highly recommend "Designing for Scalability with Erlang/OTP". You'll have to learn Erlang to get through it, but IMO it's the best introduction.

> you will still have access to amazing deployment features (like hot swapping, as you mentioned), but also clustering, service discovery, monitoring, etc.

Can you elaborate on this statement? My understanding is that you can have these things (minus hot swapping) cleanly on Docker.

Yes, you definitely do. What I meant is if you didn't use Docker and just used BEAM, you would still have access to all those features that are present in Docker + clustering technology.

Thanks, you're definitely right!

My first ever docker build was a multi-stage elixir compilation. The end result is a docker image that can be deployed to Heroku or k8s that works great. It's not that hard to get a good docker setup for it. It's even easier if you use Mix and not releases (like I did). However, releases are cool.

Code hot swapping is not really docker friendly (obviously). I haven't done that, but work's general philosophy has been to have recoverable processes such that starting up the app will bring up the correct processes loaded with the right data. However, it's definitely possible to setup hot swapping but is going to be a learning curve to it.

Code hot swapping is not particularly friendly at all. It's impressive that you can, but the time required to write the code carefully enough and QA the upgrade doesn't seem to be worth it for most applications.

Sure, a telco switch that has to be up 24x7, hot swapping makes a lot of sense. Most applications can spare the brief downtime to reload the old-fashioned way (or have multiple servers to allow upgrades to be done without downtime).

I'm sorry, I disagree.

Code hot swapping can often trivially be done (by simply compiling and copying the fixed module, then 'l(module)' in the shell) if the module does not change the state record or break function signatures. I have used this countless times to fix a module function with no downtime. You don't always need the full code upgrade procedure, which is indeed far more onerous.

I agree, I should have been more specific. Individual module upgrades are indeed straightforward. That didn't sound like what the poster was describing.

There are already recipes for deploying to Heroku, and I've had no problem using Elixir and Phoenix apps on Heroku for the past 2 years. If you use EngineYard or other bare-metal solutions like AWS or Google Cloud, I would imagine there's something you can glean from that.

Have you ever tried distributed clustering, hot code reloading, remote console or remote observer with Heroku?

It's not very hard to deploy. Just use the proper tools to compile and build a release (on a VM emulating the same architecture as your server), rsync the resulting files into the server and strat the app.

Getting hot code reload to work is harder, but for a "normal" basic deployment it's just this. App restarts take less than one second of downtime for my app, and that's a cost I'm willing to pay.

You shouldn't do this by hand of course. Write an Ansible playbook or something else that does this for you

"Hard" is relative, of course. For small teams without a release engineer, options like Heroku, now, etc. are much easier than what you are suggesting.

Deploying to Heroku is relatively easy, the only downside is you lose access to clustering (plus hot code upgrades but most people don't use that anyway). There's great documentation available for heroku as well:

https://hexdocs.pm/phoenix/heroku.html

One new service that tries to make Elixir deployment easier is https://gigalixir.com. If Heroku was built with only Elixir in mind, this would be it. Disclaimer: I'm the founder.

This looks great. I'm going to give it a shot. If you'd like feedback I'd be happy to provide it.

Absolutely! I'd love all the feedback I can get. You can leave it here or you can email me directly here (base64 encoded): amVzc2VAZ2lnYWxpeGlyLmNvbQ==

I've been running an Elixir app in production on about 20 nodes for 18 months. We just build Debian packages and deploy using Salt.

Additionally, most of the cluster nodes run on Spot Instances in AWS so they are relatively inexpensive also. When a new instance comes up it connects to the cluster and starts serving requests. When an instance is killed, traffic is routed to the remaining nodes. Works great.

Do you have a blog post or anything that explains this process? How many nodes in the cluster? Why did you build Debian packages? How do nodes join/leave the cluster (DNS?)? Do you use ELBs at all?

I really should write a blog post about it :) but right now there isn't one.

Debian packages are easy to work with and we keep them as our primary artifact for any given release.

The number of cluster nodes varies between 10 and 35 depending on the workload at the time.

Nodes join the cluster by contacting one of the three "static" nodes that are not spot instances. If they can talk to at least one of those they get knowledge of the entire cluster. When one of the spot instances is going to be killed there is a notice is the instance metadata. The nodes just watch for that and initiate a normal shutdown if they see it.

Yes we do use ELBs but just as TCP proxies and for TLS termination.

replace pet with nothing and you get my life.. it's also FAR cheaper to run at scale than ruby.. which means you can offer faster/better apps than your ruby peers at a lower price point.

as a Ruby developer from Rails 2 > Rails 5.. about a year ago I made the switch to non-monolithic applications to Elixir API(no phoenix) and ReactJS front ends.. Match made in heaven.

What resources did you use/would recommend?

I actually think phoenixframework.org is pretty robust on this at the moment, and using the #elixir chat in Slack is also awesome.

Reply on news.ycombinator.com