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

211–220 of 246 posts

Re: Would you still pick Elixir in 2019?

#211

Post by quaunaut »

StreamBright wrote: post #175
quaunaut wrote: post #118

Earlier quoted context omitted.

That's even more work? Most developers already have redis/Postgres running, the issue there is the added complexity in complex operations. Not to mention, microservices are not always the answer. And even if they were, they're still an insane amount of more work than literally changing what functions you call. I'm not saying you should never use an RPC, but I've significantly reduced the times I'd want to use one. Th…

> Most developers already have redis/Postgres running You are joking right? You mean web developers?

Yes, web developers. Elixir is primarily a network systems language, and generally, the Ruby, Javascript, Python, etc communities use Postgres/Redis. Obviously it isn't universal, but there are obvious analogies(MySQL, etc).

Re: Would you still pick Elixir in 2019?

#212

Post by digitalzombie »

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.

I dislike coding in javascript for large project. The language was originally for small stuff.

NodeJS bought it to backend and the language itself weren't meant for it. Since then ECMA5 and stuff tried to fix these shortcomings. But you can't expect me to love javascript's weakly type versus elixir or python's strong type (strong not static, as in it doesn't implicitly type convert stuff like javascript). It's a nightmare and concurrency model in NodeJS in my opinion is subpar compare to Elixir's.

Re: Would you still pick Elixir in 2019?

#213

Post by pdimitar »

guscost wrote: post #68
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…

Thanks for these notes. I’m suspicious of unconditional praise for any technology, and a lot of the goodwill for Elixir seems like it’s biased by the intention to promote adoption of the language, or like it’s from people who haven’t encountered or paid attention to its problematic aspects. Seeing fundamental problems listed like this does more to convince me that it is a real and serious technology (one with a compe…

> I’m suspicious of unconditional praise for any technology, and a lot of the goodwill for Elixir seems like it’s biased by the intention to promote adoption of the language, or like it’s from people who haven’t encountered or paid attention to its problematic aspects.

I realize that the tone of this GitHub post has been a bit fanboy-ish and biased but you have to understand that your comment here is biased as well. It's non-objective to dismiss a technology because somebody couldn't articulate it as well as Mark Twain would. Most people simply aren't that good at articulation -- me included. Doesn't mean that what they are trying to articulate is invalid, wouldn't you say?

As for "fundamental problems" -- it's a case of "pick your poison" as usual. There is no universally good language. If you frequented the official Elixir Forum you would know that most of us use other technologies every day. Many people in the forum have 10+ years of experience and are well-aware of the big picture. We are very realistic about when Elixir is a good fit and when it isn't. There's a plethora of posts where we straight up advise somebody not to use Elixir.

IMO practice critical thinking and don't judge by the tone of isolated articles.

As a final point, you should also consider why the language has so much fanboy-like articles. Maybe it is doing something good for real? Objective thinking demands consideration of all major possibilities.

Re: Would you still pick Elixir in 2019?

#214

Post by Rotareti »

yawaramin wrote: post #197
Thaxll wrote: post #196

Earlier quoted context omitted.

The critical parts are run in C not Erlang. You think Erlang is fast enough to route packets? btw routing packets and running a backend are two different things.

When you said: 'With Kubernetes what's the point of BEAM?', what exactly were you talking about? How does Kubernetes make BEAM pointless?

It doesn't make BEAM pointless, but fault-tolerance and scalability (two of the core features of Elixir/BEAM) are also handled by k8s. If you use Elixir/BEAM for these features and deploy on k8s, it may seem redundant to use them both together. Maybe that's what parent is referring to.

Re: Would you still pick Elixir in 2019?

#215

Post by pdimitar »

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.

Pattern matching is strong typing. It just doesn't assert on a type alone -- it also asserts on the shape of the data itself. Example:

    def handle_data(%{
      customer: %{
        date_of_birth: %NaiveDateTime{} = dob,
        account_balance: %Decimal{} = balance,
        name: name,
        count_purchases: purchases
      }
    }) when is_binary(name) and is_integer(count_purchases) do
    # work with the data here
    end
^ This both asserts on a particular data structure (a map with a "customer" key containing at least those four attributes) and asserts on the types of some of the attributes. I find it pretty handy and practical.

---

But I concede that strong+static typing eliminates a class of bugs preliminarily. That is unequivocally true.

Re: Would you still pick Elixir in 2019?

#216

Post by yawaramin »

Rotareti wrote: post #214
yawaramin wrote: post #197

Earlier quoted context omitted.

When you said: 'With Kubernetes what's the point of BEAM?', what exactly were you talking about? How does Kubernetes make BEAM pointless?

It doesn't make BEAM pointless, but fault-tolerance and scalability (two of the core features of Elixir/BEAM) are also handled by k8s. If you use Elixir/BEAM for these features and deploy on k8s, it may seem redundant to use them both together. Maybe that's what parent is referring to.

K8s is great for service orchestration and horizontal scaling, and lots of people in the Elixir community use it to deploy, while using Elixir itself to implement fine-grained fault-tolerance logic and vertical scaling.

A dead BEAM process can be restarted in a few microseconds, load up some complex state, and keep going. I don't believe the same can be said of a dead K8s service.

Re: Would you still pick Elixir in 2019?

#217

Post by pdimitar »

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?

I've done several scrapers on Elixir and it has been times easier and better experience than with Go, JS and Ruby.

Re: Would you still pick Elixir in 2019?

#218

Post by crimsonalucard »

vonseel wrote: post #209
crimsonalucard wrote: post #184

Earlier quoted context omitted.

Most people (especially from type unsafe languages) haven't figured out that the Option type with pattern matching actually eliminates a whole class of runtime errors. They just see the match operator and types in general as a syntactical nuisance. fileString = checkFile("sample.txt") if(fileString == null){ //handle error } If I showed the above pattern to typical javascript, python, ruby or elixir programmers at an…

Well, yes, but that guy who advocates unit tests might understand all of this and the shortcomings of the chosen programming language, and that is why he advocates unit-testing. Careful who you are criticizing here :)

I never discounted unit tests. I advocate it as an important feature in a project. I'm saying you need significantly less when you have the types of checks I talk about in place. :)

The guy I'm criticizing here is a certain breed of person who advocates unit tests but suffers from a logical flaw in his reasoning. He advocates unit tests like a mad man but he uses an unsafe, untyped language for the entire project. Javascript is the worst offender here.

Unit tests are a safety first philosophy that is employed at the inconvenience of writing tests. However, it makes ZERO sense to employ unit tests as a safety net without type checking as a feature that proves your program is absent of type errors. Remember unit tests only verify a test case works, the safety features I talk about in my post actually Prove your program correct.

This is a huge flaw in engineering paradigms that I see permeate the industry today. People literally are ignoring a feature that proves a major part of your program correct and they are advocating the entire program be safe guarded with a weaker check (unit testing). I advocate we use both.

We see thousands of python, ruby and nodejs projects with massive unit testing overhead on top of the project itself. What these advocates don't realize is that you can get rid of 80% of these tests with a type safe language. I urge you to check the unit testing involved with a golang project vs javascript. There's usually a significant difference in size. For robust applications the unit testing suite of a javascript app is much much bigger in size.

I end with a quote from a guy who used logical methods to prove the absence of bugs in his programs rather then rely on hundreds of unit tests.

"Testing shows the presence, not the absence of bugs." - Dijkstra (1969).

Re: Would you still pick Elixir in 2019?

#219

Post by 1_player »

pmontra wrote: post #126
andy_ppp wrote: post #24

Earlier quoted context omitted.

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.

Ecto is not an ORM, and an ORM like ActiveRecord would never fit a functional, immutable language anyway. Ecto is a query builder and DSL.

But I may be biased, I _love_ Ecto and have been using it every day for the past year, and have never come across something as powerful yet lightweight (perhaps SQLAlchemy, ignoring its ORM features).

Post reply on HN