7 ms·

"Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang."

by Jedi72 8y ago

"Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang." - Virding's Law

Ruddle 8y ago
IMO any program with a sufficiently high number of entities in a low level language contains an ad hoc informally-specified bug-ridden slow implementation of a garbage collector
- omeid2 8y ago
  Not exactly, a garbage collector is by definition a collector (there is sweeps rather than per-reference and more importantly has runtime cost). I think, manual memory management is a lot more similar to a poorman's ARC implementation.
  - pjmlp 8y ago
    A poorman's ARC implementation might not collect cycles, but it does not do double free() or use-after-free().
cdoxsey 8y ago
Are you talking about Go, the language this is written in? Go's concurrency features are formally specified, are not ad-hoc (they are a major feature of the language, and the product of multiple language design iterations) and are certainly not bug-ridden. Or are you talking about using Kubernetes to manage workloads on machines? How does Erlang solve running my python webapp or my SQL database on my ec2 nodes, or in the case of this project, on an IoT device.
- Jedi72 8y ago
  I am not talking about Go. I dont care what your language is, the true underlying reasoning for your engineering choices is independent of language. It just so happens that these problems have been around for ~30 years, and there has been significant progress in developing tooling to face them, in the domains that the BEAM languages sphere of influence. Just like how Ecto, despite being a great tool, does not free us of knowing about Relational Databases. If you approach the tooling infependently though, as a true knowledge expert does, you will see the progress made by other giants in these fields who are not afraid of specialised tools.
  - weberc2 8y ago
    Not sure what point you’re making specifically. Could you elaborate?
  - geofft 8y ago
    What are "these problems"?
  - johnmarcus 8y ago
    When I came across Erlang last year at a new company, I thought it was interesting how many problems Erlang solved that were also in Kubernetes. Self registering named services, processes that crash and restart automatically, health checks, etc. Unfortunately to use all those features the services needed to be written in Erlang of course, which isn't bad in itself, but unfortunately not the reality in todays multi-lingual atmosphere. Speaks to how highly Erlang was designed and written. It took a lot of real life operational concerns into account in it's design, a concept few other languages even attempt to address.
    - jimmy1 8y ago
      "Who cares that these problems are solved in Erlang/BEAM if hardly anyone is writing end user software in Erlang/BEAM/Elixir", basically. My number one reason for not using Erlang is lack of static typing. Dynamic type systems are great for small teams, not so great for "enterprise-wide" development. (I know this horse has been beaten to death here, trust me, I have heard the arguments for/against millions of times, I remain unconvinced). Also the answer to this question is interesting to me as well http://erlang.org/pipermail/erlang-questions/2008-October/039261.html http://erlang.org/pipermail/erlang-questions/2008-October/03... -- (granted this is from Oct 2008) apparently if you were to attempt to add static type checking in Erlang, it would have to fundamentally change some of these benefits erlang brings such as message passing and handling process death. Haven't been part of the erlang scene for a while, but would be interested to hear a rebuttal to that.
  - cdoxsey 8y ago
    I'm not afraid of specialized tools. For example I've used RabbitMQ which I believe is written in Erlang. We run it in Kubernetes in both our CI environment and locally so we can use the same configuration for both. It runs a dozen microservices and saves us a lot of devops time. In our CI environment it's nice for a developer to roll out a new copy of the services from a different branch for testing, and because of the autoscaler nodes are dynamically provisioned when needed, and then removed when the test environment is destroyed. That's pretty nice functionality you get basically out of the box. On EKS anyway. There are some occasional rough edges, but I think the decision to use k8s for this makes sense... At some point we'll migrate prod too. Kubernetes has a lineage as well... Based on the Borg project at Google. I guess I'm not seeing why these things are being compared. Aren't they solving different problems?
tlynchpin 8y ago
Erlang is a terrific platform, but it isn't very accessible to the wider population. Timely, here's antirez on this topic when Redis was announced on HN ten years ago [0]: > There are a lot of projects similar to Redis in Erlang actually: http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores/ http://www.metabrew.com/article/anti-rdbms-a-list-of-distrib... > Apart from speed what I like of C for this kind of projects is the self-contain-ness and the fact that most developers that may help in the development are probably able to read/write C but not Erlang. [0] https://news.ycombinator.com/item?id=494903 https://news.ycombinator.com/item?id=494903

