Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Would you still pick Elixir in 2019?

github.com

Post reply on HN
Print view View original

141–150 of 246 posts

Re: Would you still pick Elixir in 2019?

#141

Post by quaunaut »

strokirk wrote: post #134
quaunaut wrote: post #112

Earlier quoted context omitted.

Something I'd also mention is, with Elixir, you'll get your MVP done maybe 10% slower than you would in Ruby. The difference is, in Ruby, after 2-3 months, you'll be rewriting large portions of what you did to get there. And in another year or two, you'll find yourself being blocked by earlier designs not for a day or two, but by a month of work or better. In Elixir, you simply will not experience that. Even if writt…

Doesn't that depend a lot on the project? Only one datapoint, of course, but we have an elixir project at work and it's in dire need of a refractor. The dynamic nature of the language doesn't help.

Thing is, it's not 100% dynamic. It's compiled, so most common refactor errors will be revealed by that alone(no function named, not the right number of arguments, etc). The harder to find things would be harder to find in most typed languages too, unless you had tests to point them out to you.

Re: Would you still pick Elixir in 2019?

#142

Post by mrdoops »

jrx wrote: post #71
lopatin wrote: post #53

Does anyone have experience with Elixir as well as Scala/Akka. Afaik, these are the two largest Erlang inspired systems out there. I only have experience with Akka, and I'd love to hear a comparison.

I've used both in production and I must say I'm a very big proponent of both. Actor model of concurrent computation I think maps very well to, at least my, way of thinking and I think is the most productive way of writing distributed systems. Elixir/Erlang/OTP: + Very mature, very well thought out. While the newer stuff may feel a still under construction (string handling, date handling) all the concurrency primitive…

Agreed. The BEAM run-time and the preemptive scheduler implementation is designed to never block and keep chugging a long; highly desirable for the Actor model. The trade-off is you're further from the metal and raw-compute isn't as powerful as a JVM language like Scala. That said an Actor model on the JVM (Akka) can't make the same run-time guarantees using a cooperative scheduler; instead you get all the enterprise libraries and developer hours to tap into. So the trade-off of more complexity in Scala/Akka is probably worth it for big enterprise who are probably already in bed with the JVM.

I think we'll see more Akka features built in Elixir through things like Genstage and Flow, but it's hard to argue with the mountain of exiting developer man-hours in the JVM.

Re: Would you still pick Elixir in 2019?

#143

Post by rehemiau »

hartator wrote: post #123
andy_ppp wrote: post #113

Earlier quoted context omitted.

Both of these points are False, point 2 I’ve been integrating a bootstrap framework and sass and it’s super simple; I put the files in assets, add npm install —save sass and that’s it! Then debugging a pipeline is as simple as dropping in IO.inspect between statements as it returns the content as well as printing. thing |> stage1 |> IO.inspect |> stage2 Not that difficult!

> I put the files in assets, add npm install —save sass and that’s it! It takes forever if your assets are large. Just serving random static files shouldn't take long. > IO.inspect It's nothing like a real debugger.

I agree about the inspect / pry not being a real debugger but could you expand on your problems with the debugger and pipelines?

Are you using the Erlang :debugger module?

The only "problem" I see is that we can't set a breakpoint on the first line of a Elixir pipeline, but to see the value of variable from that line we can set a breakpoint on the last line of the pipeline. To see why that happens we can try stepping through a pipeline with the debugger: First "executed" is the last line of the pipeline, then the second line, then third etc and it looks like for the debugger the first line of the pipeline never happened. I don't think this is a big problem to be honest.

Re: Would you still pick Elixir in 2019?

#144

Post by klibertp »

strokirk wrote: post #134
quaunaut wrote: post #112

Earlier quoted context omitted.

Something I'd also mention is, with Elixir, you'll get your MVP done maybe 10% slower than you would in Ruby. The difference is, in Ruby, after 2-3 months, you'll be rewriting large portions of what you did to get there. And in another year or two, you'll find yourself being blocked by earlier designs not for a day or two, but by a month of work or better. In Elixir, you simply will not experience that. Even if writt…

Doesn't that depend a lot on the project? Only one datapoint, of course, but we have an elixir project at work and it's in dire need of a refractor. The dynamic nature of the language doesn't help.

That's one of the things you lose when going from Erlang to Elixir. Sure the macros are useful and convenient, but they also make the code less explicit and harder to refactor. There's probably a reason why Erlang for the past 30 years had no macros, despite being a homoiconic language.

TLDR: try working with Erlang if you find your Elixir code-base in need of a refactor - chances are you'll learn conventions which will help you write more maintainable code in Elixir, too.

Re: Would you still pick Elixir in 2019?

#145

Post by romanhn »

abledon wrote: post #120

can people give real world business use cases for where they are using elixir? What industries are you working in? what actually gets done in the real world at the end of the day with the system you're working on? e.g. are more ads served to web users? are you monitoring methane on IOT things strapped to cows in farm fields?

PagerDuty has standardized on Elixir as the backend language of choice after a couple of years of incremental adoption with new services. Developer happiness definitely helped get the word spread. https://www.pagerduty.com/blog/elixir-at-pagerduty/

Re: Would you still pick Elixir in 2019?

#146

Post by toast0 »

arcticfox wrote: post #83
artellectual wrote: post #31

