It did less than AOLserver, but was also very lightweight and easy to integrate with Apache.
For a long time, https://flightaware.com/ used Rivet under the hood.
Tcl was... is a fantastic language for doing web development. Its flexible nature made it really good for doing template/PHP type stuff, and being pretty string friendly, you had a lot of what you needed out of the box.
> Tcl was... is a fantastic language for doing web development.
Except for JSON. You can't round-trip JSON through Tcl because dicts are lists are strings. There are solutions out there (https://wiki.tcl-lang.org/page/JSON), I even wrote a few of them, but in the end there is a fundamental impedance mismatch. It gets in the way of emitting JSON from quick hacks or the REPL because you essentially need an explicit schema.
For text-based templates, Tcl is good. I have written code to generate CSS in Tcl (once for https://www.tcl-lang.org/! -- I made it responsive) and loved how well the language fit the task.
Also lots of stuff at Mozilla, because of Netscape. Usually signifies an older part of the Firefox codebase.
Back in 1999 I joined a startup (Intervento) that had a product based on the same ideas, we created our own Tcl module that could be plugged into either Apache or IIS, had a DB abstraction layer that would generate all CRUD stuff for each table for Informix, MSSQL, Sybase SQL, DB2, Access, Oracle, targeting Aix, HP-UX, Solaris, Windows NT/2000, (we also had Linux but it wasn't considered production ready), extensions could be furter coded in either Tcl or C, and we had an IDE written in VB 6.
We got acquired and became part of Altitude Software, eventually as MSFT partners we got early access to .NET and decided to port the same ideas into .NET, this gave us the performance that Tcl/C didn't deliver under very heavy loads, and Visual Studio.NET was better that what we managed to have with our in-house IDE.
Eventually some of Intervento founders left, and created what is nowadays known as OutSytems, one of the few successful low code companies.
It was a great experience, however as one the persons responsible to optimize Tcl code into C modules, and part of the .NET migration team, I learned to never consider languages without a JIT/AOT compiler for nothing serious beyond OS scripting tasks.
As a slight aside, I once worked on a molecular dynamics simulation program which used Tcl for the basic setup, and then performance critical parts were done in C. A fine enough approach, except that the original authors had decided that the one hammer to get good performance out of C was inlining. And they used this everywhere. Literally everywhere. Everything except for main() and some I/O functions was defined in "static inline" functions in header files.
I've always hated when APIs and types are prefixed like this. It doesn't play very well with autocompete.
Are the names some sort of cyberpunk in-joke?
In 1999, I was hired by ArsDigita, a web startup that used AOLserver, mainly to provide internal development and support for AOLserver. ArsDigita used big multi-CPU Sun servers (this was long before Oracle bought Sun) and I ended up diagnosing several race conditions in AOLserver that the AOL developers had trouble reproducing because they did their dev work on single-CPU boxes.
Fun fact, ArsDigita founder Philip Greenspun (of Greenspun’s Tenth Rule) knew Robert Thau from their shared alma mater MIT. Robert Thau (rst) designed and implemented Apache’s original module API. So ArsDigita hired rst to write mod_aolserver, an Apache module that provided enough of AOLserver’s API to allow running ArsDigita’s codebase (ACS) under Apache.