info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
is node and javascript just a load of shit? why not use aolserver?
71 views
Skip to first unread message
polymorph self
Apr 4, 2017, 1:52:54 PM4/4/17
to
or naviserver?
simon.m...@just-eat.com
Apr 5, 2017, 5:58:23 AM4/5/17
to
On Tuesday, 4 April 2017 18:52:54 UTC+1, polymorph self wrote:
> or naviserver?
Its been on my mind too..
Sadly software is pop culture.
And self-fulfilling.
I expect there will be a lot of 'maintenance' contracts in the near future as this wave of node.js installations unravels as rapidly as they get thrown up :).
And then people will point to all the 'jobs' for javascript as some sort of positive reflection on the technology.
But.. to your point, AOL/Naviserver are different beasts and not fundamentally based on an asynchronous event loop.
Is TCL better than Javascript? Highly subjective I guess. Both are dynamic, both a pretty easy to use. Despite its many flaws JS is actually a proper functional language and on the node.js platform it is probably 'faster' than TCL.. although its mainly the asynchronous behaviour in largely IO bound contexts that accounts for much of the perceived performance ( and perhaps TCL does well here too ).
A better comparison would be with Cowboy / Erlang I think.. which if one was being entirely dispassionate is far superior to either in terms of performance, scale and distribution ( and Erlang is pretty easy, high level functional and dynamic stuff too. Much to love for the TCL'er ).
A proper pre-emptive, process oriented model is also a far less leaky abstraction than events, co-routines and non-preemptive stuff that is the hallmark of TCL core and Javascript. With a process-concurrent model there is vast array of problems you just 'don't need to worry about'..
So for what its worth.. if would posit that
Cowboy / Erlang... but if not AOL/Naviserver TCL.. but if not PHP*.. but if not Node.js / Javascript
:)..
*I am of course joking
--
------------------------------
This is an e-mail from the company JUST EAT plc. This e-mail may contain
confidential information and/or privileged or personal advice. This e-mail
is intended for the addressee(s) stated above only. If you receive this
e-mail by mistake, please return it to JUST EAT plc without producing,
distributing or retaining copies hereof. Thank you.
> or naviserver?
Its been on my mind too..
Sadly software is pop culture.
And self-fulfilling.
I expect there will be a lot of 'maintenance' contracts in the near future as this wave of node.js installations unravels as rapidly as they get thrown up :).
And then people will point to all the 'jobs' for javascript as some sort of positive reflection on the technology.
But.. to your point, AOL/Naviserver are different beasts and not fundamentally based on an asynchronous event loop.
Is TCL better than Javascript? Highly subjective I guess. Both are dynamic, both a pretty easy to use. Despite its many flaws JS is actually a proper functional language and on the node.js platform it is probably 'faster' than TCL.. although its mainly the asynchronous behaviour in largely IO bound contexts that accounts for much of the perceived performance ( and perhaps TCL does well here too ).
A better comparison would be with Cowboy / Erlang I think.. which if one was being entirely dispassionate is far superior to either in terms of performance, scale and distribution ( and Erlang is pretty easy, high level functional and dynamic stuff too. Much to love for the TCL'er ).
A proper pre-emptive, process oriented model is also a far less leaky abstraction than events, co-routines and non-preemptive stuff that is the hallmark of TCL core and Javascript. With a process-concurrent model there is vast array of problems you just 'don't need to worry about'..
So for what its worth.. if would posit that
Cowboy / Erlang... but if not AOL/Naviserver TCL.. but if not PHP*.. but if not Node.js / Javascript
:)..
*I am of course joking
--
------------------------------
This is an e-mail from the company JUST EAT plc. This e-mail may contain
confidential information and/or privileged or personal advice. This e-mail
is intended for the addressee(s) stated above only. If you receive this
e-mail by mistake, please return it to JUST EAT plc without producing,
distributing or retaining copies hereof. Thank you.
0 new messages