It's apt to compare Tcl to Node.JS because of the similar I/O-model.
Tcl is slower than Node.JS (a broad statement, but e.g., it's not JITed), and the last time I checked Tcl's event loop was select-based and not epoll/kqueue-based. Looking at the code for 8.6.2, it appears to be like that still.
I like Tcl, but I wouldn't use it for high-concurrency tasks (I would use Go for that). It's nice when you need a DSL to extend your application, or if you want to glue C libraries together, but there are better tools for network code.
The similar IO model? It is just the Unix IO model though, with the caveat to never use blocking IO. Tcl doesn't force non blocking IO like Node, you have to do it yourself.
Event based IO was around by 1999 or earlier, according to the C10k page that we all avidly read backin the day http://www.kegel.com/c10k.html
Both Tcl and Node.JS are built around the concept of an event loop. The preffered way to do IO in both languages is to express your network application as a FSM with callbacks on state transitions. Of course event driven IO is not in any way "owned" by either languages, what I mean is that they both encourage an event-driven IO model.
For me it's more like gee, I had a job writing Tcl and it was so much "fun". I've just tried the example from "Read messages chunk by available chunk" and got:
invalid command name "handle_data sock4"
while executing
"[list handle_data $chan] "
(procedure "handle_client" line 8)
invoked from within
"handle_client sock4 127.0.0.1 40642"
I replaced [list handle_data $chan] with a plain handle_data $chan, but then another bug come up:
invalid command name "buf"
while executing
"buf sock4,data_ready write"
(write trace on "buf(sock4,data_ready)")
invoked from within
"set buf($chan,data_ready) 0"
(procedure "handle_data" line 4)
The fun never stops :-) In a way Tcl makes shell scripting (Bash) look wonderful because at least there you can't expect much from it, whereas Tcl presents itself more like a "real", full-blown programming language.
Your error looks like there might be an extra space after the line continuation (backslash) in the example.
The trace command is split in to 2 lines for readability but the web page's formatting introduced a hidden space if you try to copy/paste the example in to a tcl script.
"From SMTP filters/routers that handle millions of email deliveries a week to in-memory message journaling (for redundancy) that handle hundreds of transactions per second."
I stopped right there. To me, high performance is for instance, handling millions of emails per minute, thousands or tenth of thousand TPS. This is high performance, real life performance, not seen only in "physic labs and university research centers".
Some comments talk about Tcl using select. If this is true, it would mean a max of 1024 connections in parallel, kind of sad...
The C10k problem is 15-20 years old. Tcl uses select() which can handle a maximum of 1024 FDs. In other words, it would not be able to handle more than 1024 connections in parallel.
Moreover, Linux and FreeBSD have introduced syscalls comparable to select(): epoll (in 2002) and kqueue (in 2000). Those are way faster than select() and I think there's (virtually) no limit on FDs. Tcl must be using select() for its portability I guess.
So, handling a lot of concurrent connections is an old problem. In 2006, the C10k problem was way behind. Even at that time, I would have expected a program to be able to handle thousands of TPS.
18 comments
[ 2.9 ms ] story [ 46.5 ms ] threadTcl is slower than Node.JS (a broad statement, but e.g., it's not JITed), and the last time I checked Tcl's event loop was select-based and not epoll/kqueue-based. Looking at the code for 8.6.2, it appears to be like that still.
I like Tcl, but I wouldn't use it for high-concurrency tasks (I would use Go for that). It's nice when you need a DSL to extend your application, or if you want to glue C libraries together, but there are better tools for network code.
Event based IO was around by 1999 or earlier, according to the C10k page that we all avidly read backin the day http://www.kegel.com/c10k.html
Am I making myself clear?
If anyone is reading this article and thinking "Gee, I wish I could get a job writing Tcl", hit me up.
The trace command is split in to 2 lines for readability but the web page's formatting introduced a hidden space if you try to copy/paste the example in to a tcl script.
I stopped right there. To me, high performance is for instance, handling millions of emails per minute, thousands or tenth of thousand TPS. This is high performance, real life performance, not seen only in "physic labs and university research centers".
Some comments talk about Tcl using select. If this is true, it would mean a max of 1024 connections in parallel, kind of sad...
Moreover, Linux and FreeBSD have introduced syscalls comparable to select(): epoll (in 2002) and kqueue (in 2000). Those are way faster than select() and I think there's (virtually) no limit on FDs. Tcl must be using select() for its portability I guess.
So, handling a lot of concurrent connections is an old problem. In 2006, the C10k problem was way behind. Even at that time, I would have expected a program to be able to handle thousands of TPS.
This is obnoxious, way too common and as another comment points out seemingly aloof to the fact that the article is 8 years old.
Please, just to stick to self-promotion [1][2][3][4].
1: https://news.ycombinator.com/item?id=6560909 2: https://news.ycombinator.com/item?id=6573974 3: https://news.ycombinator.com/item?id=8086250 4: https://news.ycombinator.com/item?id=8200975
;)
And as I'm saying in following comments, even in 2006, this was poor performance.