Show HN: A Travis CI Elixir client

I'll bite. I like Elixir, but that's not why I think JS's concurrency story is a fricking joke.

JS allows you to say, in essence: "This code is allowed to run somewhere else." That's your hammer, and you'd better squint at your problem until it starts to look like a nail. This feature can be dressed up to look like callbacks, like promises, like streams, like async/await -- but if the low-level interface isn't what you wanted, you will not get what you want.

I mean, it's better than Python or Ruby, where you don't even get to point out bits of code that can run on the side. But it's still kind of crappy.

Experience in other languages with more control over the concurrency model often leaves JS not looking so good in comparison.

That leaves aside many other factors that make writing safe, concurrent code in JS harder than it has to be: for example, immutability of data, crash supervision, server clustering, shared-nothing architecture. JS doesn't have good stories here either.

>and dependencies?

My gripe with node dependency management has been the lack of a .lock file, until yarn was released. Also, the ecosystem has kind of a mess of transitive dependencies, which are sometimes in practice not resolvable to a working set of modules for a given dependency list.

>Callback hell is gone with promises, and async/await is shipping in ES7.

Sure, this particular problem is "solved" but due to the single threaded nature of js, even if you may async code look friendlier, its still the only tool you have for parallelizable tasks. And some of those tasks are a poor fit for async event loops. Tools like Elixir give your more concurrency tools, so that you don't have to shoehorn everything into async functions.

>async/await is shipping in ES7.

ES2017 / ES8.

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 :)

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.

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.