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

91–100 of 246 posts

Re: Would you still pick Elixir in 2019?

#91

Post by whalesalad »

This post is killing me. I’ve been really really loving Elixir and for a while was fighting the “everything looks like a nail” syndrome once I learned it.

But now I have a contract that would really benefit from the runtime. That being said the existing environment has a lot of python expertise and I don’t have enough production Elixir experience to have confidence in myself to deliver something of the right caliber.

It’s a damn shame. This system has to process hundreds of thousands of API calls for workloads against a half dozen third parties that all have different rate limits and failure modes. It’s the perfect job for Elixir. It needs to be as fast as possible while isolating failures to the smallest unit possible.

Re: Would you still pick Elixir in 2019?

#92

Post by arcturus17 »

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.

> The programming world is strongly moving toward statically typed languages

How? Python and Javascript (not Typescript) are two of the most popular languages in the world and still growing very fast by many accounts. Which strongly typed languages are taking over?

Re: Would you still pick Elixir in 2019?

#93

Post by markkanof »

therealmarv wrote: post #47
bicx wrote: post #41

Earlier quoted context omitted.

If you have a solid background in software development, it's not too hard to become proficient in Elixir in a few weeks. If you recruit good talent with a demonstrated proficiency and willingness to learn, you will be fine. If you need to switch languages or systems in the future, these devs will still be of great use to you.

