4 ms·

Virding's First Rule of Programming (2008)

58 points by yamrzou 4y ago

thyrsus 4y ago
It's been a few years; has anyone had a contrary experience? E.g., a system with parallelism/concurrency that was reliable and faster than one built in Erlang?
- macintux 4y ago
  I don’t, but I will point out that finding a system that performs in parallel faster than Erlang wouldn’t be difficult. The BEAM is getting better/faster over the years, but it’ll never be as fast as the JVM, much less something closer to the metal.
- aussiesnack 4y ago
  I don't have empirical evidence (nor experience) to hand, but I doubt there's any shortage of individual systems that do some sort of parallel/concurrent work faster than Erlang systems, built on lower-level concurrency primitives offered on the JVM, in golang, Rust etc. More narrowly though, there is a candidate for a means of building systems from higher level, BEAM-like primitives with potential for greater performance than Erlang/Elixir - Lunatic (https://lunatic.solutions/ https://lunatic.solutions/). It is admittedly a kind of reimplementation of the BEAM, which maybe makes Virding's point. But it's not ad hoc.
- narag 4y ago
  I've seen two systems that deal with a huge volume of data where parallelism, speed and throughput were critical. One was a mobile network operator call billing system, the other one a stock exchange. First one was written in C, the second one I'm not certain, but my understanding is that it was C too.
- valenterry 4y ago
  I think you should differentiate between Erlang and BEAM. I've not used both except for toying, but while the BEAM looks really really cool, Erlang does not. I use Scala and I'm pretty darn sure that it is way above Erlang in almost any regard, especially for concurrency and parallelism. However, to get what BEAM offers on the JVM you have to go with Akka (which I used a lot) and I think Akka falls short of BEAM in some regards, especially debugging.
wruza 4y ago
I’ll say it out loud. Erlang is cool, but so are loops, types, a whole bunch of common punctuation, idioms, packages and so on. Esoteric languages may have core killer features, but otherwise are weak and pointless in a sense of general-purpose business programming. Even LISP is less odd than Erlang. What’s with [,.], =<, #[], symbol/n, -etc? As if they wanted to win an obfuscation contest and succeeded. For some reason, great tech often comes with “strings attached”. Relational engines - SQL only, no direct api. Concurrency - Erlang. Symbolic computing - Haskell. Embedding a dynamic runtime - Lua. Controlling desktop - AHK, AppleScript. Why can’t we have these things in mainstream, “day job”-grade languages with a human face.
- macintux 4y ago
  Erlang was created in the 80s as a layer atop Prolog. Not surprising that it doesn't look like C or Python. (You can always use Elixir if you want something more modern-looking, or lfe if you prefer Lisp. Personally I like Erlang's syntax because it's concise and helps me think in Erlang, vs Python or Ruby.) I'm a big fan of languages that pick an area of expertise. Perl for text processing. Erlang for robust, concurrent operations. Fortran for numerical processing. Kitchen sink languages (yes, I'm looking at you, C++) try to meet every need and don't do anything as well as a specialized language can. Erlang does its job so very well because it makes tradeoffs that other languages can't. Arbitrary integer sizes, for example. Asynchronous message passing with mailboxes. Immutable data. Those are unacceptable for a language that's trying to break speed records.
- User23 4y ago
  Lisp isn’t odd at all. It’s just a locally optimal direct representation of an abstract syntax tree (AST). Above all else, that’s the defining characteristic of Lisp. The programmer is necessary manipulating an AST when writing in any language, Lisp just makes it clear.
- toast0 4y ago
  If you live in Erlang for a while, you'll come to terms with recursion for loops. It's kind of weird to start with, but you get used to it. Kind of the same thing with the rest of the syntax issues. Of course, I wanted Erlang with nicer syntax, but then they gave me Elixir, which is worse (IMHO), so be careful what you ask for. Immutable data is a key simplifying assumption of the VM though, and you can't write traditional loops without mutating some data, so there you go. Yes, sometimes the VM cheats a bit and mutates some data here and there, especially if you do stuff with the process dictionary, but you can't make self-referential data structures, which keeps GC simple.

58 points by yamrzou 4y ago

It's been a few years; has anyone had a contrary experience? E.g., a system with parallelism/concurrency that was reliable and faster than one built in Erlang?

macintux 4y ago
I don’t, but I will point out that finding a system that performs in parallel faster than Erlang wouldn’t be difficult. The BEAM is getting better/faster over the years, but it’ll never be as fast as the JVM, much less something closer to the metal.
aussiesnack 4y ago
I don't have empirical evidence (nor experience) to hand, but I doubt there's any shortage of individual systems that do some sort of parallel/concurrent work faster than Erlang systems, built on lower-level concurrency primitives offered on the JVM, in golang, Rust etc. More narrowly though, there is a candidate for a means of building systems from higher level, BEAM-like primitives with potential for greater performance than Erlang/Elixir - Lunatic (https://lunatic.solutions/ https://lunatic.solutions/). It is admittedly a kind of reimplementation of the BEAM, which maybe makes Virding's point. But it's not ad hoc.
narag 4y ago
I've seen two systems that deal with a huge volume of data where parallelism, speed and throughput were critical. One was a mobile network operator call billing system, the other one a stock exchange. First one was written in C, the second one I'm not certain, but my understanding is that it was C too.
valenterry 4y ago
I think you should differentiate between Erlang and BEAM. I've not used both except for toying, but while the BEAM looks really really cool, Erlang does not. I use Scala and I'm pretty darn sure that it is way above Erlang in almost any regard, especially for concurrency and parallelism. However, to get what BEAM offers on the JVM you have to go with Akka (which I used a lot) and I think Akka falls short of BEAM in some regards, especially debugging.

wruza 4y ago

I’ll say it out loud. Erlang is cool, but so are loops, types, a whole bunch of common punctuation, idioms, packages and so on. Esoteric languages may have core killer features, but otherwise are weak and pointless in a sense of general-purpose business programming. Even LISP is less odd than Erlang. What’s with [,.], =<, #[], symbol/n, -etc? As if they wanted to win an obfuscation contest and succeeded. For some reason, great tech often comes with “strings attached”. Relational engines - SQL only, no direct api. Concurrency - Erlang. Symbolic computing - Haskell. Embedding a dynamic runtime - Lua. Controlling desktop - AHK, AppleScript. Why can’t we have these things in mainstream, “day job”-grade languages with a human face.

macintux 4y ago
Erlang was created in the 80s as a layer atop Prolog. Not surprising that it doesn't look like C or Python. (You can always use Elixir if you want something more modern-looking, or lfe if you prefer Lisp. Personally I like Erlang's syntax because it's concise and helps me think in Erlang, vs Python or Ruby.) I'm a big fan of languages that pick an area of expertise. Perl for text processing. Erlang for robust, concurrent operations. Fortran for numerical processing. Kitchen sink languages (yes, I'm looking at you, C++) try to meet every need and don't do anything as well as a specialized language can. Erlang does its job so very well because it makes tradeoffs that other languages can't. Arbitrary integer sizes, for example. Asynchronous message passing with mailboxes. Immutable data. Those are unacceptable for a language that's trying to break speed records.
User23 4y ago
Lisp isn’t odd at all. It’s just a locally optimal direct representation of an abstract syntax tree (AST). Above all else, that’s the defining characteristic of Lisp. The programmer is necessary manipulating an AST when writing in any language, Lisp just makes it clear.
toast0 4y ago
If you live in Erlang for a while, you'll come to terms with recursion for loops. It's kind of weird to start with, but you get used to it. Kind of the same thing with the rest of the syntax issues. Of course, I wanted Erlang with nicer syntax, but then they gave me Elixir, which is worse (IMHO), so be careful what you ask for. Immutable data is a key simplifying assumption of the VM though, and you can't write traditional loops without mutating some data, so there you go. Yes, sometimes the VM cheats a bit and mutates some data here and there, especially if you do stuff with the process dictionary, but you can't make self-referential data structures, which keeps GC simple.