Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Elixir (2014)

theerlangelist.com

Post reply on HN
Print view View original

11–20 of 71 posts

Re: Why Elixir (2014)

#11

Post by sph »

theonething wrote: post #8
sph wrote: post #4

Earlier quoted context omitted.

Anything that spends most of its time waiting on IO, and doesn't do a great deal of number crunching: i.e. any kind of server talking over a network socket. Go, and any other language, lowers the barrier to running concurrent code, but there is much more to concurrent servers than concurrency: fault tolerance, isolation, shared state management, instrumentation, introspection, clustering, process migration. The BEAM…

> Data races are impossible As far as the application code goes, but most systems have databases which opens you up to all kinds of race conditions. Does Elixir help in that case?

Modern relation databases are not a concern at all. You get race conditions if the developer has only a passing knowledge of SQL, because otherwise that's a basically solved problem, with the existence of transactions, isolation modes, etc. If all else fails, your query throws an error, but it does not corrupt your database.

Much more common instead are race conditions on local storage, external APIs and traditional memory races when using unsophisticated languages.

Re: Why Elixir (2014)

#12

Post by sarchertech »

sph wrote: post #11
theonething wrote: post #8

Earlier quoted context omitted.

> Data races are impossible As far as the application code goes, but most systems have databases which opens you up to all kinds of race conditions. Does Elixir help in that case?

Modern relation databases are not a concern at all. You get race conditions if the developer has only a passing knowledge of SQL, because otherwise that's a basically solved problem, with the existence of transactions, isolation modes, etc. If all else fails, your query throws an error, but it does not corrupt your database. Much more common instead are race conditions on local storage, external APIs and traditional…

There’s a lot to learn about transaction isolation levels. I’d bet 90% of developers don’t know anything about them.

Also using serializable isn’t free.

Re: Why Elixir (2014)

#13

Post by nesarkvechnep »

bhupesh wrote: post #3
sph wrote: post #2

From the author of this post, here's one of the best demos of Elixir, Erlang and modern distributed computing in general: "The Soul of Erlang and Elixir • Saša Jurić • GOTO 2019" - https://www.youtube.com/watch?v=JvBT4XBdoUE When you feel sufficiently amazed by this demo, I also recommend the Elixir in Action book, by this same author, to get started with this incredible ecosystem and paradigm. --- It's hard to imagi…

Soul of erlang got me hooked to Elixir recently, trying to get my hands dirty as well. Other than distributed/concurrent system use-cases, could you share what kind of products are best when built with elixir/erlang compared to easier to write languages like Go, for example.

Easier to write by whom? I ask because to me, Go has one of the ugliest syntaxes I've seen. On the other hand Elixir is very easy to write.

Re: Why Elixir (2014)

#14

Post by benmmurphy »

theonething wrote: post #8
sph wrote: post #4

Earlier quoted context omitted.

Anything that spends most of its time waiting on IO, and doesn't do a great deal of number crunching: i.e. any kind of server talking over a network socket. Go, and any other language, lowers the barrier to running concurrent code, but there is much more to concurrent servers than concurrency: fault tolerance, isolation, shared state management, instrumentation, introspection, clustering, process migration. The BEAM…

> Data races are impossible As far as the application code goes, but most systems have databases which opens you up to all kinds of race conditions. Does Elixir help in that case?

Races within an elixir application are still possible it is just data races that are prevented. For example if you have a bank account in an elixir process nothing will stop you from implementing a withdrawal as 2 external operations: read balance, write balance which is inherently racy but not a data race.

Re: Why Elixir (2014)

#15

Post by [deleted] »

sph wrote: post #10
dpflan wrote: post #9

Earlier quoted context omitted.

Sounds good, you make it sound like that Elixir is now your de-facto, even for non-distributed systems projects?

Servers are 99% of the code I write, so yes I choose Elixir, though for very conservative clients and small projects I use Go. For everything else, which is not a lot, there's Rust, Scheme, Lisp and many other fun languages to explore. My focus these days is on my business rather than consulting, so I have a lot of freedom.

[deleted]

Re: Why Elixir (2014)

#16

Post by jimbokun »

sph wrote: post #4
bhupesh wrote: post #3

Earlier quoted context omitted.

Soul of erlang got me hooked to Elixir recently, trying to get my hands dirty as well. Other than distributed/concurrent system use-cases, could you share what kind of products are best when built with elixir/erlang compared to easier to write languages like Go, for example.

Anything that spends most of its time waiting on IO, and doesn't do a great deal of number crunching: i.e. any kind of server talking over a network socket. Go, and any other language, lowers the barrier to running concurrent code, but there is much more to concurrent servers than concurrency: fault tolerance, isolation, shared state management, instrumentation, introspection, clustering, process migration. The BEAM…

In other words, Erlang and Elixir push the capabilities of Kubernetes down into the language itself.

Re: Why Elixir (2014)

#17

Post by elicksaur »

bhupesh wrote: post #3
sph wrote: post #2

