Comment by yellowapple | Hacker News Reader

Comment by yellowapple | Hacker News Reader

Parent Full thread

It's my primary language nowadays; in situations where I'm able to choose the tech stack, Elixir is the default. I believe it's a sufficiently-mature ecosystem for production use at this point (as opposed to, say, a couple years ago when its maturity was still heavily dependent on Erlang; Elixir's starting to really hold its own, which makes for an even stronger mutual relationship between it and other BEAM languages, I think).

I'm starting to branch out into learning more about interfacing with external code (both via NIFs and via ports). I'd dabbled in it before (see also: the "rubix" package on Hex), but at the time I didn't really fully understand the conventional approaches; now, with a couple years to get a feel for the OTP way of doing things, I reckon I could make some significant improvements. I'm also using Elixir as a means to learn Rust - specifically, by toying around with writing NIFs in Rust. Rustler (http://hansihe.com/rustler/rustler/) looks to be a good start, though I haven't tried it yet.

----

EDIT: YMMV, but I ended up learning basic Erlang (via "Learn You Some Erlang For Great Good!") before I even knew what Elixir was. I'd recommend following the same approach if either of the following applies:

* You're not sure what Elixir offers over Erlang beyond having a different syntax

* You're struggling with cases where Elixir's "declarative-in-imperative-clothing" syntax is catching you off guard (i.e. because it's tricking you into writing code imperatively rather than declaratively)

In either case, Erlang will give you a baseline and help establish a more functional mindset. Elixir will then be a clear transition, and a lot of Elixirisms will make a heck of a lot more sense.

Again, though: YMMV.

Have you had any bad performance surprises ? To me, knowing that beam has poor pure computation performance made me look away. I don't want to build a magnificient immutable actor architecture only to end up writing parts of my system in C.

I've had a few here and there, though usually the sorts of performance bottlenecks I encounter are resolvable with concurrency (which Elixir makes very easy). I don't really run into many situations where something is both inherently sequential and prohibitively slow (but I came from much slower languages like Perl and Ruby, so I ain't the best judge).

My interest in ports/NIFs (and Rust as a specific implementation platform thereof) is less for performance and more for doing things that aren't really easy in a VM-driven architecture, like dealing with low-level device access or interfacing with native libraries/APIs.

Basically: I'd try it first before dismissing it for supposedly-poor performance. There's a reason why Erlang is considered to be a "soft real-time" language, after all :)

Well, the other reason is that i feel the need for things like full OTP has decreased a lot since we've been using containers and cloud services that offer autoscaling, load balancing and health checks...

Sure, but those are (IMO) pretty clunky and broad-stroked compared to OTP, which handles quite a bit of that (and then some) on a much more intelligent and fine-grained level. Microservices are probably as close as one can get to matching OTP without basically reinventing OTP, and microservices often involve a lot of complexity (that's often in turn managed by tooling around things like Docker, but still).

OTP is also not tied to a certain cloud provider; a couple of Raspberry Pi boards duct-taped to a WRT54G can use the same codebase, deployment practices, and application structure as a bunch of EC2 instances in a VPC with an Elastic IP. This is usually not true of "cloud" tools (things like Docker and Cloud Foundry are helpful here, granted, but a lot of the tooling around load balancing and such is often provider-specific).

Erlang, and hence Elixir, was never optimised for raw computation, it's all about the massive concurrency (we can handle literally millions of processes), fault-tolerance and scalability. This is not surprising as no language is good at everything, you have to pick and choose what you is most important. In most systems different parts will have different requirements so I think it is perfectly reasonable to use multiple languages in a system. Erlang is very good at communicating with other languages/systems.

> You're struggling with cases where Elixir's "declarative-in-imperative-clothing" syntax is catching you off guard (i.e. because it's tricking you into writing code imperatively rather than declaratively)

Would you mind providing an example of this type of syntax? I'm not sure I understand what you are talking about here and I'd appreciate some context to help me understand :)

One thing in particular I find myself wanting to do sometimes is assigning variables within a case/cond/if. In imperative languages, this is a reasonable practice. In Elixir, the practice is still allowed, so if I'm in "this looks like Ruby" mode, I'll end up resorting to it.

In reality, though, that sort of practice is unsafe, and Elixir's use of pattern matching alleviates the need for this sort of thing.

So, the following code, for example:

    if foo == :foo do
      bar = 1
      baz = "hello"
    else
      baz = "goodbye"  # no bar!
    end

Could and should be rewritten:

    {bar, baz} = if foo == :foo do
                   {1, "hello"}
                 else
                   {nil, "goodbye"}
                 end

Which in turn could be rewritten:

    def barbaz_for(:foo), do: {1, "hello"}
    def barbaz_for(_), do: {nil, "goodbye"}
    
    def whatever(foo) do
      {bar, baz} = barbaz_for foo
      # ...
    end

Nowadays, the first version will actually throw a compiler warning and suggest the second version, but but only because of the missing "bar", and it'll still compile either way. Meanwhile, the third version is much more extensible (maybe you want to handle foo == :bar someday in the future?) and reads clearer, IMO.

A more complex example might be the "let it crash" philosophy inherited from Erlang. Elixir looking like Ruby has a tendency to encourage try/catch-like constructs, whereas the more Erlangy/Elixiry way would be to use ordinary message passing and supervision trees (in other words: just because you can throw in Elixir doesn't mean you should).

Another example is the fact that Elixir has for loops (though they're much closer to Erlang's list comprehensions than to imperative-style loops). It's easy to rely on loops instead of recursion, even though recursion gives you much better control (and value-based multiple dispatch / "pattern matching" in function arguments makes recursion perfectly accessible and readable).

Point being, it helped me to ground myself by learning Erlang first so that Elixir would then make sense in an Erlang context. Then I can look at these things and say "wait a minute, there's a more Erlangy way to do this" and do it.

Reply on news.ycombinator.com