I happen to know of tens of thousands of running instances, and I'm sure many HNers will interact with one today. Can't say more ;-)
Aolserver is reliable and efficient. Tcl is reasonably efficient for most purposes (which is to say, dog slow but who cares?) though we drop down to C++ in many cases where Tcl might not be fast enough.
Tcl is a powerful but strange language. The heavy dependence on strings in its implementation is problematic, to say the least. An object of a particular type may be converted to a string representation, deleted in its original form, and then resurrected from the string representation later. That's not exotic functionality; it's normal in ordinary usage of the language, and it would invalidate the use of Tcl's reference counting for resource management. Therefore, when you define a new type that manages a resource (a resource such as a "future" object returned from C++ land, when you're waiting for an asynchronous operation to complete) you have to be sure NOT to implement working object->string and string->object conversion methods on that type. You have to implement those methods to signal an error to ensure that the object is never stored as a string and then resurrected later.
That's all fine and dandy, but that means you can't store objects of that type in a list, because a Tcl list is a string built from the string representations of its members. In case you were wondering how an object might be converted to a string, deleted, and then resurrected later from its string form, that's exactly what happens when you add an object to a list, dereference the original instance, and then retrieve that item from the list. Truly weird.
Sounds odd, but of course, strings are all computers store anyway; your address space is a big string (with holes, perhaps) from 0x00000000 to 0xffffffff, and that's where everything is. (And yes, if you have a 48-bit or 64-bit address space, the string is longer.)
So what's strange is not the representation but how it's not hidden from the programmer.
Speaking with some knowledge of the inner workings of Tcl, I can assert that your description is not correct in recent Tcl: you must be doing something more to that object, or misinterpreting what is happening. I suggest creating a bug ticket at Tcl's SF site with a description of the problem and sample code.
It wasn't recent work so likely not recent Tcl, but are you saying that Tcl no longer represents lists as strings? I'm surprised such deep changes are still being made in an old language.
:) If you are using Tcl7 (Tcl8 is 10+ years old) or the OLD string interfaces on Tcl8, things go through the string rep and will be dog slow - your fault. Tcl's lists, for instance, are maintained internally as C arrays of pointers to the element objects. The roundtrip through the string rep can happen, but only if YOU treat the list as a string (more generally, as a non-list).
As to "deep changes to an old language": Tcl is actively maintained and still evolving. Tcl8.5 introduced anonymous functions among many other changes; Tcl8.6 (in beta) has a completely new engine (somewhat similar to py's stackless), coroutines and tailcalls, a builtin OO system, and many other enhancements.
The roundtrip through the string rep can happen, but only if YOU treat the list as a string (more generally, as a non-list).
That's a hell of a thing to have to document, so I think it was appropriate to have the string conversion functions raise an error. When I worked on it, the code was running in Tcl 8.3 or 8.4, and I was able to reproduce the round trip through the string reliably with exactly the operations I described. I may have printed the list to the console as part of the test, and if that qualifies as "treating the list as a non-list" it pretty well proves the need to assume the worst. (It's also possible I was using older interfaces, even 10+ year old interfaces, since I kept my code consistent with the existing style in our software, but it's pretty harsh to say "your fault" if the interfaces for the most basic type in the language changed between versions 7 and 8, just saying.)
Oops, I did not mean to be harsh and apologize for coming across that way.
Tcl8 introduced the Tcl_Obj and a completely new api to deal with them. The old string-based interfaces were kept in place, because we value back compat a lot. They are flagged as deprecated in the manual pages and should only be used by legacy Tcl7 code, or when performance is known not to be an issue.
As to printing the list to the console: that should compute a string representation of the list object without discarding the representation as a list.
We used it, along with OpenACS for the Virtualmin website for about a year in 2005. It was better than the Joomla site that we replaced it with, in terms of reliability, performance under load, and maintainability. But, we finally got it right when switching to Drupal a couple of years ago.
I had no complaints about AOLServer. It was fast, reliable, small, well-documented, and did everything we needed it to do. I like Apache better, of course, because Apache can do vastly more...so many more developers just leads to more code being written. But, I never lost any sleep because of AOLServer, which as an IT guy, is my gold standard for good software.
I have a number of clients using it, they are all happy with it in terms of performance and reliability.
However they tend to be deployments based on work done previously (the dreaded "legacy" code) and for which it doesn't make sense to spend more money to rewrite the site in another language.
For example, one client is still running code originally written in 2002-2003, they just updated the templates.
Another is using the OpenACS.org codebase and is actively developing custom solutions for clients, where the client doesn't care what the technology is underneath the solution.
I personally think the ticket-tracker in OpenACS, were it cleaned up a bit more, would make an excellent lightweight ticket tracker hosted service for many small dev teams.
I just started a new job at [company you've most likely heard of if you live in a large U.S. city] and we use it here.
It's nuts. TCL's syntax is extremely simple, but overall appears to be really powerful.
Still trying to wrap my head around some of the more advanced things, but it apparently scales very well and has great community/group aspects built in.
The included ticket tracker makes for an unbelievable customer service platform, too.
Zipcar had been trying to move off Tcl, but I don't know how seriously they were focused on that or what their status is. My impression is that had much more to do with trouble finding experienced devs than any issues with the technology stack, though.
I'm a big Tcl fan, and had a hand in the most recent version of Ousterhout's book, but it's a bit of a surprise that they picked Tcl, as it's honestly not that popular these days. Wonder who it was that made that decision.
If nothing else, sounds like round 26339132 of the Tcl marketing "fail": company complains about not finding people, while simultaneously hiding themselves from the community of the product they're using, and hiding the fact that they're using the technology in question.
Actually migrating the last openACS app over to Pyramid in the next week or so. Not from a failure point of OpenACS or AOLServer - both products have worked very well.
As far as performance, I found it to be somewhat akin to Apache + a moderate CMS. It scaled better than bare apache which at the time was a large consideration. Only one of the projects ever hit a point where scalability became a concern.
I think Philip Greenspun's thinking on CMS design and entrepreneurship had quite an impact on my thought processes.
OpenACS's code - not really a stellar example of well written code. Functional, but messy.
Nothing bizarre about it, given that nginx can serve many thousands of slow-receiving web clients while AOLserver usually uses 1 thread per connection - so 20 slow clients can effectively stall 20 threads.
Thus the strategy is to use nginx to serve static content like .css .js .png .jpg .gif, plus grab the dynamic content from AOLserver and buffer it out to the order of magnitude slower clients (10Mbps client vs 100Mbps or 1Gbps link between nginx and AOLserver).
Thanks for the explanation. I've never used AOLServer and was unaware of its limitations. Seems to have the same limitations/scaling problems as the two most popular Apache MPMs. :)
My main setup nowadays is HAPRoxy -> nginx load balancers -> Unicorns.
The Aolserver web server is one of the most readable C programs I've ever seen. Each function definition is preceded by documentation of its purpose and side effects. Unfortunately the modules tend not to be quite as clean. The development community is dwindling but exceedingly polite and helpful.
The one gripe I have is that the tuning parameters are not well documented (especially post 4.5.0). You have to study the source in order to dig out all the parameters you need to tweak in order to really make the server sing.
The Ns module API was also very clean. This is why we choose it to embed our libraries and expose an HTTP interface to our other internal applications. It's worked reliably for this purpose for years. Since all our development work is inside our module wrapper, we have no immediate plans to move away from AOLserver. It just works fine as a lean web server.
What's the current state of teacup? Working with the current web technologies, I'd miss the library support that Python/Perl/Ruby have, and building everything yourself and packaging that as a starkit is nice for desktop apps, but for servers…
I've used it continually since 2001, and I'm still using it now. The downside is that most companies have forked the OpenACS code internally (including universities using dotLRN) --- that code never made it to the outside world. If you needed an extension, it has always been the case that you had to write it yourself. Developers are indeed an often scarce good but that has worked well for those of us that are still around.
Scholastic UKs website is predominantly a Rails frontend app (with the exception of many PHP minisites and one OpenACS site) all talking to an OpenACS / PG / iSeries backend. It truly is a monument to over 10+ years worth of web development. Though the main reason towards the Rails switch was the lack of TCL developers, though, strangely enough, good local Rails developers are equally as rare.
Well, I've used it a fair bit, always in conjunction with ACS or OpenACS. With the exception of supporting legacy TCL code, I can't think of a good reason to use it over Apache/Nginx with Ruby/Python nowadays.
Aolserver is reliable and efficient. Tcl is reasonably efficient for most purposes (which is to say, dog slow but who cares?) though we drop down to C++ in many cases where Tcl might not be fast enough.
Tcl is a powerful but strange language. The heavy dependence on strings in its implementation is problematic, to say the least. An object of a particular type may be converted to a string representation, deleted in its original form, and then resurrected from the string representation later. That's not exotic functionality; it's normal in ordinary usage of the language, and it would invalidate the use of Tcl's reference counting for resource management. Therefore, when you define a new type that manages a resource (a resource such as a "future" object returned from C++ land, when you're waiting for an asynchronous operation to complete) you have to be sure NOT to implement working object->string and string->object conversion methods on that type. You have to implement those methods to signal an error to ensure that the object is never stored as a string and then resurrected later.
That's all fine and dandy, but that means you can't store objects of that type in a list, because a Tcl list is a string built from the string representations of its members. In case you were wondering how an object might be converted to a string, deleted, and then resurrected later from its string form, that's exactly what happens when you add an object to a list, dereference the original instance, and then retrieve that item from the list. Truly weird.