Maintaining backwards compatibility isn't one of the things I need or am looking for in a production language. If it's something you need for your production system, that's a valid requirement that would cause you not to choose Arc. But don't conflate your personal requirements with what's needed for a production system in general.
To the question "do we have a decent and reliable implementation of Arc for production systems" the answer is yes. People use Arc today for production systems.
Is Arc something that you would want to use for your project? I have no idea. I don't know what your skills are or what your requirements are.
I can offer some general guidelines. Arc is a language for hackers. If you're not not a hacker, then Arc is probably not going to be a language for you.
Arc is a language for exploratory programming. If your project is a straightforward engineering effort with a known solution, then while Arc might not be worse than some other platform it probably isn't going to be better.
Arc is a language designed to maximize the individual productivity of a programmer. It is not designed for programming teams working in a bureaucracy. If your project is large enough that you need a team of programmers to work on it, then Arc is probably not going to be a good choice for you.
And then there are particular features that you may need for a particular project. An easy question to answer is "I need X, Y, and Z, does Arc have that?". Then we could answer:
- "why yes, Arc has X, Y, and Z", or
- "why no, Arc doesn't have Y", or
- "no, Arc doesn't have Y but I think it probably will sometime in the future", or
- "no, Arc doesn't have Y and my best guess is that it probably won't".
"To the question "do we have a decent and reliable implementation of Arc for production systems" the answer is yes."
But arc doesn't get regular bugfixes. The queue bug causes it to segfault, and it was fixed over months without any official support, and it still hasn't been integrated into arc 3.1.
When an outsider asks, "is arc reliable?" he's partly asking, "will discovered bugs get fixed in a timely manner?" I don't want to over-sell arc to outsiders, so my answer is "No."
One of us can maintain a more regularly-fixed variant, but there's several of those and the community hasn't converged on one of them.
At this point we're arguing semantics, which is a futile exercise. So yes, we should just say x, y and z rather than fluffy words like 'production'.
In my experience people who use the words 'production use' are often talking in the context of a system that runs all the time, and that has a team of programmers working on it. In this context there can be lots of x's, y's, and z's that go into 'production', but it always includes "should I be afraid of upgrades?" (roti can confirm or deny in this case.) There's a reason perl and python and common lisp and racket have gone through contortions to indefinitely support bad ideas.
I'm not saying this is a good thing, btw. I think this whole model is wrong. But I'm just one guy shouting at the cosmos, and I certainly haven't seen more than the tiniest sliver of what people do with software.
