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

Re: Would you still pick Elixir in 2019?

#191

Post by awgm » Sun, Jan 06, 2019, 9:36 PM UTC

chillaxtian wrote: post #136

nelsonic wrote: post #100

Earlier quoted context omitted.

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

I really think that you don't need to utilize italics to make yourself appear like you care.

I found the emphasis helpful

Re: Would you still pick Elixir in 2019?

#192

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

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’ve been integrating a bootstrap framework

You do this for legacy systems. New systems should not use Bootstrap, there is much better out there.

Re: Would you still pick Elixir in 2019?

#193

Post by JoshuaScript » Sun, Jan 06, 2019, 9:38 PM UTC

jondubois wrote: post #128

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.

Are you mainly talking about clustering?

Re: Would you still pick Elixir in 2019?

#194

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

rthille wrote: post #171

Sees post recommends https://nerves-project.org for IoT Clicks thru Sees that Nerves is an excellent platform for IoT and only requires a base of 12MB and Linux. Quickly backs away.

Do you have an actual rational counterargument? It is a completely stripped-down Linux that boots directly into BEAM.

Re: Would you still pick Elixir in 2019?

#195

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

StreamBright wrote: post #185

_asummers wrote: post #10

Earlier quoted context omitted.

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

Wrk2 is not fast enough and will thus give spurious results since the bottleneck is the client.

The only measuring tool that is fast enough to accurately measure Phoenix performance is something like Tsung (which is also an Erlang app...)

Re: Would you still pick Elixir in 2019?

#196

Post by Thaxll » Sun, Jan 06, 2019, 9:55 PM UTC

yawaramin wrote: post #160

Thaxll wrote: post #124

Earlier quoted context omitted.

But with Kubernetes what's the point of BEAM?

BEAM is a battle-tested, decades-old technology that most likely runs a critical part of your telephone network. You're pretending that K8s, the newcomer, is already the incumbent. Are you sure you've done a proper assessment?

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.

Re: Would you still pick Elixir in 2019?

#197

Post by yawaramin » Sun, Jan 06, 2019, 10:02 PM UTC

Thaxll wrote: post #196

yawaramin wrote: post #160

Earlier quoted context omitted.

BEAM is a battle-tested, decades-old technology that most likely runs a critical part of your telephone network. You're pretending that K8s, the newcomer, is already the incumbent. Are you sure you've done a proper assessment?

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?

Re: Would you still pick Elixir in 2019?

#198

Post by skyde » Sun, Jan 06, 2019, 10:13 PM UTC

quaunaut wrote: post #118

skyde wrote: post #116

Earlier quoted context omitted.

If you need a request/response model (ex: query some data) and not simply queue an operation to execute later without waiting for it. I agree (worker/queue) are the wrong solution. But you should use a multi-language RPC framework like GRPC instead of building a distributed monolith. With kubernetes you have an endpoint per service that route and load balance to the correct machine. It seem to me you already got all…

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…

Calling a remote function is exactly the same as calling a service in both case you are doing an RPC. While doing a Rest service is more work, using something like GRPC or java RMI is not and also support pub-sub mechanism and give you have a clear interface that define which functions can be called remotely which make understanding the cost of the function call and the security implications a lot easier.

Re: Would you still pick Elixir in 2019?

#199

Post by abledon » Sun, Jan 06, 2019, 10:19 PM UTC

rehemiau wrote: post #170

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?

- chat / IMs backends - multimedia streaming - multiplayer game servers Generally soft real-time systems

what multiplayer game servers use elixir? can you give specific examples?

Re: Would you still pick Elixir in 2019?

#200

Post by jashmatthews » Sun, Jan 06, 2019, 10:23 PM UTC

quaunaut wrote: post #106

whalesalad wrote: post #91

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

Honestly? I'd still encourage you to do it. The thing that's nice about Elixir, is that it gives you the tools to screw up and make good on it. This isn't to say you'll write great Elixir from the beginning. I'm on a codebase now that was from back before the semantics of good Elixir were really well known(2016). It's not uncommon for me every week or two to rewrite a portion of it to look cleaner, and be more perfor…

> The crazy thing though? Holy shit did it scale. We're doing event processing for an application that is processing nearly 100m events per week. At times, it needs to process 1500 per second. These events need to check the DB multiple times, fan out to multiple services, and make discreet HTTP calls of their own to external servers.

Frameworks make a huge difference here rather than language. Phoenix and Ecto have done a really great job with performance.

Ruby will deliver the same performance on a similarly light framework like Sinatra/Roda + Sequel but definitely not Rails.

Once you get a high performance service running on Phoenix + Ecto or Sinatra + Sequel, the gains from moving to compiled languages are a lot smaller unless you invest a huge amount of time in optimisation.