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

121–130 of 246 posts

Re: Would you still pick Elixir in 2019?

#121

Post by pmontra »

mrspeaker wrote: post #15

Could someone give a more concise reason for using Elixir? I have a "rule of 3" for checking out things - the third time I hear it mentioned and it seems interesting, then I'll go check it out. Elixir is past 3 times - so I will check it out for sure! - but this article didn't seem to actually say anything (seemed more like a PR piece that was trying not to be technical, and the main argument appeared to be "well, it…

Killer feature: pattern matching mixed with destructuring.

Bonus: parallelism almost for free.

If only GenServers had a sensible interface instead of semi random handle_* functions that obfuscate what a given GenServer is implementing.

Re: Would you still pick Elixir in 2019?

#122

Post by mnm1 »

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…

Workers and queues fail. SQS was down for us for almost two weeks while AWS fixed a bug. We had no choice but to wait or rewrite our implementation... Again! We've already had to rewrite once due to poor visibility and rare occasional problems processing data. Debugging such distributed systems is legendary hell. And that's just for simple async processing so that we can return a response quickly to the user and finish the task in a few seconds. There is simply no comparison between such a complex, failure prone distributed system and the simplicity, reliability, and ease of use of having support built into the language for this, IMO.

Re: Would you still pick Elixir in 2019?

#123

Post by hartator »

andy_ppp wrote: post #113
hartator wrote: post #111

Was very excited by Exilir coming from Ruby, however found 2 issues that made it hard to work with: - Pipelines are hard to debug. You can’t just throw a debugger just before the line with the issue. - Phoenix is very bad at serving static files. It was a nightmare to import a new CSS template requiring to convert everything to work with bower first, or dump the files in the /priv directory to make it work.

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.

Re: Would you still pick Elixir in 2019?

#124

Post by Thaxll »

arvidkahl wrote: post #88
hombre_fatal wrote: post #80

Earlier quoted context omitted.

> Elixir is VERY fault-tolerant. DB connection crashing? Ah well, reconnects immediately, while still serving the static parts of the application. PDF generation wonky? Same thing. I still don't understand this. I don't think I've ever built a web server in any language where this wasn't true unless I specifically wanted hard failure. The amount of fault tolerance would be a per-app design goal rather than something…

It's less about how it handles exceptions but rather how the BEAM makes sure that things that break don't crash the whole system. The magic is in the supervisor pattern, explained here for erlang: http://erlang.org/documentation/doc-4.9.1/doc/design_princip... It is hard to describe why this "feels different" in Elixir than it does in Express.js or a Tomcat running a Java application. It's all experiential for me, bu…

But with Kubernetes what's the point of BEAM?

Re: Would you still pick Elixir in 2019?

#125

Post by qwerty456127 »

ninjakeyboard wrote: post #97
qwerty456127 wrote: post #26

Isn't Elixir the most efficient thing available?

no elixir/beam is very slow for any computation-heavy tasks.

But what about not so computation-heavy tasks like parsing HTTP requests, interacting with databases, generating and serving responses based on the input, templates, reasonably simple logic and the data? And if it's not fast then why even consider it when there are more well-established alternatives like Ruby for those who like the syntax, ASP.Net/Core, Python/Django, Node/Express, Scala/Play for the FP lovers etc? I've been previously told it's key features are it's super fast, functional and Ruby-like.

Re: Would you still pick Elixir in 2019?

#126

Post by pmontra »

andy_ppp wrote: post #24
mrspeaker wrote: post #15

Could someone give a more concise reason for using Elixir? I have a "rule of 3" for checking out things - the third time I hear it mentioned and it seems interesting, then I'll go check it out. Elixir is past 3 times - so I will check it out for sure! - but this article didn't seem to actually say anything (seemed more like a PR piece that was trying not to be technical, and the main argument appeared to be "well, it…

I would say it's about developer happiness while coding and that all the decisions made by Jose and the core team tend to have been the correct decision. So taking Phoenix as an example you look at the framework and every time they find a problem i.e. Presence instead of saying that's a difficult problem and moving on they fix said problem in a really scalable way [1]. The same could be said for things like data proc…

Actually Ecto is the most unhappy part of the Elixir ecosystem to me. It's unnecessarily complicated for almost any software project. I'd even take Django's ORM instead of it, but what I want is something close to ActiveRecord. There are some Elixir modules similar to AR, none popular.

Re: Would you still pick Elixir in 2019?

#127

Post by hartator »

quaunaut wrote: post #115
hartator wrote: post #111

Was very excited by Exilir coming from Ruby, however found 2 issues that made it hard to work with: - Pipelines are hard to debug. You can’t just throw a debugger just before the line with the issue. - Phoenix is very bad at serving static files. It was a nightmare to import a new CSS template requiring to convert everything to work with bower first, or dump the files in the /priv directory to make it work.

> Pipelines are hard to debug. You can’t just throw a debugger just before the line with the issue. You absolutely can. Just change, ```elixir users |> send_email_with_money() |> do_complex_thing_that_crashes() ``` into ```elixir users = users |> send_email_with_money() require IEx; IEx.pry() ``` I turned the `require IEx; IEx.pry()` into a snippet just to make life as easy as it is in Ruby land. > - Phoenix is very…

Yeah, but you do need to edit your actual pipelined code to add a debugger. That's annoying.

> Well, two sides to this. For one, Phoenix uses Webpack now(since finally the war to see what app bundler would win is over).

We shouldn't force devs on Bower or Webpack. If I want to try out a new theme just bought on ThemeForest, it shouldn't take hours to make it compatible. Or to force to do the /priv/ hack that seems unelegant.

Re: Would you still pick Elixir in 2019?

#128

Post by jondubois »

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…

There are plenty of great, battle-tested frameworks and libraries in Node.js which help to leverage multiple cores but they just don't get as much hype.

Re: Would you still pick Elixir in 2019?

#129

Post by mrdoops »

zerr wrote: post #74

Considering progress in statically typed languages with regard to programmer ergonomics, does it still make sense to go with dynamic languages?

Between pattern matching and typespecs you get a lot of the "hey you're doing something wrong" checks at compile time to avoid errors. Definitely not a complete solution; a language like OCaml or F# will be better if you're concerned about type safety.

The dynamic typing in Elixir/Erlang is a trade-off for Actor model message passing. You get a state of the art run-time for fault tolerance and concurrency, but the messaging aspect makes typing problem-prone. A co-dependency on a custom type is coupling you want to avoid when sending messages around. You don't want a long running process that knows about Type_v1 sent a message from a newer process messaging with Type_v2.

The Aeternity team is building blockchain systems with Erlang for nodes and infrastructure. However since smart-contracts necessitate so much type safety and formal verification - they're designing an ML flavor functional language just for that.

Re: Would you still pick Elixir in 2019?

#130

Post by pmontra »

mooreds wrote: post #57

If you are coming to elixir from a rails background, how does it compare? I looked a year or two ago and the number of packages was far smaller with elixir, which turned me off of it.

There is more or less everything now. My complaint was the lack of and authentication framework and Coherence filled the void. I have no trouble finding modules to solve problems without coding the solution from scratch.
Post reply on HN