Comparing Node.js with Tcl • Hacker News Board

Re: Comparing Node.js with Tcl

#21

Post by graemep » Wed, Jun 17, 2015, 4:42 PM UTC

beering wrote: post #16

graemep wrote: post #11

Earlier quoted context omitted.

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...

I did not know that V8 was that good as regexes. TCL is very fast, but it is quite likely that Node is faster.

On the other hand, I think the point that real world performance will depend on the task in hand stands.

Re: Comparing Node.js with Tcl

#22

Post by graemep » Wed, Jun 17, 2015, 4:44 PM UTC

woah wrote: post #18

graemep wrote: 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.

In retrospect the title is a bit too attention grabbing. If I had anticipated the reaction I could justly be accused of writing flame bait, but I did not expect it to get so much attention or debate - I thought just TCL people would be interested!

Re: Comparing Node.js with Tcl

#23

Post by klibertp » Wed, Jun 17, 2015, 5:59 PM UTC

beering wrote: post #16

graemep wrote: post #11

Earlier quoted context omitted.

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...

Nothing really surprising here.

Regexes are the only way to do more advanced text manipulation in JavaScript, so they're being used far more than in other languages. Lua is similar here, having only a couple most basic string operations built-in and relying on regexes for anything even slightly more advanced. This makes it natural for these languages' implementations to focus heavily on optimizing regexes.

Also, regexes are easily JITable and of course implementations having a JIT are going to be much more performant than normal interpreters. This explains the results of your [0] - I didn't check, but I suppose it's a vanilla Lua interpreter and not LuaJIT.

Re: Comparing Node.js with Tcl

#24

Post by mattLummus » Wed, Jun 17, 2015, 6:47 PM UTC

graemep wrote: post #22

woah wrote: post #18

Earlier quoted context omitted.

Sounds like your title is a distraction.

In retrospect the title is a bit too attention grabbing. If I had anticipated the reaction I could justly be accused of writing flame bait, but I did not expect it to get so much attention or debate - I thought just TCL people would be interested!

1. Node is not a language it is an implementation of a language, so the title would really be TCL vs JS or Dandelion vs Node...

2. In which case you would be opened up not only to performance benchmarks but usability, simplicity, and features - whether you are talking about the language or the implementation.

That being said, I have nothing against your opinions or work though and understand that your implementation is also from 2008 :)

Re: Comparing Node.js with Tcl

#25

Post by tempodox » Thu, Jun 18, 2015, 7:35 AM UTC

klibertp wrote: post #17

tempodox wrote: post #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.

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…

My exact pain points with Tcl are: (1) No types at all, everything is a string. If strings are all you have to deal with that may be enough but it gets hairy fast for everything else. (2) Dynamic scoping rules and `uplevel` & Co. Do I really have to say anything about that?

Re: Comparing Node.js with Tcl

#26

Post by klibertp » Thu, Jun 18, 2015, 9:15 AM UTC

tempodox wrote: post #25

klibertp wrote: post #17

Earlier quoted context omitted.

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…

My exact pain points with Tcl are: (1) No types at all, everything is a string. If strings are all you have to deal with that may be enough but it gets hairy fast for everything else. (2) Dynamic scoping rules and `uplevel` & Co. Do I really have to say anything about that?

> No types at all, everything is a string

At least there's no need for any kind of toString() method...

This is a design decision which makes the language smaller and easily composable. It also helps greatly with metaprogramming, because the code itself is also just a string - this makes Tcl homoiconic, which is a nice property to have. Last but not least, you can easily type-tag the values you use in more than one way if you want; you also have a built-in object system for cases where you need more structure in order for things not to get hairy.

> Dynamic scoping rules and `uplevel` & Co

Tcl is lexically scoped by default, it just provides ways to break out from lexical context. It's a good thing, allowing you to write for example this: http://rosettacode.org/wiki/Generic_swap#Tcl without any hassle. Like all design decisions it has its downsides, but it's a powerful tool if used correctly.

Tcl is not a bad language, it's just ill-suited for you or for your use case.

Re: Comparing Node.js with Tcl

#27

Post by tempodox » Thu, Jun 18, 2015, 9:57 AM UTC

klibertp wrote: post #26

tempodox wrote: post #25

Earlier quoted context omitted.

My exact pain points with Tcl are: (1) No types at all, everything is a string. If strings are all you have to deal with that may be enough but it gets hairy fast for everything else. (2) Dynamic scoping rules and `uplevel` & Co. Do I really have to say anything about that?

> No types at all, everything is a string At least there's no need for any kind of toString() method... This is a design decision which makes the language smaller and easily composable. It also helps greatly with metaprogramming, because the code itself is also just a string - this makes Tcl homoiconic, which is a nice property to have. Last but not least, you can easily type-tag the values you use in more than one w…

That rosetta code has NO static scoping (neither has Tcl, you got that wrong). It uses dynamic scoping with `upvar`. It's a design decision all right, just a really bad one.

Re: Comparing Node.js with Tcl

#28

Post by klibertp » Thu, Jun 18, 2015, 1:22 PM UTC

tempodox wrote: post #27

klibertp wrote: post #26

Earlier quoted context omitted.

> No types at all, everything is a string At least there's no need for any kind of toString() method... This is a design decision which makes the language smaller and easily composable. It also helps greatly with metaprogramming, because the code itself is also just a string - this makes Tcl homoiconic, which is a nice property to have. Last but not least, you can easily type-tag the values you use in more than one w…

That rosetta code has NO static scoping (neither has Tcl, you got that wrong). It uses dynamic scoping with `upvar`. It's a design decision all right, just a really bad one.

> That rosetta code has NO static scoping

That was the point! I pasted it as an example of what you can do with upvar, by bypassing lexical scoping. Take a look at other entries on that page: almost all high-level languages either pack the two variables into a list of some kind (passed by reference) or have a specialized language construct for this (inout etc.)

> neither has Tcl

This is very easy to disprove, take a look. This code:

    proc g {} {
        echo $a
    }

    proc f {} {
        set a 10
        g
    }

    f

results in an error in Tcl:

    can't read "a": no such variable
        while executing
    "echo $a"
        (procedure "g" line 2)
        invoked from within
    "g"
        (procedure "f" line 3)
        invoked from within
    "f"
        (file "main.tcl" line 35)

while in a dynamically scoped language, like Emacs Lisp, it would work:

    (defun g ()
      (message "%s" a))

    (defun f ()
      (let ((a 10))
        (g)))

    (f)

How can you argue with that, I wonder? :)

> just a really bad one.

It (upvar and uplevel) lets you easily define new control structures (think "unless", "until", "await", things like these). I don't think you can convince me that adding a powerful feature to the language is a bad decision... but that's indeed a matter of preference and there are people who use Go, so I'm not going to argue about this :)