Cancer or not, Node.js is attracting plenty of interest, and just like smoking cigarettes at school Node.js is seen as the cool thing to do. Started by Ryan Dahl in 2009, this server-side scripting environment has in less than three years attracted enough coverage to persuade Microsoft, the world's largest software company, that …
Downvote away, you know you're going to want to.
1. Why the **** are you giving Ted Dzuiba any more credence as a tech writer than he deserves (which is none)?
(Yes, he doesn't like Node.js and he doesn't have to use it. For the rest of us, it's a tool to be used, should you wish to do so, and it carries up and down sides like everything else. For anything that's intended to service long-life connections, it's not really a bad solution. At least you can actually achieve such things in Node.js rather than trying to do it based on Apache/PHP if you have *any* plans about scalability)
I didn't down-vote you, and I'm in what follows I'm using "you" in a general sense.
You're doing what Microsoft have been doing for years - you're relying on tools to insulate your organisation or yourself from shit programming practices.
A better approach, and one I push for pretty strongly at work, is to educate teh hackerz. Topics range from authentication and authorisation to configuration management, DR and monitoring.
Node works well if you're working out of your garage, writing a web support page for a fart app in iTunes. But if you're dealing with user data, financial data or anything business critical It. Just. Doesn't. Cut. It.
Here's the thing, I read your post and everywhere I see 'Node', I can substitute in 'PHP' because it's precisely the same argument, just held a few years back, and with all the same connotations.
Bad coders make bad code no matter the language. Even skilled developers still make mistakes in any language, but at least the higher level language environments do insulate against certain classes of vulnerability - leaving a smaller potential surface of attack.
PHP or Node may not be perfect but I think you'll find it's a touch harder to execute raw machine instructions via them than it might be if the front-side apps are in C++...
Yes, educating the coders is important. There's just not enough people understanding authorisation, authentication, configuration management, DR, monitoring, or for that matter even processes like prevention of SQL injection, and dealing with XSS and CSRF matters are still not entirely understood by an awful lot of coders out there. And educating them is undoubtedly going to help.
Unfortunately, the more you try and remove protective layers, the more coder stupidity is going to cause problems, and it's not like the current generation of coders is that great at doing what they do. Nor the users for that matter.
Bottom line: Node isn't fully understood yet, sure. Doesn't mean it's not a suitable tool for certain cases, and I would love to see a tool that has security, robustness, performance, scalability and maintainability - and still allows me to work in a reasonably safe environment (i.e. not C++ because it's far too easy to have buffer overflows) while being able to handle the sorts of matters that PHP can't (which means if I don't use Node, I'm basically looking at Python/Twisted or Ruby/EventMachine for that use case... are you telling me that these meet all your criteria that Node does not?)
Mebbe you're right and mebbe you're wrong.
But 5 seconds to calculate Fibonacci sequence to 40? My dad had a pocket calculator that could beat that, and that was in 1983.
Sure it's is a contrived example, but other than the recursion the code looks OK on the surface and I've interviewed devs who've written worse. Abstraction is good - actually great - to a point, but like any model you've got to know when to apply it, and that comes from experience and understanding how it works under the hood.
Re: Re: Huh?!?
There are an awful lot of bad coders out there, and there's an awful lot of code that needs to be written. However, out of all of that code there's probably a relatively small amount that actually has requirements that would make an interpretive language impossible to use. We also don't have enough people with the wit and wisdom to work out what is appropriate and what is not.
Frankly, if we end up with people going back to using C++ for this sort of stuff, I predict a flood of buffer overrun security issues in servers all over the globe. I know you can write safe C++, and the people coding in C++ should know how to write safe C++. But that's theory, practice and experience should tell us something else...
We've got a generation of devs brought up on Java and C#, they're going to require careful supervision...
To follow myself up
I thought it best to quantify the outrage of 5 seconds to calculate this, and I confess I've surprised myself.
Same code in Java: 854ms (average of 100 runs after the 1st)
Same code in C: 3751ms (average of 100 runs)
Same code in Perl: I got bored, but the first round took about 163000s
So Node.js with it's slightly daft event model, at 5600ms - call it 5500ms to generously allow for network stack overhead - is only 22% slower than the same impementation in C, which is a whopping 430% slower than Java.
So although I vaguely dislike Node.js I'm reluctantly going to qualify my previous post as follows: "shit code can be written in any language; and never underestimate the power of an optimizing JIT compiler".
JS in itself isn't a bad language - I was writing JS OO libraries as far back as 1999 - but it stops bad coders from shooting themselves in the foot, and that's not necessarily good thing.
Writing asynchronous code in a language that doesn't support it is like doing maths in English: pointless masochism.
Re: To follow myself up
Am I missing something? When you say fibonacci sequence to 40, do you mean finding the 40th term? If so your doing something seriously wrong to get such ludicrous times.
Re: C vs java
If your C code is slower than java you don't know what you're doing.
Glad you're sticking to Java.
Re: To follow myself up
What on earth are you running your Fibonacci code on? I just tried a PHP and Python test and both generate 40 numbers in the series in under 10ms on a tiny little VPS. You must be doing something very wrong, even an old C64 would give better results than yours.
Re: Re: C vs java
Well done for failing to read his post. He said he implemented the SAME code in each, this is a discussion about how the compiler works with the SAME input, not about how to optimise code.
Go back to thinking how clever you are now.
Re: Re: Re: C vs java
Much obliged JDX, you saved me the effort. The code is taken from the linked-to article, and it's supposed to be bad. The point is to compare the same bad code in different languages.
OS X uses C++?
News to me. All Apple's documentation—which I'm inclined to trust as I'm learning to develop for their platform—makes it crystal clear that OS X is built on... Objective-C.
Objective-C had a similar birth to C++ and, like the latter, evolved from the original C programming language. Nevertheless, Objective-C took a different path to C++ and remains at heart a "C with Objects" language with a very clean design considering its age. By contrast, C++ has become a nasty, brutish camel of a committee-designed language that has more ways to blow your own foot off than a minefield.
Re: OS X uses C++?
It depends where in the source code you are looking. A lot of the kernel libraries (IOKit etc) are all C++ while user space (applications etc) can use ObjC. Suspect that the performance slant of the article gave rise to the author's ambiguity.
I'm not going to get into the whole C++ is the spawn of the devil('s committee) thing as it's really tired. There's nothing wrong with a feature-rich language providing it is designed right - if you don't like (or need) features, don't use them. C++ is designed so that language features do not add overhead if they are not used.
Re: OS X uses C++?
@Sean Timarco Baggaley: "All Apple's documentation—which I'm inclined to trust as I'm learning to develop for their platform—makes it crystal clear that OS X is built on... Objective-C."
You're confusing the application development framework with the underpinning of the OS itself. The fact that a particular environment is coded in one language doesn't preclude it from offering an API or development framework in another. There are many parts to OS X - some will be coded in C, others C++, and some in Objective-C too.
I guess common grounds would be Lazarus
That's native code, memory safe strings, and event-based processing all in one package. The only problem is that those features currently require you to use the graphical interfaces so you'll need an X11 server. That is, however only a problem with the current libraries and there's already talk about fixing it.
C++ has the huge problem that a) It doesn't even try to prevent you from shooting yourself into the foot and b) that there are only few people who are able to write C++ code without shooting themselves into the foot.
On modern Pascal you have native string types with the most common one being arbitrarily long and offering copy on write, so you'll only need to shift references in many cases. Plus you can opt-in for things like array boundary checking or integer range checks. (You also have working exceptions of course, so you can safely drop connections or have proper error messages.)
"On modern Pascal "
Oh please, give it up, pascal is dead and buried. Get over it. C++ is a lot more powerful that that kids language and if some programmers shoot their foot off because of that its not the fault of the language. A poor workman does not blame his tools.
Please, show me 10 programmers who can actually write good C++ code under real-life conditions.
If it was about power, people would use Assembler and add a macro pre-processor for it.
Horses for courses
@Christian Berger: "C++ has the huge problem that a) It doesn't even try to prevent you from shooting yourself into the foot and b) that there are only few people who are able to write C++ code without shooting themselves into the foot."
Why does every, single article about C++ attract a gaggle of "ooohh, C++ might blow your foot off" comments? You've mentioned 'shooting', so lets rephrase this as if we were actually talking about a gun:
"A gun has the huge problem that a) It doesn't even try to prevent you from shooting yourself into the foot and b) that there are only few people who are able to fire a gun without shooting themselves into the foot."
Now, how clever does that sound? C++ can be like a gun - they are both powerful and can be disastrously misused in the hands of someone untrained, inexperienced, or unbalanced. But they both have essential roles in the hands of trained, licensed professionals. And clearly, point B is false. There are literally thousands of professionals around the world who use C++ to great effect in "real-life conditions". And it's nice to occasionally see articles covering developments that concern the language. If you aren't one of those people, feel free to ignore the articles and - above all - don't even look at the comments, let alone contribute.
Re: I guess common grounds would be Lazarus
My last company and my current company are both completely C++ shops. Each of them had at least 10 people who can code C++ extremely well for extremely stable application. One was producing shrink wrap software that we couldn't afford to have crash or be packed full of vulnerabilities. The second produces realtime (not hard realtime) software that processes ridiculous amounts of data. Neither organisation could have produced the same thing in a garbage collected language for performance reasons.
With every language it is a case of picking the correct tool for the correct job. C++ is there when you want blinding speed in an object oriented package, and don't mind paying additional development costs to get it (C++ has longer development times than the garbage collected languages - both from compile times, also from the additional checking for memory leaks or corruption that you have to do, and from the simple fact that the language is more complex).
I'm happy to use garbage collected languages or dynamically typed scripting languages when the time is right for them.
Re: Re: Pascal??
"Please, show me 10 programmers who can actually write good C++ code under real-life conditions."
I could show you hundreds. Perhaps you should try working with professionals instead students or BAs who reckon they can program because they once did a course 10 years ago.
No it's not dead.. it's still used commercially. Modern pascal has modern features - generics, anonymous functions, namespaces, etc. and is far, far from what you probably learned at college.
It's big downside is it's single pass, which makes for some difficult choices as the program architecture gets more complex.
C++ is just different.. not more powerful, and I regularly write code in both where the situation demands it - along with half a dozen other languages. There's no overall best language, really.
Re: I guess common grounds would be Lazarus
Christian, I think you are kidding yourself. If you are a programmer capable of shooting yourself in the foot with C++ you will quite likely achieve the same in other, higher level languages. Maybe not buffer over/under runs but there are a myriad other ways to write crap, insecure software - SQL Injections, lack of input validation, XSS, ... the list is endless. A crap programmer will shoot themselves in the foot regardless.
With all this shooting at feet, its a miracle there isn't some kind of explosion...
Re: Re: Pascal??
Assembler cannot be used for power by almost any normal (or even leet hacker) human beings due to OOO (out of order execution), prefetching, etc. You need an optimizing compiler for anything non-trivial. There is a high chance a C or (even) Java compiler would generate better code than hand written assembler.
Hand written assembler in some cases could be clear win but those case are just too few.
Re: Re: I guess common grounds would be Lazarus
@AC, Feb 17, 13:32GMT
If you have free cores to run a non STW (stop-the-world) GarbageCollection, I can't see the overhead of the GC environment. As plus, GC allows for a lot of concurrent algorithms that are much harder or even impossible via standard ref-count.
If you rely on CAS for reference counting, it's already a quite substantial overhead even on modern CPU (Nehalem+), esp. if all of the CPU caches are not interconnected - even non-contended CAS causes more than local latency.
Re: Horses for courses
Everyone mentions the shoot your foot off analogy, because Straustrup was widely reported as having said it, as anyone old enough to remember will tell you.
"It's harder to shoot yourself in the foot with c++ [than c,] but when you do, you blow your whole leg off." was the main claim in the "I love Ada because it was designed to be bug reducing, even at sourcecode level, versus I love c++ because I love c++ because it looks like what I did on my uni course." wars of the 80s.
Re:Horses for courses
@AC: "Everyone mentions the shoot your foot off analogy, because Straustrup was widely reported as having said it, as anyone old enough to remember will tell you."
The problem is that the people who "quote" Stroustrup (misquote is more apt) seem to have no idea what he was actually talking about. The gist of it is that C++ is designed to be safer than C, i.e. it is more difficult to cause accidental harm, but in the hands of an incompetent or ignorant developer the damage can be much more severe. And that is the point I was trying to make - C++ is a powerful language, but that doesn't inherently make it dangerous. And the key ingredient - to my mind - is that it maximises *choice*. You can write something very much akin to assembly language if you want (or inline assembly where it really counts). Or build elegant, abstract frameworks. Or both. You can bolt garbage collection onto it if that suits the context, but the language doesn't force anything on you.
And my title - horses for courses - should have made it plain that I don't see C++ as a panacea for all software problems. Although I primarily use C++ (many of the tasks I address could not be done in anything other than C/C++), I use a variety of other languages depending on the context. I'm just sick of the "C++ is scary/cryptic/dated/etc" mentality. C++ is constantly evolving, and is a powerful contributor to modern software development.
Here's a Zen koran for you.
If Ted Dzubia writes an article, and El Reg doesn't link to it several times, does anyone read it?
Re: Zen Question
think you mean "koan" unless "koran" alludes to the whole "my programming language is better than yours" religious thing.
Re: Re: Zen Question
I think you're right :)
If mohammed is the last prophet, and he's dead, should we still listen to him?
If Google stick with Dart, that'll do the same job better.
That Cancer link is hilarious
My favourite: "Node Punishes Developers Because it Disobeys the Unix Way". I'd never heard of Ted before, but he sounds delightful and I think I shall bookmark him alongside TheDailyWTF.
I don't know whether I should be dismayed because that Dziuba guy sounds like a maintainer of 4chan popping speed pills or moderately in accord because underneath all the Kid Rage Talk there are these points:
1) Separation of concerns is good, moving applogic into the webserver is bad.
2) You are not as blocking as you naively might think you are
... but then we knew all that, right?
I still don't get where his REAL problem is.
>C++ is so compelling that much of the world's most popular software still uses it - OS X, Facebook, Chrome, MapReduce, Windows 7, Firefox and MySQL to name just a few
People now need to be /told/ this stuff? Oh gawd I'm feeling old.
Worrying I actually do struggle to understand the main thrust of the article. Something to do with cloud computing and scripting, eh? Wow. What will these whipper snappers think up next?
Yes, us youngsters have to be told facts to know them...
But now I have to be clairvoyant about existing large-scale software architectures and their programming environments? Get to ****
Lol, at least you didn't down vote me. It was sort of a joke but it also has a serious point. I've been involved in IT as a software developer for 25 years now. For most of that time I've understood everything and it's all made sense. But over the past five years I've noticed that some technologies are appearing that seem to be unusual. Things that don't quite make sense.
It's probably something everyone goes through (my Dad gave up on computers when microchips started to appear). The serious point I'd like to make though is that there comes a time when the older generation do start to lose touch. I wonder if there's scope for an El Reg article here?
A related concern here is that, yes, C++ is still important. CPUs are important. OSes are important. 'The Cloud' is a cool concept but the up and coming IT generation is going to have to understand and support 'old school' tech. You can't operate a cloud without understanding assembly language. Not long term anyway :)
Speaking as a C++ developer I do wish they could just leave well along. The language is complicated enough already - if I need any more meta style programming there's Boost. All they're doing is creating more potential obscure questions to be asked in job technical tests.
"C++ developers no longer have to build or pick their own libraries to achieve concurrency in C++ applications."
What??? There is already a standard threading library - its called pthreads! Its not hard to use for any half decent developer and what happens if I don't want multithreaded but want multiprocess - has it got a wrapper for fork() (which Windows doesn't even support) and shared memory, semaphores, message queues, pipes, fifos, sockets, signals? No? Why not? Either do it properly or don't bother. C++ should be a language , not an enviroment.
Yet another half baked chuck-in-everything-thats-cool proposition from a committee that really needs to find something more productive to do with its time.
Speaking as a long-time C++ developer, I have to agree about the half-arsed concurrency additions to C++11. The only thing that actually needs to be supported by the language, in my opinion, is atomic operations and well-specified barriers so that we can write such code in a portable way.
But other than that, most additions to C++11 are quite welcome. I won't name them all, but things like type inference, lambda functions, constructor delegation, as well as the STL cleanups and improvements, were long overdue and really make the language much nicer.
Still, won't beat Lisp anytime soon.
Re: Re: C++11
There is a huge amount of C++11 which I am really looking forward to. Of course, the nice thing is that everything is pretty well backward compatible, so the reality is, if you want to like in your C++98 or C++03 world, you can remain there. Personally, for me, one of the biggest things that will improve life is in the space of move constructors and all the spin-off stuff from that. Being able to do the following without a tonne of temporaries slowing everything down is huge:
MyComplexType a, b, c, d, e, f, g, h, i;
a = b+c+d+e+f+g+h+i;
Small things like type inference and initialiser lists will make using boost and the standard library much nicer. I could go on, but I won't. Just suffice to say I'm looking forward to it.
"What??? There is already a standard threading library - its called pthreads! "
Really, and I assume that pthreads is platform independent? I assume it works on Windows (pthreads-w32 is a poor substitute), and on embedded systems - both huge areas for C++. The lack of a memory model has been one of the biggest issues with C++ since its inception. It leads to inefficient threaded code, and it leads to broken threaded code, especially since C++ allows access through to the assembler so many more people are using native compare and swap in their code. Having memory barriers and atomic operations in the core language is huge.
Re: Re: C++11
"Really, and I assume that pthreads is platform independent?"
Frankly who cares. If you're coding in C or C++ then you're going to be using OS specific APIs at some point anyway. Thats where #ifdef's come into their own. And if you don't want those then thats what Java was invented for.
Utter bollocks. If your memory management causes threading issues then you're doing it wrong. Personally I'd go for multiprocess anyway, you all the benefits of multithreading without most of the problems. (It has a couple of its own but nothing significant). But oh dear, Windows doesn't do multiprocess very well does it. Too bad eh? I won't be ditching fork() anytime soon just on the off chance someone might need to port it to a Microsoft platform.
OpenMP offers language-level multithreading. Shame it doesn't really catch on because for simple parallel tasks it is way less code than 'proper' threading libraries.
I think it's the lack of libraries and frameworks that stop software houses from adopting new languages. No-one's interested in producing these for node.js because no-one is using node.js apart from in specialised, high-concurrency apps which need to cram in as much functionality into as few server resources as possible... which don't need bloated frameworks and libraries.
For the beginner or intermediate developer - which these days, is about 99% of the developer population - doing things raw means doing things wrong, and that's why they'll stick to Apache and PHP.
thanks guys but think I will stick to VB.NET
99% of the situations don't require node.js - I had a customer where Cisco ACE was not performing well (it was kicking users off for no apparent reason)
I coded a loadbalancer using php, apache and mysql and it is working very well now for over a year now.
Why would I want to even go there, re-learning a new framework, new tools, new webservers (node.js can't work on its own, it needs some other kludge of servers for production) it just doesn't make any sense to me.
A correctly configured installation of apache, mysql and php works well enough for anything you can throw at it - you can even have in-memory variables shared between processes using apc or memcached if you really need high performance - and for the most part mysql is fast enough since immediate queries are cached in-memory as long as you have configured it correctly.
Yes, I suppose so. Your "production environment" wouldn't be an Acer laptop running in your cellar hanging off the fridge power strip and pumping bad early-2000 websites with blinking gifs to innocent punters?
Ohh, you're so clever..
No, actually you are completely wrong, its running a state of the art AJAX-intensive customer management system with datagrids, trees etc. on high-end servers.
This is just the sort of idiotic comment i've come to expect from lame internet trolls like yourself.
Just for the record, you were probably not even working on the internet pre-2000, and were still in your nappies.