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

61–70 of 71 posts

Re: Why Elixir (2014)

#61

Post by mike1o1 »

cgopalan wrote: post #59
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…

Thanks for the talk link, it completely kept me engrossed and was a pleasure to watch! Addendum question: what is the state of database drivers for Elixir? Does it have mature libraries for Postgres for eg? I imagine if it's targeting web development, it will need those.

Elixir has Ecto, which is not-quite an ORM but is the de-facto standard for database access in Elixir/Phoenix.

https://hexdocs.pm/ecto/Ecto.html

Re: Why Elixir (2014)

#62

Post by sb8244 »

dbbk wrote: post #47

I see so much effusive praise for Elixir that I feel like something must have gone really wrong with our codebase, because build times from scratch are horrible (10 minutes or so), and I frequently have problems with the incremental build when switching between branches which force me to do a clean build. Coming from a Node and PHP background makes me really appreciate the lack of compile step.

How many .ex files in code base?

Re: Why Elixir (2014)

#63

Post by arrowsmith »

conradfr wrote: post #60
arrowsmith wrote: post #44

Earlier quoted context omitted.

> how to reference functions in the same module sometimes requiring to still write the name of the module Not sure what you mean here. If the function is in the same module then you should be able to refer to it without including the module name. Can you give some example code to show what you mean?

Not a function but when a module has a struct that you want to use inside the module you need to use the full module name or alias itself.

You can write __MODULE__ to reference the current module. Or if the current module is a struct you can write %__MODULE__{}

Re: Why Elixir (2014)

#65

Post by conradfr »

arrowsmith wrote: post #63
conradfr wrote: post #60

Earlier quoted context omitted.

Not a function but when a module has a struct that you want to use inside the module you need to use the full module name or alias itself.

You can write __MODULE__ to reference the current module. Or if the current module is a struct you can write %__MODULE__{}

That's not very pretty though ;)

IIRC you can also write:

alias __MODULE__

Re: Why Elixir (2014)

#66

Post by zelphirkalt »

toast0 wrote: post #55
zelphirkalt wrote: post #49

Earlier quoted context omitted.

Recruiting was exactly the one argument that I got to hear. That hiring people would be difficult and people demanding high wages and so on. I could not convince an employer to not weigh that heavily. At least that is the brought forward argument. There might also be an element of "don't know it myself, don't want it in my company".

I worked at WhatsApp, one of the big Erlang users, almost none of our server team knew Erlang before joining, including me. Until we hired someone who actually used it before, I was the most knowledgeable pre-hire, because I remember seeing a post about it when Erlang open sourced it. Yes, we probably could have done some things better if we had a bit more Erlang experience on our team; at least while I was there, no…

That is exactly what I think. If you got decent and educated developers, they should be up to speed fairly quickly. But management layers often have no trust at all, even if it would take maybe merely 2 weeks to be able to do basic implementations in a new language and ecosystem. Basically it means, that we cannot possibly spend 2 weeks becoming better engineers, but we can spend infinite time on wrangling with lesser tools.

I would love the chance to learn more Erlang (looked at the beginning of "Learn you some Erlang for great Good") or Elixir (used in last year's AoC) on a job and get to use OTP, watch it run my function calls on multiple machines and all that. I know a lot about functional programming, as I do it in my free time (big Scheme fan).

As it is currently, I cannot apply my skills at the job. For example when I think that some code should not mutate some state, but rather use pure functions and the tests should be simply function calls and checking the output, then I don't get the time to do that, nor the time to show how this would look like and how it would make things simpler. No one aside me on the job seems to be interested in purely functional data structures/persistent data structures either, which sooner or later are necessary, if one wants to make things purely functional. So basically I am the only person with that knowledge and cannot apply it. It is so dull.

Re: Why Elixir (2014)

#67

Post by mikevin »

zelphirkalt wrote: post #41

I recently used Elixir for Advent of Code 2023. It is elegant in many places, at least from what I have explored during puzzle solving. However, to me it does not reach the elegance of Scheme or Lisp and I switched back to Guile while solving more puzzles. Due to its not as simple syntax, naming choices are more limited than in many Lispy languages. Also the way anonymous functions are written did not appeal to me es…

Do you have a repo for your Guile solutions to AoC? Would love to see it.

Re: Why Elixir (2014)

#68

Post by mikhailfranco »

williamdclt wrote: post #20
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…

First, if you write process-concurrent code in Elixir/Erlang, it will run on all the cores in your machine. It's automatically locally scalable. The number of processes should range from some small multiple of the no. of cores (say, 10x cores), up to 100k - 1m on a big memory multicore machine.

Second, as the other comments say, Elixir/Erlang have very transparent built-in ways to address other nodes, and the programs will scale as expected: more cpus v. network data distribution cost. So good for small tasks that require lots of compute. The native clustering will run to a few dozen nodes over a trusted LAN.

But soon, you will want some layer managing the cluster, try Swarm:

https://github.com/bitwalker/swarm

Re: Why Elixir (2014)

#69

Post by mikhailfranco »

reddit_clone wrote: post #54
jimbokun wrote: post #16

Earlier quoted context omitted.

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

Its somewhat painful to watch modern languages and ecosystem reinvent (mostly in an inferior manner) things that Erlang (and Lisp) had since so long ago. Talk about under-appreciated.

Virding's First Rule of Programming (2008):

  Any sufficiently complicated concurrent program in another language 
  contains an ad hoc informally-specified bug-ridden slow implementation 
  of half of Erlang.
https://rvirding.blogspot.com/2008/01/virdings-first-rule-of...

Re: Why Elixir (2014)

#70

Post by mikhailfranco »

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 and deadlocks are certainly possible in pure Erlang/Elixir - no databases or global state required. There is no magic bullet.

For example, if you use blocking RPCs between two processes, they can deadlock waiting for each other's responses. Try implementing Dining Philosophers, you will learn a lot.

The answer is not to use blocking RPC, but that will challenge your brain topology. It takes some time to be able to lower yourself into the hot bath of full asynchrony, but when you do, it feels very very good.

I characterize it as the co-problem (in the sense of the dual of a problem). Distributing a problem, starting processes and pushing messages is easy. But it may be hard to know when you're finished. Everything is easy, but termination is difficult. It's the Erlang/Elixir Halting Problem.

It is not often mentioned as a strong feature for concurrent programming, but Erlang/Elixir have timeouts built into the language. And when you add OTP supervisor restarts, you can avoid some common programming mistakes through random evasion - don't do this by design, but it does help resilience.

Post reply on HN