6 ms·

The Erlang team is working on a JIT for the language, and the first release should be out soon. That should help with the "faster" part. "Nicer" is rather sub

The Erlang team is working on a JIT for the language, and the first release should be out soon. That should help with the "faster" part. "Nicer" is rather subjective. I happen to enjoy how Erlang looks and works, though it took me a couple of tries before I really liked it. I'm not sure why people don't jump on the idea of a bulletproof VM.

MichaelGG 11y ago
Doesn't seem as concise as an ML is one of my factors in "nice". I guess I don't care about a bulletproof VM because I've not had issues with the JVM, CLR or other systems. And BEAM reeks of instability. Furthermore the resulting apps seem to bear no relation to Erlang's robustness. Look at RabbitMQ. Lots of stability problems... So what's Erlang saving us from?
- tormeh 11y ago
  Your sense of nice conflicts with Erlang's goal of supporting reliable systems. For example, Erlang is not designed using the paradigm du jour. It may seem like Erlang borrows from functional programming, but Erlang's designers invented all that independently because it supported writing reliable systems. Concise and maintainable are antagonistic qualities, and so Erlang's designers sacrificed all the conciseness they could get away with. Erlang is not deisgned to be nice, elegant or have any other property people normally advertise their language as having. Erlang is designed so that programmers at Ericsson could write better code for phone switches, with constant feedback from said programmers. That's Erlang's mission statement, originally. If you want concise actors, Scala with Akka allows you to write pretty unreadable code if you want to.
  - incepted 11y ago
    > Concise and maintainable are antagonistic qualities Uh? How so? That's quite a strange argument to rationalize Erlang's verbosity and boiler plate.
  - SEMW 11y ago
    > Your sense of nice conflicts with Erlang's goal of supporting reliable systems. Obvious counterexample: Elixir. Plenty of modern niceties that Erlang lacks (rubyesque syntactic sugar, scheme-style hygenic macros, the pipe operator, mix, etc), but shares most of Erlang's semantics and ultimately compiles down to the same bytecode, so AFAICS doesn't sacrifice any of the things that make Erlang good for building reliable systems.
    - simoncion 11y ago
      This in no way diminishes the power of your counterexample, but -AIUI- Elixir is implemented as a bunch of macros on top of Erlang.
    - tormeh 11y ago
      Syntax is crucial when developing for reliability. Brainfuck trivially proves this. Both semantics and syntax need to support reliability.
      - simoncion 11y ago
        > Syntax is crucial when developing for reliability. Brainfuck trivially proves this. Both semantics and syntax need to support reliability. This is an almost content-free comment. You could have made your comment substantially better by giving some examples of language syntax that makes it easier to write reliable code than unreliable code. I think that we all agree that Brainfuck and Whitespace are two examples of languages that are very difficult to read. A comment along the lines of "Languages that are difficult to read do not support reliability." is also almost content-free and probably not entirely true. (Some people find C terribly difficult to read -for some reason or other- but very reliable systems have been written in it.[0]) :) [0] Yes, a quint-squillion unreliable and even dangerous systems have also been written in C. This doesn't invalidate my point.
      - SEMW 11y ago
        I'm not sure if you're implying that Elixir's syntax makes it less good at developing for reliability than Erlang. If so, I'd appreciate if you could explain your thinking further -- if the existence of brainfuck proves that Erlang's syntax is better than Elixir's at developing for reliability, I'm afraid the nature of that proof is eluding me.
- vezzy-fnord 11y ago
  Doesn't seem as concise as an ML is one of my factors in "nice". Sorry, but that disqualifies most programming languages out there. It's not as concise as ML, but it's far more so than your average ALGOL dialect. (Also, ML isn't as concise as Scheme.) And BEAM reeks of instability. [citation needed] Furthermore the resulting apps seem to bear no relation to Erlang's robustness. Look at RabbitMQ. Lots of stability problems... So what's Erlang saving us from? A sample size of 1, particularly one that's already known to be an infamous exception (RabbitMQ), isn't helping your case.
  - MichaelGG 11y ago
    Apologies. I was thinking if HIPE, not BEAM. You're right a lot of languages are disqualified. A lot just suck and have strange hacky stuff thrown around helter skelter. Erlang isn't that bad, but it is just questionably verbose and not fast. And apologies, apart from playing a bit with some custom ejabberd code (which was terrible, but it was written by an inexperienced coder so nothing expected), RabbitMQ is the only high profile Erlang thing I've got experience with. I hear couch or something is also written in Erlang, but I've not heard of amazing HA, more than, say, Redis. It's just nothing that Erlang has seems that special, apart from the process controller/network stuff. Which is straightforward to write in another language. The forced serialization, eh, I'd like the option to share memory when needed. Hot code patching? From what I understand, it has very strict compatibility requirements, and under those constraints, you can do it in another language. So apart from OTP, I really don't get the point. Erlang's big thing seems to be something that should be a library, not a language.
    - simoncion 11y ago
      > Apologies. I was thinking if HIPE, not BEAM. Other than the fact that it makes your BEAM files "non-portable" [read: can only be run on the arch that they were compiled on], what's unstable about HiPE in Erlang 16.x or later? > Hot code patching? From what I understand, it has very strict compatibility requirements... Eh? What requirements might those be? I've used hot patching, but not in anger. The only requirement that I see is that callers must called the replaced code by its fully qualified (module:fun()) name in order to get the new code. What am I missing? Riak is another piece of well-regarded code written in Erlang. (If you read Apyhr's writeup about Riak, note that it's from 2013!) > It's just nothing that Erlang has seems that special, apart from the process controller/network stuff. Which is straightforward to write in another language. So, like, where are the libs that do all of this in C++, Python, and/or Java? I'm not snarking here. If there exist bulletproof libs to do 99% of what you get with Erlang, then I really need to know about them.

