Live data from Hacker News

Switching to Elixir

leemeichin.com

261–270 of 283 posts

Re: Switching to Elixir

#261
post #246

Earlier quoted context omitted.

Erlang developed the way it did before people started calling it an Actor model. The key characteristic is not a state machine, but that: - first class processes send messages to each other - messages are queued - each process is single execution flow. If you want to reenter code, start another process and send messages to it - process execution can be preempted - values passed in messages are for the most part, immu…

Erlang did appear after the creation of the actor model. The actor model is from 1973 : https://en.m.wikipedia.org/wiki/Actor_model And Erlang is from 1987 : https://fr.m.wikipedia.org/wiki/Erlang_%28langage%29

https://softwareengineering.stackexchange.com/a/277469

Looks like I misread it. While the Actor model was conceived before Erlang, the Erlang actor model was developed in parallel. It isn’t a pure implementation of Actors (everything is an Actor, making it closer fo Smalltalk). Only processes are Actors. It also implies that Akka is not a true Actor model as conceived in the originao ‘73 paper.

This goes into greater detail on the history: https://www.labouseur.com/courses/erlang/history-of-erlang-a...

In any case, there are not many contemporary systems that uses these ideas.

Re: Switching to Elixir

#262
post #158

Earlier quoted context omitted.

It took me months before it sank in that Nodejs async wasn't really async as I knew it from Elixir -- there's an implicit queue, and no true suspension of the execution flow. One justification for this was that it is supposed to make it easier to reason. It made it more difficult for me to reason -- maybe single-threaded async reactor is a poor substitute for immutability. Unhandled promise rejection is an example of…

> One justification for this was that it is supposed to make it easier to reason. It’s a valid justification because it makes it substantially easier to reason compared to mutable multithreaded languages/runtimes such as C(++), Java and C#. Eg a semaphore in JS doesn’t exist. It’s just a boolean. Interlocked Increment doesn’t exist. It’s just someVar++. And so on, it’s very nice. That doesn’t mean that there aren’t o…

You and I may know this, yet I have encountered smart people who defend a local maxima.

Re: Switching to Elixir

#263
post #56

I have been watching Elixir YouTube videos pretty much every day for the last few weeks. I guess there was an Elixir conference recently and after I watched a couple, YouTube has been sending me a consistent stream of Elixir content. I really want to try out this language. I love the idea of Erlang but the few times I've had to deal with it (an ejabberd chat server was one) I found it to be a bit too quirky. Every vi…

> There is a huge risk in niche languages and platforms. Hard to hire for, hard to find libraries for, hard to find blogs/tutorials/etc. There is a real need to push Elixir outside its initial circles and it's being done a bit at the moment (I feel). Both Chris & José are doing a lot of work for exposure outside the initial Elixir circles, and some people in the community are doing the same at their own levels. Hirin…

I believe José deserves a lot of credit. For example, the Elixir Conference looks well-produced. No doubt there is a large team behind that, but it is obvious his influence guides that process. I'm particularly thinking of the LiveNative talk where the founder of the company talks about his own vision for extending LiveView to mobile and desktop. He mentions several times when José has interacted with him to help guide the project to stay inline with Elixir's overall goals. Of course, there is also the hints of frustration of a commercial business having to wait for community consensus. But that kind of direct involvement in the community is extremely encouraging.

You also make a very good point about the risk and reward metric. One of the reasons I have been focusing on Elixir as opposed to other niche languages is the progress the community is making is inspiring. I recall an essay by Paul Graham where he talks about Lisp being a contributor to his success with the startup that made him wealthy. He believed that being faster to market with features due to his platform choice was decisive in that success. In that way, something like Elixir (and really, the BEAM) could be a decisive component to some startups success. Given that they are focusing on important contemporary ideas, that is possible. LiveBook for example and Nx/Axon/etc for ML may actually be a killer feature.

Of course, time will tell. I don't have a crystal ball. But I am very interested in watching it all unfold.

Re: Switching to Elixir

#264
post #76
post #56

I have been watching Elixir YouTube videos pretty much every day for the last few weeks. I guess there was an Elixir conference recently and after I watched a couple, YouTube has been sending me a consistent stream of Elixir content. I really want to try out this language. I love the idea of Erlang but the few times I've had to deal with it (an ejabberd chat server was one) I found it to be a bit too quirky. Every vi…

You are overthinking some of it at least when it comes to concurrency. Look at what a process is and how send works. GenServer is a natural generalization of a pattern you’d write a thousand times. Knowledge of actors is transferable. Go has libraries which implement actor abstractions for example. Process mailboxes are just message queues like Go’s channels are. There are differences with respect to how the interpre…

I have no trouble understanding the concepts, its the nomenclature that is different. It is the same with Haskell or other niche languages - once you are familiar with the terminology then you start to feel comfortable.

