[racket] Is racket suitable for such a project?

On Tue, 2014-02-11 at 10:11 -0500, Neil Van Dyke wrote:
> I can't answer the question in the Subject header off-the-cuff, but I 
> can comment on some of the details...
> For an onion router that has to handle lots of traffic at high speed, my 
> first guess would be C or maybe C++ (not Go or Java), though I can 
> appreciate wanting a higher-level language for this task.
I specifically wanted to avoid languages that require me to write an
event loop. Event loops are just too much hassle; in C and C++ the
alternative is pthreads, which are extremely heavyweight.
> 
> I would consider Python only if the project involves huge numbers of 
> people running onion nodes, and you want them to be able to inspect the 
> software themselves.  Python is far from perfect for this task, but it 
> would be good in that large numbers of people can read it, and a better 
> overall fit than JS.
> 
Hmm. Why? Isn't python considered not scalable? I've written servers in
Python before, and they were usually much slower than Racket servers.
> If you want to get creative, you might see whether you build this from 
> domain-specific languages in Racket, but have Racket target C code.  
> Like Pre-Scheme with DSLs.  (Also, going to a hardware description 
> language from DSLs.)
Chicken/Gambit does work, but the real reason why I find Racket so
attractive are advanced features like custodians and the fact that all
threads are user threads with nonblocking I/O underneath, which allows
thread-based servers to be as scalable as event loop servers.
> "#lang racket" is for demos, IMHO; I *always* use "#lang racket/base" 
> for any code that's not a demo.
Thanks, I'll kepp that in mind
> The Racket VM startup time is longer than it used to be, and I no longer 
> use it often as a quick command-line calculator.  (If filesystem and 
> libraries aren't in Linux caches, it's almost 4 seconds before REPL 
> prompt on my workstation.)  That might not have to be a problem for an 
> onion-router, however, even if you're starting up lots of processes 
> (since you might be able to start worker processes before they're needed).
This is actually a rather large problem for me, as I deploy on extremely
overprovisioned PlanetLab nodes (basically, free global cluster of VMs
for research purposes, for anybody from a university and asks nicely).
Startup can easily take upwards of 20 seconds, especially with Typed
Racket doing all those optimizations. I agree this isn't an issue with
servers; it's more users deploying the client on ancient computers
complaining that the program takes forever to start.

Another question: is there any way to make Racket release memory back to
the OS when it frees memory? Like the Java memory options? It seems like
Racket's heap grows until around 400 MB, and then uses this 400 MB as an
allocation arena. I don't want to be the jerk using up a few gigs of RAM
all the time on a shared server.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: This is a digitally signed message part
URL: <http://lists.racket-lang.org/users/archive/attachments/20140211/309935a3/attachment-0001.sig>