MichaelGG 11y ago

Doesn't seem as concise as an ML is one of my factors in "nice". I guess I don't care about a bulletproof VM because I've not had issues with the JVM, CLR or other systems. And BEAM reeks of instability. Furthermore the resulting apps seem to bear no relation to Erlang's robustness. Look at RabbitMQ. Lots of stability problems... So what's Erlang saving us from?

tormeh 11y ago
Your sense of nice conflicts with Erlang's goal of supporting reliable systems. For example, Erlang is not designed using the paradigm du jour. It may seem like Erlang borrows from functional programming, but Erlang's designers invented all that independently because it supported writing reliable systems. Concise and maintainable are antagonistic qualities, and so Erlang's designers sacrificed all the conciseness they could get away with. Erlang is not deisgned to be nice, elegant or have any other property people normally advertise their language as having. Erlang is designed so that programmers at Ericsson could write better code for phone switches, with constant feedback from said programmers. That's Erlang's mission statement, originally. If you want concise actors, Scala with Akka allows you to write pretty unreadable code if you want to.
- incepted 11y ago
  > Concise and maintainable are antagonistic qualities Uh? How so? That's quite a strange argument to rationalize Erlang's verbosity and boiler plate.
- SEMW 11y ago
  > Your sense of nice conflicts with Erlang's goal of supporting reliable systems. Obvious counterexample: Elixir. Plenty of modern niceties that Erlang lacks (rubyesque syntactic sugar, scheme-style hygenic macros, the pipe operator, mix, etc), but shares most of Erlang's semantics and ultimately compiles down to the same bytecode, so AFAICS doesn't sacrifice any of the things that make Erlang good for building reliable systems.
  - simoncion 11y ago
    This in no way diminishes the power of your counterexample, but -AIUI- Elixir is implemented as a bunch of macros on top of Erlang.
  - tormeh 11y ago
    Syntax is crucial when developing for reliability. Brainfuck trivially proves this. Both semantics and syntax need to support reliability.
    - simoncion 11y ago
      > Syntax is crucial when developing for reliability. Brainfuck trivially proves this. Both semantics and syntax need to support reliability. This is an almost content-free comment. You could have made your comment substantially better by giving some examples of language syntax that makes it easier to write reliable code than unreliable code. I think that we all agree that Brainfuck and Whitespace are two examples of languages that are very difficult to read. A comment along the lines of "Languages that are difficult to read do not support reliability." is also almost content-free and probably not entirely true. (Some people find C terribly difficult to read -for some reason or other- but very reliable systems have been written in it.[0]) :) [0] Yes, a quint-squillion unreliable and even dangerous systems have also been written in C. This doesn't invalidate my point.
    - SEMW 11y ago
      I'm not sure if you're implying that Elixir's syntax makes it less good at developing for reliability than Erlang. If so, I'd appreciate if you could explain your thinking further -- if the existence of brainfuck proves that Erlang's syntax is better than Elixir's at developing for reliability, I'm afraid the nature of that proof is eluding me.
vezzy-fnord 11y ago
Doesn't seem as concise as an ML is one of my factors in "nice". Sorry, but that disqualifies most programming languages out there. It's not as concise as ML, but it's far more so than your average ALGOL dialect. (Also, ML isn't as concise as Scheme.) And BEAM reeks of instability. [citation needed] Furthermore the resulting apps seem to bear no relation to Erlang's robustness. Look at RabbitMQ. Lots of stability problems... So what's Erlang saving us from? A sample size of 1, particularly one that's already known to be an infamous exception (RabbitMQ), isn't helping your case.
- MichaelGG 11y ago
  Apologies. I was thinking if HIPE, not BEAM. You're right a lot of languages are disqualified. A lot just suck and have strange hacky stuff thrown around helter skelter. Erlang isn't that bad, but it is just questionably verbose and not fast. And apologies, apart from playing a bit with some custom ejabberd code (which was terrible, but it was written by an inexperienced coder so nothing expected), RabbitMQ is the only high profile Erlang thing I've got experience with. I hear couch or something is also written in Erlang, but I've not heard of amazing HA, more than, say, Redis. It's just nothing that Erlang has seems that special, apart from the process controller/network stuff. Which is straightforward to write in another language. The forced serialization, eh, I'd like the option to share memory when needed. Hot code patching? From what I understand, it has very strict compatibility requirements, and under those constraints, you can do it in another language. So apart from OTP, I really don't get the point. Erlang's big thing seems to be something that should be a library, not a language.
  - simoncion 11y ago
    > Apologies. I was thinking if HIPE, not BEAM. Other than the fact that it makes your BEAM files "non-portable" [read: can only be run on the arch that they were compiled on], what's unstable about HiPE in Erlang 16.x or later? > Hot code patching? From what I understand, it has very strict compatibility requirements... Eh? What requirements might those be? I've used hot patching, but not in anger. The only requirement that I see is that callers must called the replaced code by its fully qualified (module:fun()) name in order to get the new code. What am I missing? Riak is another piece of well-regarded code written in Erlang. (If you read Apyhr's writeup about Riak, note that it's from 2013!) > It's just nothing that Erlang has seems that special, apart from the process controller/network stuff. Which is straightforward to write in another language. So, like, where are the libs that do all of this in C++, Python, and/or Java? I'm not snarking here. If there exist bulletproof libs to do 99% of what you get with Erlang, then I really need to know about them.