I see what you mean. I entirely agree with you. Basically, I would not want too to advocate for a switch if it was for minor reasons (even for most medium ones) that can be fixed or with which one can live. That happens a lot with software, you have to live with some shit and that's ok.
I think my point goes beyond however.
For understanding why, let's discuss one aspect of software. There is something cool about software that actually many organisation miss I think. Software is pretty predictable. Just use your stats. So, if your development team was going at that velocity this month on that system, chances are they are going to move forward with the same velocity or so the next month. If you've had 15 new bugs this week on your system, chances are you gonna have at least 10 new bugs next week. If you had important successes with your system, chances are you gonna continue to be successful with your system again.
In other words, if your team is slow this month, they won't be fast next month. Nah, they wont. If you had bugs last week but think you've made big fixes, well you gonna be disappointed this week when you will understand that you've not fixed the mother of all bugs because there is no such thing. Your codebase has that property, it has that bug stats. It can go down, but using a continuous and low varying function.
If you adopt Arc and got 5 technical problems in 2 weeks all more or less related to Racket [0], chances are, that's my point, that you gonna have technical problems all along.
So what I'm trying to do here by my call is not to fix a couple of issues. What I'm trying to do is to change the stats themselves. Arc must be smooth. If it's not smooth, hackers wont use it. Right now, Arc is unusable because, as you use it, you understand that statistically, Racket gonna pose problems. So you quit.
Note that I'm not advocating fragmentation. I'm advocating to, if reviews and discussions tell it's right, deprecate the Racket version for a CL one.
I've very quickly tried the Clamp implementation yesterday, and already, I've felt the difference. The ffi, check. As fast as C, check. Threads, check. Not repl problem in sublime, check. Easy import from CL, check. Executable, check (I've made one with clamp, it just worked). (Chances are, Im gonna continue to check at this rate.)
I think that makes my point more clear. Before any consideration, we must have a real good implementation hackers would use, as a foundation on which to build on. I can be wrong though. I may be making a judgement mistake of course.
[0] I've also had problems importing my symbols coming from a ffi to arc. Such a pain. It's already working with clamp though...
> If you adopt Arc and got 5 technical problems in 2 weeks all more or less related to Racket [0], chances are, that's my point, that you gonna have technical problems all along.
> Right now, Arc is unusable because, as you use it, you understand that statistically, Racket gonna pose problems. So you quit.
I've had the complete opposite experience -- none of my problems with Arc are Racket-related. The things you have listed seem to fall into two categories: you prefer Common Lisp, or things that have been done in Clamp.
I think I'd be happier about switching implementations if we could update the site that most people using the language use to communicate on! The instructions still say to get a specific old version of mzscheme!
The only caveat I want to inject is to not blame Racket too strongly. Clamp showed me that I don't know enough CL to make a good Arc in it. By the same token, Pauan's https://github.com/arclanguage/arc-nu showed me how much better Arc-on-Racket can be. Racket is pretty mature, but the default Arc implementation hasn't moved much from the days of mzscheme.
Sure, obviously Racket is a great language, specially for teaching. Though, I don't find it is in the same greatness category as C and python (and some others like Ruby, Rust and Go). Those are the hacker languages. I would like to see a lisp actually in this category.