I’ve been programming in elixir for about 2 years now. I have to say it’s hard to go back to something like Ruby or JavaScript. In elixir you really get the full power of multi core and support for distributed computing out of the box. Code that would have been beyond my pay grade or wouldn’t even imagine to write in Ruby or JavaScript is now easily reasoned about and maintained in projects. I can write succinct code…

> If you need multi core and distributed features (which is generally more common than you think) elixir is truly your friend. Is it though? At least in my line of work I don't think I've ever run into this. I feel like I've always been able to distribute just fine with workers/queues. If I even suspected it would I'd look into it more, but generally I find distributing across systems to be a software architecture-le…

I'm a big fan of Erlang, but I think you can acheive similar things in other languages with queues and workers. Erlang's advantage here is that you can do easily do a worker per client connection, for almost any number of client connections; for data processing queues, the lack of data sharing between processes (threads) strongly pushes you towards writing things in a way that easily scales to multiple queue workers -- you can of course write scalable code in other languages, but it's easier to write code with locking on shared state when shared state is easier.

As for distribution, again, this isn't necessarily exclusive, but the right primatives are there and work well to start with. You could have good reasons for a bigger separation between nodes as well.

Erlang has some warts too, of course. For me, the warts are usually about scale, oddly enough. BEAM itself scales very well, but some parts of the OTP don't, often because of the difference in expectations between a telcom environment and a large scale internet service. Two examples:

A) the (OTP) tls session cache is serviced by a single process and in earlier versions, the schema and queries were poorly designed so you could store multiple entries for a single destination, and the query would retrieve all and then discard all but the first. When you were making many connections to a host that issued sessions but didn't resume them, all of the extra data could overwhelm that one process, and resulting in timeouts attempting to connect to any tls host. This was fixed in a release after r18, I believe, to store only one session per cache key, and the cache was plugable before then, but it wasn't fun to find this out in production.

B) reloading /etc/hosts and querying the table it loads into weren't done in an atomic way. I believe this is fixed in upstream as well, but queries satisfied by /etc/hosts were actually two queries on the same table, and reloading the table was done by clearing and then loading, so the second query could fail unexpectedly. This led to the bundled http client getting stuck, despite timeouts.

Re: Would you still pick Elixir in 2019?

#147

Post by pulisse »

artellectual wrote: post #31

I’ve been programming in elixir for about 2 years now. I have to say it’s hard to go back to something like Ruby or JavaScript. In elixir you really get the full power of multi core and support for distributed computing out of the box. Code that would have been beyond my pay grade or wouldn’t even imagine to write in Ruby or JavaScript is now easily reasoned about and maintained in projects. I can write succinct code…

> In elixir you really get the full power of multi core and support for distributed computing out of the box. Code that would have been beyond my pay grade or wouldn’t even imagine to write in Ruby or JavaScript is now easily reasoned about and maintained in projects.

One of the alternative languages you mention is single-threaded, and the other has a global interpreter lock (in its most common implementation). That Elixir is superior to them for parallel programming doesn't really say much.

Re: Would you still pick Elixir in 2019?

#148

Post by pmarreck »

hota_mazi wrote: post #86
phtrivier wrote: post #58

Elixir has great things "of his own": * the syntax is well though-of (`with`, destructuring, `|>` are powerful * message passing has great use-cases And then it has problems that are not necessarily "elixir-y", but are there nonetheless: * it's hard to model an application around the Actor model. It's very easy to abuse it. * it's hard to maintain / refactor a large application without help from the compiler before r…

The fact that it's dynamically typed is also often overlooked, while it's at the top of my deal breaker list. The programming world is strongly moving toward statically typed languages, because today, there's pretty much zero reasons to use a dynamically typed language.

Static typing incurs restrictive boilerplate while only eliminating a small subset of all possible bugs. I will admit the guarantees it gives you are nice but I’d argue that the guarantees immutability-all-the-way-down gets you in a language like Elixir are stronger. You don’t get those guarantees on ANY of the statically-typed languages that run on the JVM because as soon as you interop with anything Java, bye-bye guarantees.

And this is anecdotal but with good pattern-matching and guards in Elixir, I can’t remember the last time I created a bug that would have been made impossible by static typing.

Re: Would you still pick Elixir in 2019?

#149

Post by petre »

troquerre wrote: post #137

What kind of problems are people using Elixir to solve in production? My impression is it’s mainly useful for highly networked applications with real-time features (i.e. chat), but it seems like for most applications you’d be better off picking rails or nodejs for the community/ecosystem.

> for most applications you’d be better off picking rails or nodejs for the community/ecosystem

Only to find out they do not scale very well after your application is mature and used by a growing number of clients.

Re: Would you still pick Elixir in 2019?

#150

Post by pmarreck »

sb8244 wrote: post #36

I've been fortunate to work with a CTO that sees the value in Elixir and also letting us push forward with it. It has been excellent . At this point we have about 20 engineers who have chosen to work in it close to full time for their services. It's hard to pick one big draw, but I'd say the biggest for me is that everything I wanted to do in rails has been possible in Elixir and then additional functionality not eas…

> everything I wanted to do in rails has been possible in Elixir and then additional functionality not easily possible in rails is trivial in Elixir

I also noticed that every functionality I write in both Ruby and Elixir is both more concise (less code) in Elixir as well as 5-10x faster :)

Post reply on HN