Would you still pick Elixir in 2019? • Hacker News Board

Re: Would you still pick Elixir in 2019?

#181

Post by himaraya » Sun, Jan 06, 2019, 9:16 PM UTC

yawaramin wrote: post #164

hota_mazi wrote: post #86

Earlier quoted context omitted.

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.

I agree and believe that it's harder to maintain a dynamically-typed codebase, but Elixir has a well-thought-out gradual typing solution: typespecs ( https://hexdocs.pm/elixir/typespecs.html#basic-types ). This builds on Erlang's Dialyzer tool and is supported by editor plugins like VSCode's ElixirLS extension. In practice, you do get instant typechecking while you code, if you write down the typespecs properly.

Debatable in practice, given the lack of a type system that actually enforces checks -- Dialyzer's even less complete, not to mention its poor error messages.

Elchemy, Alpaca, and Gleam try bringing static typing to the BEAM, but they're still too immature, unfortunately.

Re: Would you still pick Elixir in 2019?

#182

Post by StreamBright » Sun, Jan 06, 2019, 9:18 PM UTC

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.

You must be joking. I never heard of Express and we have put several REST APIs into production in several companies.

Re: Would you still pick Elixir in 2019?

#183

Post by subfay » Sun, Jan 06, 2019, 9:19 PM UTC

jondubois wrote: post #107

>> Node is a single-threaded event loop, if the process crashes for one user, it crashes for all the requests being handled by that process. i.e. one user can crash the server for hundreds/thousands of people! This is a terrible design flaw This is a design flaw on the part of the team who is using Node.js incorrectly and not a flaw of Node.js itself. There are many ways to implement error handling properly in Node.j…

Couldn't agree more. Just look at Google Tends. Because Elixir is dying they do more and more content marketing: https://trends.google.com/trends/explore?geo=US&q=%2Fm%2F0pl...

In their Slack channel they orchestrate organized upvotes of such post like this one, they collectively downvote people like the parent and post fanboism through several accounts.

Elixir is a solution without a problem.

Re: Would you still pick Elixir in 2019?

#184

Post by crimsonalucard » Sun, Jan 06, 2019, 9:25 PM UTC

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…

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 any company, 99% of them won't be able to identify why this pattern is bad, they see it as a necessity and rely on the programmers skill to catch that potential null (or exception depending on the implementation).

In fact, you dear reader, might be one of those programmers. You might be reading this post and not understanding why the above code is an unsafe and a bad style. To you, I say that there are actually compilers that automatically prove and force you to handle that potential null not as a logic error but more as if it was a syntax error.

That guy who advocates unit tests at your company doesn't understand that unit tests only verify your program is correct for a test case. These compilers provide PROOF that your program is correct and can eliminate the majority of the tests you typically write.

The code above is unsafe not because of the developer, it is unsafe because of the nature of the (made up) programming language.

In elixir, python and javascript you will inevitably have to follow this unsafe pattern.

Re: Would you still pick Elixir in 2019?

#185

Post by StreamBright » Sun, Jan 06, 2019, 9:26 PM UTC

_asummers wrote: post #10

StreamBright wrote: post #6

Elixir just really nice. I gave it a shot again and it is super smooth experience nowadays. Distillery, mix, iex https://github.com/aws-samples/aws-lambda-elixir-runtime The only downside is that the out of the box performance is subpar for http services but it is still acceptable.

Cowboy measures its latency in microseconds, what bottlenecks are you running into specifically?

Not really, you can't have a microsecond latency talking over a network. I understand localhost microbenchmarks are nice but real life scenarios are much better.

The setup for the test:

- provision node A for being the server

- provision node B for being the client

- open X (16..16000) connections from node A and use http pipelining start to send requests to node B

I use wrk2 as the test client it is pretty amazing and looking at the latency distribution graphs.

Tools that clear winners of performance:

- https://github.com/valyala/fasthttp

- https://www.rapidoid.org

Elixir/Cowboy/Plug is in the middle range, kind of like what Techempower[1] guys saw during their tests.

[1] https://www.techempower.com/blog/2018/10/30/framework-benchm...

Re: Would you still pick Elixir in 2019?

#186