by Jedi72 8y ago

"Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang." - Virding's Law

Ruddle 8y ago

IMO any program with a sufficiently high number of entities in a low level language contains an ad hoc informally-specified bug-ridden slow implementation of a garbage collector

omeid2 8y ago
Not exactly, a garbage collector is by definition a collector (there is sweeps rather than per-reference and more importantly has runtime cost). I think, manual memory management is a lot more similar to a poorman's ARC implementation.
- pjmlp 8y ago
  A poorman's ARC implementation might not collect cycles, but it does not do double free() or use-after-free().

cdoxsey 8y ago

Are you talking about Go, the language this is written in? Go's concurrency features are formally specified, are not ad-hoc (they are a major feature of the language, and the product of multiple language design iterations) and are certainly not bug-ridden. Or are you talking about using Kubernetes to manage workloads on machines? How does Erlang solve running my python webapp or my SQL database on my ec2 nodes, or in the case of this project, on an IoT device.

Jedi72 8y ago
I am not talking about Go. I dont care what your language is, the true underlying reasoning for your engineering choices is independent of language. It just so happens that these problems have been around for ~30 years, and there has been significant progress in developing tooling to face them, in the domains that the BEAM languages sphere of influence. Just like how Ecto, despite being a great tool, does not free us of knowing about Relational Databases. If you approach the tooling infependently though, as a true knowledge expert does, you will see the progress made by other giants in these fields who are not afraid of specialised tools.
- weberc2 8y ago
  Not sure what point you’re making specifically. Could you elaborate?
- geofft 8y ago
  What are "these problems"?
- johnmarcus 8y ago
  When I came across Erlang last year at a new company, I thought it was interesting how many problems Erlang solved that were also in Kubernetes. Self registering named services, processes that crash and restart automatically, health checks, etc. Unfortunately to use all those features the services needed to be written in Erlang of course, which isn't bad in itself, but unfortunately not the reality in todays multi-lingual atmosphere. Speaks to how highly Erlang was designed and written. It took a lot of real life operational concerns into account in it's design, a concept few other languages even attempt to address.
  - jimmy1 8y ago
    "Who cares that these problems are solved in Erlang/BEAM if hardly anyone is writing end user software in Erlang/BEAM/Elixir", basically. My number one reason for not using Erlang is lack of static typing. Dynamic type systems are great for small teams, not so great for "enterprise-wide" development. (I know this horse has been beaten to death here, trust me, I have heard the arguments for/against millions of times, I remain unconvinced). Also the answer to this question is interesting to me as well http://erlang.org/pipermail/erlang-questions/2008-October/039261.html http://erlang.org/pipermail/erlang-questions/2008-October/03... -- (granted this is from Oct 2008) apparently if you were to attempt to add static type checking in Erlang, it would have to fundamentally change some of these benefits erlang brings such as message passing and handling process death. Haven't been part of the erlang scene for a while, but would be interested to hear a rebuttal to that.
- cdoxsey 8y ago
  I'm not afraid of specialized tools. For example I've used RabbitMQ which I believe is written in Erlang. We run it in Kubernetes in both our CI environment and locally so we can use the same configuration for both. It runs a dozen microservices and saves us a lot of devops time. In our CI environment it's nice for a developer to roll out a new copy of the services from a different branch for testing, and because of the autoscaler nodes are dynamically provisioned when needed, and then removed when the test environment is destroyed. That's pretty nice functionality you get basically out of the box. On EKS anyway. There are some occasional rough edges, but I think the decision to use k8s for this makes sense... At some point we'll migrate prod too. Kubernetes has a lineage as well... Based on the Borg project at Google. I guess I'm not seeing why these things are being compared. Aren't they solving different problems?

tlynchpin 8y ago

Erlang is a terrific platform, but it isn't very accessible to the wider population. Timely, here's antirez on this topic when Redis was announced on HN ten years ago [0]: > There are a lot of projects similar to Redis in Erlang actually: http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores/ http://www.metabrew.com/article/anti-rdbms-a-list-of-distrib... > Apart from speed what I like of C for this kind of projects is the self-contain-ness and the fact that most developers that may help in the development are probably able to read/write C but not Erlang. [0] https://news.ycombinator.com/item?id=494903 https://news.ycombinator.com/item?id=494903