I was probably overstating things, and certainly overstating my knowledge of them. I was focusing entirely on message-passing concurrency, like in Erlang. 'Crappy' was a reference not to a specific runtime but to the threads model in general and how errorprone it is.
What do you think of SBCL? I get the sense it is faster. Is that not true?
re message-passing concurrency in PLT, PLT has both message-passing (either synchronous channels or asynchronous buffered channels, your choice) and concurrency built in as a standard part of the language. Second, even if PLT didn't have that, you can easily implement "message-passing concurrency" on top of a threads model.
As for SBCL, I haven't seen a comparison, so I don't know. Common Lisp doesn't have call-with-current-continuation so Arc's ccc wouldn't be fully supported, but I don't know if anyone's Arc programs use full continuations so it may not matter.
I was wondering about runtime quality without reference to arc or specific features.
From what people say Erlang has a really high-performance fine-grained message-passing implementation. PLT has the primitives, but not nearly the same runtime quality. Is that mistaken?
Which means what exactly? Slow? Crashes a lot? Doesn't sparkle?
Do you have a single shred of evidence for these claims, whatever they are? Do those "people"? Or is this just all blabble?
If you actually want to know if Erlang has a faster message-passing implementation than PLT you don't need to compare what I say with what "people" say. Write a program in Erlang and PLT and see which one is faster.
Ok. You seem to be saying PLT is the best thing for everyone, and that nobody should use anything else. I'll just assume something's being lost in translation, and shut up. It's not a very productive topic anyway.
You don't just ask, you ask using words like "babble" and "shred of evidence". Is that necessary? It sounds defensive of PLT. But perhaps you think my argument is poor. So let me try to clarify.
You seem to be saying reputations are irrelevant. They're a shortcut. They're for when the program I'd have to write to test some property would require a week to months of work. If you want to ignore reputations, be my guest. But reputation is how you found out about PLT in the first place. You didn't run some idealized experiment comparing every single platform in existence for precisely the nuanced characteristics of the program you were planning to write.
I hear lots of people online touting Erlang as high performance at hundreds of cores, and highly fault tolerant. Have you not heard this? Do I need to cite chapter and verse for things I assume people are aware of? I don't hear anybody saying similar things for PLT. Am I just not listening in the right places? Feel free to cite evidence yourself.
I use PLT and arc because of programming convenience. I don't spend much time thinking about how good the runtime quality is because it's frankly not that important to me. It doesn't give me much confidence when I see 12 segfaults a day on my readwarp server[1]. So yes, it does 'crash a lot'[2]. In this very thread you're switching away from using immutable cons pairs because they seem to be not working as advertised. Is that not 'evidence'?
You've said things like "if there's anything better than PLT.." so it sounds like you're thinking in terms of an absolute ordering that you can stack language/platform combinations on. Surely the ordering is in the context of your use case. Or would you write the linux kernel in PLT scheme? Based on what you know now? How would you scale news.arc to two servers? I don't care that PLT 'has message passing'; if I wrote something that required lots of machines I know I would switch to Erlang or C, and put up with crappy syntax. You can't have the best programming environment and the best runtime - because no single community focuses equally on both.
I was careless in my phrasing of 'some people'. Sorry. I didn't expect to get pounced on, and I didn't mean for the conversation to get yet more noisy. It takes two to do that.
