It used Racket's inbuilt Threads, http constructors, and the only external package, db-lib, to talk to Postgres.
Supported about ~12,000 long-lasting connections/min for the first 48hrs, without dropping or being overly slow.
Lack of some libraries weren't really an issue, because:
* Typed, Lazy and normal Racket can all talk to each other easily.
* Re-inventing the wheel is ridiculously easy and quick in Racket.
* Re-writing something from SLIB [0], is a five minute thing, if you need to make any changes.
* Racket has a decent FFI, and wrapping C is simple. (There is also progress for talking to Java)
Add to that, for most people Python is easy. And when they get used to parentheses, most of my team were surprised to find Racket is a lot like Python, which meant fast iteration, with better performance than Python, but less opinion.
Have you taken a look to see if you find what you need?
For a parallel example: At first I was reluctant to develop in Common Lisp due to what appeared to be "too few libraries", again, it's just an appearance when you compare to the amount of libraries for a more mainstream platform like Java or C++. However, for CL i found all the libraries i needed (and then some); i wouldn't be surprised if for Racket you can find everything you need.
It's usually not so much the number of packages itself, as it is the degree of maturity or support. It is indirectly connected to count in a sense that, say, you might have a dozen packages doing the same thing for Java or Node, of which three have more than one maintainer, and one is mature and stable - and so you can use that latter one without worry. Whereas in smaller ecosystems, you often end up with just one package being your only option, and so you just live with the fact that it has a single maintainer (who can decide to quit for whatever personal reasons any day), and has been version 0.x for years.
However, in Racket (and Scheme, Lisp, Clojure, LFE, etc.), due to the extra flexibility, the language lets you extend the library in a much easier way (than in Java or C++), so becoming a contributor to said library becomes a viable proposition.
I agree. Moreover, like the examples in the benchmargame, usually for code that only crunch numbers Racket is 10x-20x times faster than Python. For code that use a lot of strings or hash-tables, Racket is usually slightly slower, 20%-50%. YMMV.
It's also important to compare the idiomatic version of the code in Racket versus the idiomatic version of the code in Python. If you make a line by line translation, you can get an awful performance.
Also, remember that by default the DrRacket IDE use the mode "debugging" and "preserve stacktrace". They are very handy for debugging but they make the code much slower. The recommendation is to run the benchmarks in the command line. But if you disable "debugging" and "preserve stacktrace" the results are quite good.
“… After all, facts are facts, and although we may quote one to another with a chuckle the words of the Wise Statesman, ‘Lies—damned lies—and statistics,’ still there are some easy figures the simplest must understand, and the astutest cannot wriggle out of.”
If people out there are satisfied with Ruby and Python3 performance, then they will be even more satisfied with Racket, which should run at 2x speed at least...
We used Bigloo for a while (with a considerable amount of in-house developed code/libraries). That project has since ended, but it was fun while it lasted.
