Not the OP, but using TCL in the first .com wave taught me that any language without JIT or AOT support on their toolchains are bad fit for anything that needs to scale.
This is specific to Tcl, but it is byte compiled [0], and work is ongoing right now to target llvm[1]. To say nothing of punting and coding performance-critical code in C and orchestrating it all via Tcl.
Well, the LLVM announcement certainly is new. You'll have to forgive me though, I thought you may have been propagating the old "in Tcl, everything literally is a string" trope.
What did you press it into service for in ye old .com boom?
An application server built on top of Apache and IIS modules, targeting Windows and multiple UNIX flavours.
Similar to AOL Server and already using quite a few patterns that people seemed to only have discovered years later with Ruby On Rails, but since Portugal isn't SV no one heard of them.
All critical path routines were actually done in C.
However, eventually the platform was migrated to .NET with focus on Windows.
The founders of this company went on to found OutSystems, with the lessons taken from this attempt.
I do most of my work in ruby and am a fan of it (less of some decisions it's community makes, but I'm still okay with it)... and I shy away from rubinius because I don't think it has enough to offer to justify the non-boring risk/tax. I don't want to be discovering that some gem I use (perhaps only a couple versions after i start using it) isn't compatible with rubinius. Even if it's a small risk (and I honestly am not sure how much of a risk it is), for what? Slight performance edge? I don't need it. Multi-core parallelism? I usually don't need it, and if I do, I'm going to choose JRuby (reluctantly).