Post by pmarreck » Sun, Jan 06, 2019, 9:26 PM UTC

latch wrote: post #60

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…

It's the synergy between the language, the runtime and the standard library to deliver the actor model. Elixir "threads" are called "processes". It's a bit confusing at first, but there's a good reason for it. So from hereon in, when I say "process" think "thread". Elixir processes, like OS processes, are fully isolated from each other. If Process A has data than Process B wants, Process A has to ask it (send it a me…

Spotted the BleacherReport guy (...I think!) ;)

Re: Would you still pick Elixir in 2019?

#187

Post by StreamBright » Sun, Jan 06, 2019, 9:27 PM UTC

RobertKerans wrote: post #19

_asummers wrote: post #10

Earlier quoted context omitted.

Cowboy measures its latency in microseconds, what bottlenecks are you running into specifically?

I assume perf comment is in relation to AWS Lambda, for which the Elixir example they've put up is severely below par perf wise

I am talking about raw HTTP request handling performance. Elixir/Cowboy/Plug is in the middle range of web servers. Again, it is good enough for most use cases.

Re: Would you still pick Elixir in 2019?

#188

Post by undersheet » Sun, Jan 06, 2019, 9:29 PM UTC

This feels like an orchestrated upvoting and content marketing flash mob from the Elixir Slack channel. Google Trends shows that Elixir is declining. I love new languages but don't like to be fooled.

Re: Would you still pick Elixir in 2019?

#189

Post by StreamBright » Sun, Jan 06, 2019, 9:30 PM UTC

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…

Scala/Akka has a much worse developer experience than Elixir/Phoenix. BEAM is fairly slow but you can make FFI calls into much faster implementations if your workload is CPU bound (most of the workloads I am familiar with in the web world are not).

Release less broken code to production? I am not sure about it either.

Re: Would you still pick Elixir in 2019?

#190

Post by jashmatthews » Sun, Jan 06, 2019, 9:32 PM UTC

quaunaut wrote: post #102

arcticfox wrote: post #83

Earlier quoted context omitted.

> 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…

Until I used Elixir, I thought workers/queues were enough. But after the last nearly-three-years, I've actually fallen into a place where workers/queues are almost always strictly inferior. Workers/queues in languages like Ruby have problems like, * Require very specific ergonomics(for example, don't hand the model over, hand over the ID so you can pull over the freshest version and not overwrite) * They require a se…

Erlang/Elixir has some really great advantages in concurrency and parallelism but what you're describing are just badly designed systems.

Shopify, for example, use Resque (Ruby + Redis) to process thousands of background jobs per second.

> * Require very specific ergonomics(for example, don't hand the model over, hand over the ID so you can pull over the freshest version and not overwrite)

This is good practice but certainly not a requirement. You can pass objects in a serialized format like JSON or use Protobuf etc.

> * They require a separate storage system, like your DB, Redis, etc. This doesn't sound big, but when doing complex things it can turn into hell.

ETS and Mnesia aren't production ready job queues, unfortunately: https://news.ycombinator.com/item?id=9828608

> * They have to be run in a separate process, which makes deployment more difficult.

Background tasks have different requirements so this is a good idea regardless.

> * They're slow. Almost all of them work on polling the receiving tables for work, which means you've got a lag time of 1-5 seconds per job. Furthermore, the worse your system load, the slower they go.

Redis queues have millisecond latency and there's no polling. Resque and Sidekiq use the BRPOP to wait for jobs. BRPOP is O(1), so it doesn't slow down as the queue backs up.

PG has LISTEN/NOTIFY to announce new jobs or the state change of an existing job so there's no need to poll. SKIP LOCKED also prevents performance degrading under load.

> * You can't reliably "resume" from going multi-process. Lets say you're fine with the user waiting 2-3 seconds to have a request finish. With workers/queues, you either have to poll to figure out when something finished(which is not only very slow, but error prone), or you have to just go slow and not multi-process, making it into a 8-10 second request even though you've got the processing power to go faster.

There are multiple other options here which are better:

Threads - GIL allows parallel IO anyway and JRuby has no GIL

Pub/Sub - Both Redis and PG have a great basic implementation usable from the Ruby clients

Websockets - Respond early and notify directly from the background jobs