From the author of this post, here's one of the best demos of Elixir, Erlang and modern distributed computing in general: "The Soul of Erlang and Elixir • Saša Jurić • GOTO 2019" - https://www.youtube.com/watch?v=JvBT4XBdoUE When you feel sufficiently amazed by this demo, I also recommend the Elixir in Action book, by this same author, to get started with this incredible ecosystem and paradigm. --- It's hard to imagi…

Soul of erlang got me hooked to Elixir recently, trying to get my hands dirty as well. Other than distributed/concurrent system use-cases, could you share what kind of products are best when built with elixir/erlang compared to easier to write languages like Go, for example.

“Easier to write” has to be bait, right? That’s entirely subjective. Someone out there might think Assembly is easiest to write.

Re: Why Elixir (2014)

#18

Post by anonyfox »

nesarkvechnep wrote: post #13
bhupesh wrote: post #3

Earlier quoted context omitted.

Soul of erlang got me hooked to Elixir recently, trying to get my hands dirty as well. Other than distributed/concurrent system use-cases, could you share what kind of products are best when built with elixir/erlang compared to easier to write languages like Go, for example.

Easier to write by whom? I ask because to me, Go has one of the ugliest syntaxes I've seen. On the other hand Elixir is very easy to write.

I use both on a regular basis for many years now (and some others), and I'd say it depends.

Elixir matches the way my brain thinks somehow, with (kind of) pure functions transforming data step by step, and when you can break down some task in such a way its only a simple set of pipelines (|>) its really great and feels great. It is also exceptionally cool if you spawn Agents to hold some global state where multiple processes talk with it, plus the integrated stateful introspection/debugging is just chefs kiss. In the context of pg's "Blub Paradox" Elixir is an acceptable Lisp (not homoiconic, but with modern tooling). You can solve very complicated problems in very clean ways. Also often underrated: Phoenix/LiveView is probably the best escape hatch out of JS frontend hell alltogether, and leads to better outcomes (performance, scalability, sanity, maintainability, ...) compared to JS frameworks.

On the other hand, sometimes I have a very dirty real life thing I want to achieve. Like doing some Unix stuff, interacting with some ugly APIs, implementing an given imperative algorithm to brute force a problem quickly within reasonable constraints, manipulate some image file, automate some adhoc outlook365 process, ... you name it. The weakness of Go (extremely simple/plain, verbosity, boilerplate, ...) here is actually the strength of it in these cases, but took me a while to realize. In Go, I don't even care anymore to make anything "elegant" (which is very tempting in Elixir!), but write the absolute straightforward series of steps in brutal directness, including nested loops and very long functions. This leads to rapid dirty work solving, and has the added benefit of trivial distribution (cross-compile to a single self contained binary) to other folks that don't have dev dependencies installed. Also I rely solely and the compiler/linter for this type of code and have zero tests for it (I am not going to mock the filesystem interactions and all that for basically a better ad hoc shell script).

So for the big/complex/scalable projects, I think Elixir/Phoenix is just perfect in terms of a "web stack", only a few rough edges left in iE the docs for beginners looking into LiveView. But for the small ad-hoc stuff or in situations where I can "brute force" my way through an ad hoc problem, Go is it.

Just my 2 cents.

Re: Why Elixir (2014)

#19

Post by maleldil »

nesarkvechnep wrote: post #13
bhupesh wrote: post #3

Earlier quoted context omitted.

Soul of erlang got me hooked to Elixir recently, trying to get my hands dirty as well. Other than distributed/concurrent system use-cases, could you share what kind of products are best when built with elixir/erlang compared to easier to write languages like Go, for example.

Easier to write by whom? I ask because to me, Go has one of the ugliest syntaxes I've seen. On the other hand Elixir is very easy to write.

> Easier to write by whom?

Most people? I have no love lost for Go, but most (if not all) programmers have experience with imperative code, making it very easy to learn, even if the syntax is ugly. Elix is from a different paradigm, so you have to learn that in addition to the syntax.

Re: Why Elixir (2014)

#20

Post by williamdclt »

sph wrote: post #2

From the author of this post, here's one of the best demos of Elixir, Erlang and modern distributed computing in general: "The Soul of Erlang and Elixir • Saša Jurić • GOTO 2019" - https://www.youtube.com/watch?v=JvBT4XBdoUE When you feel sufficiently amazed by this demo, I also recommend the Elixir in Action book, by this same author, to get started with this incredible ecosystem and paradigm. --- It's hard to imagi…

I’m an elixir noob, but I’m actually surprised that the distributed story is not _better_. For example, a big thing about OTP is that it allows running many processes that communicate by message passing: but all these processes are _colocated_ to a given node, i would have expected that OTP (or genserver or whatever) handles clustering of machines, scheduling of workloads and routing of messages for me so that I can start processes and call them without caring about where they run.

What about “distributed systems” is elixir actually shining at? From my reading, it seems rather like a good option to _avoid_ distributing (thanks to the light processes and concurrency handling)

Post reply on HN