Thanks for posting this! Arc is really a great language - I use it every day to power my Chinese e-commerce site (there were a bunch of totally bogus complaints a while back about Arc's lack of utf8 support). Libraries are no longer really a big problem: with aw's additions in Anarki, it's really easy to call Perl and Python libraries, in addition to all of those from Racket. And Anarki has a healthily growing set of indigenous libraries as well.
The biggest problem the language has is lack of marketing (something I think we in the Arc community should take PG to task for).
there were a bunch of totally bogus complaints a while back about Arc's lack of utf8 support
Those claims were not bogus at the time. When arc was released Paul Graham explicitly stated that unicode support was not there and was low on the priority list.
Nope, they were bogus then too. I was hacking a Chinese website at the time. Basically what happened is PG didn't use utf8 and didn't check to see if it worked, but it did anyway. From the very beginning,
(def 什么 () 1)
(什么) => 1
worked. Python, for example, can't even do that. As is often the case, the people complaining didn't even bother to try it out to see what they were actually complaining about.
There were a few tiny places that needed improving (I know, because I wrote most of the utf8 improvements in Anarki), and they almost all revolved around parsing / producing web-related utf8 stuff.
Python 3.1.1 (r311:74543, Aug 24 2009, 18:44:04)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> def 什么():
... return 1
...
>>> 什么()
1
Interesting, I thought pg had said the unicode support came after the underlying scheme system started supporting it, which came later. I guess I'm mistaken about that.
I apologize for the downtime to anyone who has had problems accessing the site. Temporary outages have come along with my modest traffic spike. I hope you'll try back in a few minutes.
I evaluated it a few weeks back while porting a Common Lisp system to Android, and if you ask me, Arc is better suited as a resident language for a handheld device than most other languages.
Paul's insistence on brief symbol names, and heavily simplified Lisp syntax didn't make a lot of sense 8 years ago. But today, it's just what the doctor ordered for mobile.
If you got that error at the REPL after being on the site for a few minutes, your sandbox probably got garbage collected due to high traffic. Please see http://news.ycombinator.com/item?id=1814494
If you got it when you first arrived or in some other context, you're bug reporting. Tell me more!
In either case, if you (wait a few minutes and) reload the page, it will probably work. Thanks for your patience.
Providing independent sandboxed evaluation for every visitor to the site costs a lot of memory. On my Linode 512, it only takes about 90 users before all the memory is consumed and I have to start garbage collecting. If you saw that message when you tried to evaluate something, you probably got GC'd.
I'd like to find a more graceful way of handling this. Any suggestions?
I'm not familiar with Arc's internals or the effect that this would have in the context of GC, but as a hack, perhaps you could assign multiple people to a single interpreter instance, prepend prefixes to symbols to avoid collisions before evaluating (e.g. user_1_total, user_1_total, user_2_total), and make each user optionally aware of commands from other users on that instance (e.g. implemented as in-browser chat), letting individual evaluations block each other -- I doubt anyone's doing anything particularly heavy-duty or time-sensitive on your server.
This is convoluted and fragile, but if I wanted to roll out "sandboxes" on limited hardware I'd start with something like this.
This is a very clever idea. Even if I don't implement it this way, your suggestion has inspired me to think outside the box.
Here's an approach that's a variation/refinement of my current one: Instead of just orphaning old clients when their sandboxes get GC'd, leave them with a local copy of their REPL history. If they try to use the REPL again after a long period of silence, a new sandbox will be allocated for them (as it would be for a fresh client), and all the commands in their REPL history loaded in to bring it back to its previous state.
This approach could potentially pave the way for users having persistent REPLs, even across page reloads.
The biggest problem the language has is lack of marketing (something I think we in the Arc community should take PG to task for).