Live data from Hacker News

Comparing Node.js with Tcl

pietersz.co.uk

11–20 of 28 posts

Re: Comparing Node.js with Tcl

#11
post #5

Earlier quoted context omitted.

The point it that he's comparing his TCL code (which is as fast as he could be bothered to make it) to a 'hello world' tutorial that was written as an introduction to Node, not as anything that was designed to demonstrate Node is in any way fast.

The 'hello world' example is a good comparator: Presumably the Node developers have optimised the `http` library as much (if not more) than the author's Tcl equivalent. Given that they are therefore doing the same thing, it seems a fair test. Beyond forking new Node processes to handle more requests, I don't think you could make it faster (likewise with the Tcl version). That said, while it's a fair test, I don't thi…

I suspect that for something non-trivial, it will depend on what you are doing. TCL is slow at most things, has fast string manipulation and very fast regular expressions. TCL also makes it easy to write some C to do your heavy lifting, which could be very fast indeed. On the other hand it lacks libraries for async database access etc.

It was not meant to be more than a limited test of the TCL event loop and my code.

Re: Comparing Node.js with Tcl

#12
post #2

So some Node written by a self-confessed Node novice, based on a 'hello world' example, and running on an old(ish) verson of Node is actually quite similar in performance terms compared to TCL written by someone who knows how to write a TCL server from scratch. That is not a reasonable comparison. Get someone with some Node experience to write the Node server, then compare them.

How much could you optimize a "hello world"!

I was never all that great a TCL programmer - it was the first language I did any real work in, and I had quite limited experience at the time I wrote that.

Re: Comparing Node.js with Tcl

#13
post #7

This is a very silly comparison. There's a huge difference in terms of features and reliability between node's http module and this - http://pietersz.co.uk/software/dandelion-server I'm sure an equally minimal http implementation using the net module would match or beat that, but since you'd never use either of them in production, the results are meaningless.

>There's a huge difference in terms of features and reliability between node's http module and this

Yeah, but in which software's favor?

TCL has been battle-tested for decades, even in industrial automation...

Now, this particular server might be just some guy's quick project, but Node also started as a ho-hum experiment...

Re: Comparing Node.js with Tcl

#14
Tcl may be tolerable if what you need is on the level of some shell script. Beyond that, it's the most god-awful language I've ever seen, barring only classic BASIC.

So this comparison is as skewed as can be. Writing server (or even client) software in Tcl is a pure travesty.

Re: Comparing Node.js with Tcl

#15
post #13
post #7

This is a very silly comparison. There's a huge difference in terms of features and reliability between node's http module and this - http://pietersz.co.uk/software/dandelion-server I'm sure an equally minimal http implementation using the net module would match or beat that, but since you'd never use either of them in production, the results are meaningless.

> There's a huge difference in terms of features and reliability between node's http module and this Yeah, but in which software's favor? TCL has been battle-tested for decades, even in industrial automation... Now, this particular server might be just some guy's quick project, but Node also started as a ho-hum experiment...

> TCL has been battle-tested for decades, even in industrial automation...

Right but I believe the point was that this http implementation was less battle-tested than node's and that if you're willing to strip away features from the node version, it too could outperform node's version in a microbenchmark.

Re: Comparing Node.js with Tcl

#16
post #11

Earlier quoted context omitted.

The 'hello world' example is a good comparator: Presumably the Node developers have optimised the `http` library as much (if not more) than the author's Tcl equivalent. Given that they are therefore doing the same thing, it seems a fair test. Beyond forking new Node processes to handle more requests, I don't think you could make it faster (likewise with the Tcl version). That said, while it's a fair test, I don't thi…

I suspect that for something non-trivial, it will depend on what you are doing. TCL is slow at most things, has fast string manipulation and very fast regular expressions. TCL also makes it easy to write some C to do your heavy lifting, which could be very fast indeed. On the other hand it lacks libraries for async database access etc. It was not meant to be more than a limited test of the TCL event loop and my code.

Node's regular expression engine will run circles around almost every other language implementation out there.[0] This is thanks to Google's work on V8.[1] Regexes are, maybe surprisingly, one of the few things that Node is good at.

[0] http://benchmarksgame.alioth.debian.org/u32/performance.php?...

[1] http://blog.chromium.org/2009/02/irregexp-google-chromes-new...

Re: Comparing Node.js with Tcl

#17

Tcl may be tolerable if what you need is on the level of some shell script. Beyond that, it's the most god-awful language I've ever seen, barring only classic BASIC. So this comparison is as skewed as can be. Writing server (or even client) software in Tcl is a pure travesty.

I'm sorry, but you're really wrong. TCL is a beautiful language; consistent, easy to extend both semantically and syntactically, it offers a stable and mature ecosystem and is quite performant for an interpreter.

> it's the most god-awful language I've ever seen

I wonder, how many and which exactly languages have you seen, used and learned? Are you sure you're versed in PLT enough to be able to really understand all the TCL features and their impact on the language?

I'd say TCL is fairly similar to Lisps and REBOL, which makes it both simple and hard to master. It also makes it very different from BASIC...

[EDIT: typo]

Re: Comparing Node.js with Tcl

#18
post #10
post #7

This is a very silly comparison. There's a huge difference in terms of features and reliability between node's http module and this - http://pietersz.co.uk/software/dandelion-server I'm sure an equally minimal http implementation using the net module would match or beat that, but since you'd never use either of them in production, the results are meaningless.

I state the point of the comparison in the post: to see how TCL's event loop + my code compres. Node's http module is fairly lightweight, and even if something more minimal would beat my TCL code by a bit it still show what I wanted to, that they are comparable and TCL is an option for event driven servers (at least as far as performance goes)

Sounds like your title is a distraction.

Re: Comparing Node.js with Tcl

#19
post #18
post #10

Earlier quoted context omitted.

I state the point of the comparison in the post: to see how TCL's event loop + my code compres. Node's http module is fairly lightweight, and even if something more minimal would beat my TCL code by a bit it still show what I wanted to, that they are comparable and TCL is an option for event driven servers (at least as far as performance goes)

Sounds like your title is a distraction.

Ok, we s/Beating/Comparing/'d the title.

Re: Comparing Node.js with Tcl

#20
Interesting enough, Tcl was one of the past's most versatile tools. We used it in agent-oriented programming in 90's where code could move from place to place to cut data bill. Sandboxes were built for it. Tcl was also used in AOLserver and a related web framework before that became a fad. So, the author's point that Tcl is an option for high-performance event driven apps was proven when the highest traffic site in the world ran on it. I think we have something better today in about every area due to inherent properties of Tcl and labor invested in other solutions. Yet, Tcl delivered plenty in the past, apparently still can, and has potential for people using that sort of thing.

The main potential, though, is portability and future-proofing. Tcl is so ridiculously simple that it's been implemented on about every OS and architecture. That's batteries included due to all the existing code and ActiveState's development tools. People can extend live apps, run shell scripts, configure networks, and so on all using the same (or a similar) language. Any change in underlying platform just requires porting the (simple) lower layers. Makes Tcl a powerful future-proofing option if used judiciously.

Post reply on HN