However, I just consider some things in the world outside of Elixir/Erlang/BEAM to be a bit more common. For example, using Docker with Kubernetes/ECS/etc as a deployment story. Or connecting micro-services using REST/gRPC/GraphQL. Or using queue systems like SQS or Kafka (to be fair, literally yesterday an ElixirConf talk about using Kafka with Elixir was posted). The advantage of BEAM is that you can avoid that stuff in some cases because it is built in to the platform - but that is a double edged sword since now you aren't doing those things.

Even if I have used Akka for Actors in Scala/Java/Kotlin, something about the BEAM based languages still feels like I am stepping onto the Galapagos Islands and seeing a ecosystem that has been evolving in its own isolation for decades. Sure, there are birds, but they just don't look like any birds I've seen before.

Re: Switching to Elixir

#265
post #56

I have been watching Elixir YouTube videos pretty much every day for the last few weeks. I guess there was an Elixir conference recently and after I watched a couple, YouTube has been sending me a consistent stream of Elixir content. I really want to try out this language. I love the idea of Erlang but the few times I've had to deal with it (an ejabberd chat server was one) I found it to be a bit too quirky. Every vi…

The basic idea that infuses all of Armstrong's writings and work is reliability , not concurrency, that's just a means to an end to achieve higher reliability (and lower latency, which in the context of (soft) real time can be a failure condition if certain guarantees are not met.

I think you are right and wrong. I've watched 3 or 4 videos of Joe Armstrong on YouTube this week (he seemed to show up a lot at Strange Loop). He talks a lot about concurrency for its own sake. However, you are right that he also heavily emphasizes reliability and how concurrency contributes to that.

More interesting to me is his physical theories about computation. For example, he hints often at his idea of the blackhole as the most powerful computer. As we think about the distribution of computational systems, I wonder how often we consider the density of computational systems.

Re: Switching to Elixir

#266
post #56

I have been watching Elixir YouTube videos pretty much every day for the last few weeks. I guess there was an Elixir conference recently and after I watched a couple, YouTube has been sending me a consistent stream of Elixir content. I really want to try out this language. I love the idea of Erlang but the few times I've had to deal with it (an ejabberd chat server was one) I found it to be a bit too quirky. Every vi…

the big risk with elixir imo is that it's runtime/vm is still owned by ericsson and there's no alternative. i know things like firefly exist but they aren't mature replacements (to my knowledge)

I thought Open Source Erlang is Apache 2.0 based on the first paragraph on the Erlang faq page [1]: "You can use Open Source Erlang to build commercial products without having to pay royalties or licence fees to Ericsson. Open Source Erlang uses the Apache License 2.0."

I think it is a bit confusing actually, since they differentiate between Erlang (the language), ERTS (Erlang Runtime System) and the BEAM. It isn't clear to me what "Open Source Erlang" refers to with respect to those distinctions, or what the licenses are for each of them.

1. https://www.erlang.org/faq/implementations

Re: Switching to Elixir

#267

Earlier quoted context omitted.

I actually find the opposite to be true. Elixir is less "magic" once you learn it. I can see and understand what most things are doing and read the code. With javascript? Not so much. On the point of hard to hire and hard to find tutorials. It is true. It is way harder to find for example someone that done what you wanna do in elixir vs javascript. When it comes to libaries it isnt so big problem. There are lots of l…

Elixir is actually the easiest language to read (for me), once I knew it. You can make it difficult to follow if you want to, but when people are using it to pass around plain old data structures, it's very legible. Speaking only for myself. YMMV.

(author here) - I've also found this to be true. The most confounding aspects of elixir tend to be choices made to fit a square object into a round hole. For example, creating interfaces over functions so Hammox can mock them in your tests. It creates a lot of frustrating boilerplate and suddenly your actual code gets lost in the noise of indirection.

Re: Switching to Elixir

#268

> In Ruby it's common to use exceptions for control flow. I think this is just plain incorrect. The example given later in this paragraph is the Rails `update` method--but the approach used in all canonical Rails examples and generators is the non-exception version of `update`.

The examples show you a simple way to do things that limit complexity, especially for learners. Any decently sized library or application switches to descriptive error classes once they become sufficiently complex, because stateful error handling (as ActiveRecord does it) is painful.

I'd argue that now Ruby has some kind of pattern matching, it can take the place of using exceptions for control flow. You can just return the class itself instead of raising it, then match on it.

Re: Switching to Elixir

#269

I often see people say static typing slows them down and I'd really like to know why that is because for me it's the exact opposite, I really don't like not knowing what format data is in. I'd much rather have to write slightly more verbose code and have a vast number of possible errors caught at compile time instead of having things go wrong in production when someone inputs something a bit weird with nothing so muc…

Yeah but it doesn’t matter - if someone inputs something weird you will anyhow fail with TypeError

Re: Switching to Elixir

#270
post #46

Write after you’ve been there for 2 years, instead of at the start. That new thing always looks like a flawless shiny new silver bullet when starting out.

I'm the author and well accustomed to the concept of the honeymoon period. First impressions have their place and that's what I'm offering, because I'm talking to expert Rubyists, not expert Elixir/Erlang devs.
Post reply on HN