Live data from Hacker News

Why am I interested in Elixir?

underjord.io

141–150 of 183 posts

Re: Why am I interested in Elixir?

#141
post #41

Earlier quoted context omitted.

Are there no bad parts?

I've used it sparingly, I think deploying is pretty bad with it. I like the convenience of deploying a golang app, just one executable.

> I like the convenience of deploying a golang app, just one executable.

This is crazy. What about configuration, systemd unit file / initscript, documentation, manpage, shell completion. And the ability to tell what is installed, where, and at which version.

HN forgot how to do software distribution to the hype of statically compiled languages.

Re: Why am I interested in Elixir?

#143
post #128
post #73

Earlier quoted context omitted.

- deployment is terrible like really bad - average performance ( like 10x slower than Java even worse for CPU intensive tasks ) - dynamic language ( this is the worst part ), working on large code base means problems ahead - lot of features from BEAM / OTP that are not that useful and done better on modern cloud platforms ( Kubernetes for instance does a lot of similar things but better and more flexible, apply to an…

> deployment is terrible like really bad I've seen this stated many times as one of the big drawbacks of Beam languages. But using Distillery with Elixir, it's very easy to generate a release that's completely self contained. Just extract a tarball on a freshly installed system and you are ready to go. If your target platform differs from the one you are compiling your project on, there are various options for cross…

We just bumped to elixir 1.9 and I'm enjoying seamlessly deploying to our dev environment with a single command from Linux and my juniors are working on getting it to go for Mac via vagrant.

Re: Why am I interested in Elixir?

#144
post #73

Earlier quoted context omitted.

- deployment is terrible like really bad - average performance ( like 10x slower than Java even worse for CPU intensive tasks ) - dynamic language ( this is the worst part ), working on large code base means problems ahead - lot of features from BEAM / OTP that are not that useful and done better on modern cloud platforms ( Kubernetes for instance does a lot of similar things but better and more flexible, apply to an…

> average performance ( like 10x slower than Java even worse for CPU intensive tasks ) Urgh, that's a disaster.

How confident are you that what you are doing is CPU intensive?

Re: Why am I interested in Elixir?

#145
post #109

Earlier quoted context omitted.

Of course they are, but thé article seems to be from someone interested by elixir, rather than someone who used it long enough to discover them (although I might have misunderstood the article.) From own experience, the problematic parts are : - deployment being a bit messy if you try to follow 12 factors (might be improving in 1.9) - absence of a decent debugger - younth of the ecosystem and size of the community (a…

BEAM based languages lack "good" debuggers, because they historically depend on tracing instead of debuggers. I recently wrote a blogpost about the tracing landscape in Elixir. https://www.erlang-solutions.com/blog/a-guide-to-tracing-in-... But the main reason is that BEAM languages are mainly used for concurrent computing which is a very difficult problem to debug with classical debuggers. I know it is not a mainstr…

Wow, since moving over to Elixir/Phoenix I have been doing all my bug fixing this way but wasn't sure if I was doing it right!

Re: Why am I interested in Elixir?

#146

Earlier quoted context omitted.

Are there no bad parts?

Deployments are a mess and as it is interpreted, performance is closer to Ruby than Go. I found the community to be pretty disappointing (but YMMV obviously) — it seemed more alternative oriented than the Rust community (which seems more solutions oriented).

For web development the performance is within a breath of Go and a kilometer ahead of Ruby on Rails.

Re: Why am I interested in Elixir?

#147

Earlier quoted context omitted.

Not sure I understand completely your problem and I apologize if this is a stupid question, but can’t you just pattern match the errors in with’s else block?

this depends on errors being unique to the line they come from. if any of your errors overlap then it doesn't work. for example what if you have a bunch of functions that return {error, :notfound} and you want to handle each differently. also you don't have access to any previous values instantiated in the else block. if you could have an else block for each <- that short-circuited and had access to previously <- ass…

Yeah, if your functions return the same error it's quite difficult to use the "else" pattern. I also dislike the fact that the error handling is not near the function that provokes it, but in a separate block, so you have to remember which function in the pipeline returns which error. I've never written a with-pipeline with more than 4-5 calls, so it's been easy to avoid its limitations, but I can understand it's not optimal if you're writing complex stuff.

Re: Why am I interested in Elixir?

#148
post #97
post #84

Earlier quoted context omitted.

> Only (small) gripe is that Elixir is not a fast language. Which is interesting because Elixir isn't well known for being super fast when it comes to CPU bound tasks, but for a lot of semi-CPU intensive things you'd end up doing in a web app, it's still very very efficient. For example I wanted to generate 5,000x 19 random character discount codes and my first attempt took 730ms to generate the codes while being a c…

Would love to see the 3ms solution. Post a gist if you have it available.

Sure. Here's a gist with 3 versions (original, the 25ms version and the 3ms version): https://gist.github.com/nickjj/99ea84f460f41dae4139d0610ce80...

The reason I didn't use the 3ms version was due to it having too many concepts that are unknown to me. At the end of the day I would still need to maintain the code and the 25ms version is a lot easier to change (for me at least).

But, if I had very strict time requirements, I could just drop in the 3ms version at any time to get the speed boost which I think is reasonable. I only need to bring in the operational complexity when the demand calls for it. Otherwise the more human readable version is fast enough for my use case.

Re: Why am I interested in Elixir?

#149

Earlier quoted context omitted.

Are there no bad parts?

The needlessly dynamic typing. In practice, Elixir data structures are rarely dynamic in nature. All structs have the same fields. Virtually all lists and maps and whatnot you end up writing will have the same type for all elements. Unlike in the JS ecosystem, there is no culture of having functions with, say, optional arguments in the middle, or arguments that can be either a number or a function or a Date object or…

I've never used a proper statically typed language for web development but with Elixir can't you solve the 90% with pattern matching and guards?

For example (taken from the docs on guards):

    def foo(term) when is_integer(term), do: term
    def foo(term) when is_float(term), do: round(term)
If you tried to pass a string into foo at run time, no function pattern would be matched and it would blow up. The above should also give IDEs a way to potentially say "hey, when you call foo, it accepts a term and expects an int or float", and it's also very human readable to figure out what you need to provide as arguments without IDE support.

What's interesting about guards is you can also put expressions in there. Like `when foo > 3` and now suddenly you have a new type of integer that only accepts integers greater than 3, except it's not an explicit IntegerGT3 type you have defined somewhere.

In practice, how much worse is that vs a "real" statically typed language, other than putting guards on things is optional?

Re: Why am I interested in Elixir?

#150
post #20
post #12

I'm currently building a video course hosting platform with Elixir / Phoenix and all I can really say is this has been the nicest tech stack I've ever used in 20 years of web development. IMO it really does feel like you get the best of everything (developer productivity, developer happiness, great language for creating maintainable code, OTP and the BEAM bring a lot to the table, it's memory efficient, tracing code…

I love hearing stories like yours. I wonder how Elixir would compare to Clojure, which I've used and liked for web development for many years. I hear nothing but good things about Elixir but I wonder if it would bring something new to the table for me in the "really liking it" category.

IMO BEAM is a better VM than JVM despite the number of libraries.

It provides a more robust, performant and observable platform for Web development. (Technically JVM is faster batch operations but for Web, most Elixir apps win)

More importantly, it's a perfect fit for immutable functional languages. Everything is immutable and proper tail-recursion are provided. Clojure is great but it has several different ways to define state and type, and sometimes I found they're a little bit awkward. With BEAM process, there's no need for language to have constructs for state/reference/async handling, which could makes the language itself more simpler and more compact.

Post reply on HN