Ok, that sounds good. My overall experience is only for most companies (I'm working as a contractor for many years) that they don't really want to invest in you. Either you fit for the job or not (and competition is not easy sometimes).

I can’t argue with this point in general, but your first question was from the perspective of a company. There certainly are companies, that are willing to use things like Elixir (like my company for example) because we believe that an experienced developer should be able to come up to speed quickly with Elixir. What really takes the time is learning our business domain and our existing codebase. Or looking at it another way, I wouldn’t want to hire someone that was a Rails dev, I would want to hire someone that was a strong dev in general and may have happened to be doing Rails most recently.

Re: Would you still pick Elixir in 2019?

#94

Post by chrisco255 »

forty wrote: post #44
symboltoproc wrote: post #17

The JavaScript Fatigue argument is not good. There's simply no data that backs it and nobody is forced to use new libraries only because they use JavaScript. I've seen third party dependencies churn on Elixir as well (packages that are no longer maintained or alternatives that are better) - I think it's an inherent problem with using dependencies and has nothing to do with the programming language in which those depe…

> nobody is forced to use new libraries only because they use JavaScript. It's not completely true IMO for 2 reasons: 1- the nodejs standard lib is quite poor compared to say, Java's, Scala's or python's, so you generally need quite a lot of modules to do anything 2- the npm ecosystem is much more amateur. To do anything you have a ton of poorly supported by hobbyists or not supported at all modules. This can force y…

Yeah but on Node.js, Express has been the de facto framework of choice for building REST APIs for over 6 years. The JS fatigue phenomenon was mostly on the front end, and even that has basically settled down as people have rallied around React, Angular and Vue.

Re: Would you still pick Elixir in 2019?

#95

Post by chrisco255 »

no_wizard wrote: post #89
symboltoproc wrote: post #17

The JavaScript Fatigue argument is not good. There's simply no data that backs it and nobody is forced to use new libraries only because they use JavaScript. I've seen third party dependencies churn on Elixir as well (packages that are no longer maintained or alternatives that are better) - I think it's an inherent problem with using dependencies and has nothing to do with the programming language in which those depe…

I’m not calling out JS or elixir communities by any means here. I just want to mention that a big part of the “JavaScript Fatigue” is the amount of overlapping libraries that all do the same thing and it isn’t always straightforward to figure out which one is better - and this happens with so many packages it would be impossible to do it with all of them. Just look up “isArray” (which I wish where just not showing up…

It's no more difficult than choosing an app in the app store. You go on NPM, you look at the download count, you look at the feature set, you install and then move on with your day. JS is a vast and very open ecosystem so duplication is inevitable.

Re: Would you still pick Elixir in 2019?

#96

Post by ninjakeyboard »

ninjakeyboard wrote: post #56
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 have experience with both. I have recently been working with Elixir. It's okay. I find the lack of static typing to be some thing I celebrate and curse. Elixir is VERY simple and beam is VERY slow at computation. I wouldn't recommend anyone working with scala/akka look at elixir unless you want to understand how BEAM works but I would recommend _everyone_ working with elixir learn different functional programming l…

Also, I have to say that elixir developers are generally not very experienced with it and seem to be generally less desirable than the people who are working with scala. You get rubyists that have some interest in working with elixir because there were some blog posts saying it's the new hotness. Scala seems to attract more comp-sci savvy people. And generally those people will refuse to work with elixir when there are Scala job out there that will pay. Startups should use scala for these reasons. Elixir may be a mistake for the resource pool alone.

One thing that's trecherous is that rubyists can bring whatever they believe to be the right way to do things and assume everything should be exactly the same, especially with regards to ecto vs active record. Elixir isn't ruby. Ecto isn't rails active record. Not anywhere close. It just happens to look like ruby and there are some influences in the design but Ecto tells you not too implement STI like rails does for example so don't assume you're going to do it like you would in rails. I'd argue ruby is more like scala than it is like elixir as it has multiple paradigms. Elixir is squarely functional, just a very very simple functional language. The skill ceiling is pretty low and it should take very little time for someone to get up to speed which is important because you won't find a big pool of rockstars using it in the job market so you'll have to hire good people without experience and hope they will be okay using elixir and not jump ship to go work with strong typed languages.

Re: Would you still pick Elixir in 2019?

#98

Post by PopeDotNinja »

neathack wrote: post #76

I have never used Elixir, so maybe it's a great language, maybe not. But I have to question the reasoning of the post simply going by the comments about other languages in the "Conclusions" sections — some of which I did use extensively. Really, Go "is the choice if you need to 'sell it' to a 'Boss'" and the imperative programming style leads to more complexity? And Python/Django can only be used if you "don't need a…

I really like Elixir. There are a lot of practical realities that can make Elixir not the best language to use in many situations, and the same is true for any language. Just ignore the hype train, because you'll find one for every language.

I'd say Elixir's killer feature in today's day & age is concurrency. I'd argue that using concurrency is appropriate in most programming situations IF your language's concurrency model isn't a pain in the ass to use. You can write completely non-blocking, async code in Elixir (and Erlang) without losing your mind. The preemptive scheduling is nice, too.

I love a lot of other stuff about Elixir, too. Pattern matching, process supervision, tooling, documentation, etc.

Re: Would you still pick Elixir in 2019?

#99

Post by y4mi »

chrisco255 wrote: post #94
forty wrote: post #44

Earlier quoted context omitted.

> nobody is forced to use new libraries only because they use JavaScript. It's not completely true IMO for 2 reasons: 1- the nodejs standard lib is quite poor compared to say, Java's, Scala's or python's, so you generally need quite a lot of modules to do anything 2- the npm ecosystem is much more amateur. To do anything you have a ton of poorly supported by hobbyists or not supported at all modules. This can force y…

Yeah but on Node.js, Express has been the de facto framework of choice for building REST APIs for over 6 years. The JS fatigue phenomenon was mostly on the front end, and even that has basically settled down as people have rallied around React, Angular and Vue.

Uh, what?

It might've become the defacto standard for consuming them, but definitely not for creating them.

Almost no service I've ever administered used a nodejs backend.

Re: Would you still pick Elixir in 2019?

#100

Post by nelsonic »

chmln wrote: post #78

This went past me as the post is filled with a lot of claims with no reasoning to back those up. It is not a critical evaluation of the language, but rather sounds like a "fanboy" piece, for the lack of a better term. > Memory efficiency is much better than most other languages (with the exception of Rust, but Elixir is miles better at Error handling than Rust, which is a more practical feature IMO How exactly are ar…

@chmin thanks for the great feedback! ;-)

I did not write the post for general consumption, more as a reply to the question from the person as indicated in the first paragraph of the thread ... I really did not expect it to end up on HN. ¯\_(ツ)_/¯

100% Agree that there is a lack of "critical evaluation" and it borders on "fanboy" ... It's not a scientific or statistical analysis because I did not find any data I could use to make a an argument either way.

My experience with Elixir, JavaScript, Ruby, Java, PHP, etc. is based on doing the work in several companies big and small and I don't consider myself an "expert" in any of these languages. I have felt the pain of having to maintain/debug several large codebases with incomprehensible/impenetrable and untested code over the years and I find Elixir to be the most approachable of the languages I am fluent with.

I wish there was an objective way of assessing the day-to-day experience of living with a language ... have you come across such a measure that isn't based on the opinions of, as you say, "fanboy" users?

You appear to have superior knowledge/experience of Rust. Have you written any tutorials or blog posts sharing that knowledge? I would love to read your work. Is this you: https://github.com/chmln ? If it is, https://github.com/chmln/asciimath-rs looks cool! (nice work! :-)

Post reply on HN