3 ms·

besides it being functional and process orientated, theres lots about erlang syntax, that is just cumbersome, unwieldy and unnecessary, the interested reader is

besides it being functional and process orientated, theres lots about erlang syntax, that is just cumbersome, unwieldy and unnecessary, the interested reader is refferred to http://damienkatz.net/2008/03/what_sucks_abou.html http://damienkatz.net/2008/03/what_sucks_abou.html. To claim that stability is a facet of the syntax , is questionable given as it would imply that languages like reia http://reia-lang.org/ http://reia-lang.org/ are less stable, which i would very much doubt. Also in terms of stability ive yet to hear of a jvm based project with 99.999% uptime. You seem to suggest that this is because all of the java programs out there are not written to the same standard, this clearly cant be true. Finally, I wait anxiously for the day that a single jvm can handle as many concurrent processes as a single erlang execution environment. This is all my opinion, but what you say doesnt really make sense to me.

mononcqc 16y ago
I try to tackle some of these points in An Open Letter to the Erlang Beginner (or Onlooker) (http://ferd.ca/an-open-letter-to-the-erlang-beginner-or-onlooker.html http://ferd.ca/an-open-letter-to-the-erlang-beginner-or-onlo...). As for the nine nines (99.9999999%) in the Ericsson AXD 301 ATM switches, Please note that this is not an indication that none of the components in an Erlang-based system failed, but that a general switch system was available 99.9999999% of the time, planned outages included. This is partially because Erlang is built on the notion that a failure in one of the components should not affect the whole system.
runT1ME 16y ago
>Also in terms of stability ive yet to hear of a jvm based project with 99.999% uptime. Azul systems has said that for many clients, they've achieved perfect reliability in terms of uptime, and that the only reason they don't have five nines uptime is because deployments happen often enough that it doesn't count as uninterrupted uptime. > Finally, I wait anxiously for the day that a single jvm can handle as many concurrent processes as a single erlang execution environment. It sounds like you are talking nonsense. Do you understand that a 'single jvm' is one process, so to say that a single jvm can handle as many concurrent processes is meaningless. Do you mean threads? I'm quite certain the JVM's thread scalability is much higher than erlang's vm. Are you familiar with the architecture of either?
- drstrangevibes 16y ago
  yes I meant processes as in the generic term you might say executions as erlang process are different to Java threads. I meant a comparison of concurrent 'activities' as comparing a Java thread model to an erlang process model is somewhat pointless. I am interested in any Java program you might have that can run thousands of threads without grinding to a halt. please show me I didn't think it possible!
  - runT1ME 16y ago
    I'm doing simultaneousness processing of 700-800 transactions on my dual core laptop on the JVM. I think on a production grade server a thousand or so is not going to be an issue. Your Garbage Collector and program's contention is going to a bigger scaling bottleneck than the JVM itself.

mononcqc 16y ago

I try to tackle some of these points in An Open Letter to the Erlang Beginner (or Onlooker) (http://ferd.ca/an-open-letter-to-the-erlang-beginner-or-onlooker.html http://ferd.ca/an-open-letter-to-the-erlang-beginner-or-onlo...). As for the nine nines (99.9999999%) in the Ericsson AXD 301 ATM switches, Please note that this is not an indication that none of the components in an Erlang-based system failed, but that a general switch system was available 99.9999999% of the time, planned outages included. This is partially because Erlang is built on the notion that a failure in one of the components should not affect the whole system.

runT1ME 16y ago

>Also in terms of stability ive yet to hear of a jvm based project with 99.999% uptime. Azul systems has said that for many clients, they've achieved perfect reliability in terms of uptime, and that the only reason they don't have five nines uptime is because deployments happen often enough that it doesn't count as uninterrupted uptime. > Finally, I wait anxiously for the day that a single jvm can handle as many concurrent processes as a single erlang execution environment. It sounds like you are talking nonsense. Do you understand that a 'single jvm' is one process, so to say that a single jvm can handle as many concurrent processes is meaningless. Do you mean threads? I'm quite certain the JVM's thread scalability is much higher than erlang's vm. Are you familiar with the architecture of either?

drstrangevibes 16y ago
yes I meant processes as in the generic term you might say executions as erlang process are different to Java threads. I meant a comparison of concurrent 'activities' as comparing a Java thread model to an erlang process model is somewhat pointless. I am interested in any Java program you might have that can run thousands of threads without grinding to a halt. please show me I didn't think it possible!
- runT1ME 16y ago
  I'm doing simultaneousness processing of 700-800 transactions on my dual core laptop on the JVM. I think on a production grade server a thousand or so is not going to be an issue. Your Garbage Collector and program's contention is going to a bigger scaling bottleneck than the JVM itself.