Ask Slashdot: Node.js vs. JEE/C/C++/.NET In the Enterprise? 304
theshowmecanuck writes "I'm working at a small- to medium-sized company that creates software for mobile devices, but came from a 'large enterprise' world before. I see node.js being used increasingly in smaller companies (including ours) or in web/mobile related software. Meanwhile we see languages like Java/JEE, C/C++, and .NET continue to be used for medium-to-large enterprise corporate software. Compared to the status quo in the enterprise (JEE/C/C++/.NET ... and yes, maybe even COBOL) maybe Slashdotters can chime in on how they see Node.js in this role. I'm thinking of things like complexity of business logic (dependencies, workflows, linear processes, etc), transaction support (for processes in general and database support), messaging services, etc. Also, what is the state of Node.js in terms of paradigms like application containers, where much of the 'plumbing' is already set up for you (one of the main benefits of JEE application containers)? But there is also the question of maintainability, deployment, and ongoing operations. What say you, Slashdot?"
Who you gonna call? (Score:5, Insightful)
Re: (Score:3, Insightful)
And when your Java application goes to shit you're going to call Oracle? Reality is that for enterprise code it's more about longetivity than anything else (no "ancient VB6 app nobody knows how to touch anymore") and by the looks of it Javascript is here to stay. Sure sounds a lot better than many of the other fads out there.
Re:Who you gonna call? (Score:5, Informative)
That's much less likely to happen with Java apps. skovnymfe's point (since it flew way over your head) was that node.js is not backed by a big company so if you're doing important development you probably would want to use something safer.
Re: (Score:2)
Re: (Score:3)
Being a mature language, it's not that hard to find a Java developer. With enterprise software you have to think about language features and support staff turnaround.
You lost me on that one. Java was first released in 1995. Node.js is about two years old and is still at a 0.10 version release. PHP, Ruby, Perl, and Python all have longevity and developer base supporting them
Re: (Score:2)
Re:Who you gonna call? (Score:5, Insightful)
First you chose the right tool for the job at hand. node.js is not intended for serious number crunching, but neither is Java or .Net. If you need multi-threading in node.js you are doing it wrong; node.js efficiently handles many thousand parallel executions, in one thread. Node.js is very efficient at waiting and reacting to input. One node.js instance can get up to 99% on one CPU core, something that is really hard with a Java or .Net application that happens to do I/O. If your needs extend one core you can always use cluster and thus spawn multiple node.js processes working the same program. node.js is awesome, since in almost all applications this approach results in a very easy solution to scaling out.
So far with npm, I have found everything I can possible want under the sun and all with permissive licenses, such as MIT. I don't see the issue here.
Finally if you really need the raw power, use C or Fortran, seriously. Java and .Net are the last places to look for performance.
Re:Who you gonna call? (Score:4, Insightful)
Finally if you really need the raw power, use C or Fortran, seriously. Java and .Net are the last places to look for performance.
actually the > 1.6 incarnations of Java are fast and only getting faster, and there are real time implementations of the JRE if you really need them. As far as "power" (however that is defined), folks are doing some really interesting (especially in the news lately) things with large data set analysis and manipulation with products like Hadoop.
Re:Who you gonna call? (Score:4, Informative)
Re: (Score:2)
Re: Who you gonna call? (Score:3)
Re: (Score:2)
You're pretty ignorant. If you measure "performance" by checking how high you can get the graph in the task manager, trust me, I can cap out as many CPU cores as a machine has, and do a lot of I/O simultaneously, in Java or C#, and I can do it trivially.
Furthermore, thanks to the JIT compiled nature of Java and C#, number crunching is just fine on these platforms, thank you very much. Even in the early days, right when .NET came out, it was fine. We ran a simple number-crunching test, calculating Fibonacci
Re: (Score:3)
Re:Who you gonna call? (Score:5, Informative)
You obviously do not know about Java.
Since others have addressed other points, let me touch some not yet mentioned.
There are production servers running Java workloads with heap sizes in the tens or even hundreds of Gigabytes of memory, with 10 millisecond GC pause times. I mention that because someone always brings up GC. But JavaScript (node.js) has GC, so instead I'll ask whether you think node.js garbage collector can do that?
The JVM (java virtual machine) is one of the most amazing pieces of software engineering on the entire planet. It has some of the most sophisticated code ever written. It's JIT is an amazing dynamic compiler whose source language is the JVM binary code emitted by the Java compiler.
Now, imagine if your node.js could do this.
The VM notices that a particular function (A) is getting more than it's fair share of CPU, so the JIT compiles it to native code. During compilation, if function A calls function B many times, such as in a loop, function A may inline function B.
Now, on the JVM you can dynamically replace and reload binary classfiles in a running system. So suppose the binary file containing function B is reloaded. But now the compiled version of function A has inlined an out of date function B. No problem, the JVM ditches the compiled version of function A, and very shortly, based on real time continuous performance monitoring and statistics, it will notice that function A deserves to be compiled to native code, and repeat the whole process.
The JVM is perhaps one the best runtimes available for many different programming languages. It provides a huge number of highly evolved services right out of the box. GC. Binary portability. Native compilation at runtime, thus making the JVM bytecode portable. Choice of GC algorithms. Choice of JVM vendors, including ones with real commercial support for your Billion dollar business application. Remote monitoring tools and consoles.
Pick the right tool for the right job.
Re: (Score:3)
Modern Javascript environment have JIT compilation and GC as well. The performance is not going to be as good for several reasons. But JIT is not a Java specific trait.
Re: (Score:2)
Unless of course you're sitting on a 100+ strong team of developers capable of forking the project off in the direction you want it to go, and then maintaining it for you. But then it's not really node.js anymore, is it?
Re: (Score:2)
you're not gonna call anybody except your own guys. you can contract companies for node.js if you think that covers your ass.
and an answer to the plumbing question.. go check npm. plenty to choose from and that's maybe the problem, but there's plenty of different so called plumbing solutions should you need one. it's farm more likely that node.js just plays a front end role in any large solution and linear backend stuff that takes longer time etc happens elsewhere - or perhaps in another spawned node.js.
nod
Re:Who you gonna call? (Score:4, Insightful)
And when the Oracle .net driver goes to shit, who you gonna call?
Hint: Microsoft and Oracle will blame each other and it'll take six months to get a fix. My day job is dealing with both of them, and it does happen sometimes. I don't care for node.js much at all, but the idea that it's somehow inherently more dangerous than stuff from big companies is just nonsense.
Re:Who you gonna call? (Score:5, Insightful)
WTF are you talking about? Oracle .net driver? You mean you're using .net with an oracle database instead of mssql? Well there's your problem. M$ doesn't like other databases except theirs.
Re: (Score:2, Interesting)
He's probably talking about the .NET connector which allows Oracle databases to be consumed by .NET framework features like the EF or to integrate with tools in visual studio.
But either way what he says shouldn't ever happen. The .NET connectors don't just randomly break unless you upgrade to a version that's broken. If you test and integration test and everything works then don't upgrade without regression testing. If you upgrade and don't regression test and it breaks then it serves you fucking right.
The
Re:Who you gonna call? (Score:5, Insightful)
Yes, because there's never been a bug that manifested in some weird situation after everything had been live and working for months. Nope!
Re: (Score:2)
It's not like database communication is the sort of thing that's not well understood and isn't fairly easy to build a solid test suite for. It's even easier for the consuming developer to test their own use of the even smaller subset of the features their product requires too.
So yes these sorts of things tend to be extremely unlikely to result in bugs that just pop up out of nowhere. Where it is a possibility the occurrence is so small as to not be a factor in overall language/technology stack choice becaus
Re: (Score:2)
Re: (Score:3)
It seems like a half-ass attempt at best by Oracle, though it's been getting better since Microsoft quit supporting the Oracle drivers themselves. You still have to install the fairly unwieldy Oracle Client on all front end servers to access the database (though I believe they are working on a portable library). The ODP.net client doesn't do automatic cursor mapping, and if you want to use it, Oracle seriously recommends to hand/hard code into your base configuration file xml mappings for cursor return t
Re: (Score:2)
Re: (Score:2)
Nope. They haven't. the .NET data layer is still coded around concrete classes mostly and the APIs have many less features than JDBC.
Re:Who you gonna call? (Score:5, Informative)
I reply to you, not the followups that are similar brain dead.
What is node.js? It is a server software you can download.
Then you have a bash script and some config files to start it. And perhaps a book from O'Reeilly.
When you write your code against it, you figure if it is "good enough" for you.
When you deploy it in your enterprise you very likely consider to stick stable to the current version/release for YEARS.
So, meantime node.js is no longer maintained. WHO CARES?
You stick to your old version, and you are good. If you need new features that belong into node.js and not into your software you hire one for it. Or you write it yourself.
BTW: do you really believe if it is no longer maintained it won't become an Apache project?
What about all the other software out there that once was open source and was used by enterprises and is no longer maintained? I never heared about a company going bankrupt because of this.
Re:Who you gonna call? (Score:5, Insightful)
So, meantime node.js is no longer maintained. WHO CARES?
You stick to your old version, and you are good. If you need new features that belong into node.js and not into your software you hire one for it. Or you write it yourself.
And then you get hit by a vulnerability.
http://blog.nodejs.org/2012/05/07/http-server-security-vulnerability-please-upgrade-to-0-6-17/ [nodejs.org]
Re: (Score:2)
Yes, and then you fix it ...
Vulnerabilities can happen in any product.
I rather fix such bugs myself then have to wait months for Oracle or whom ever.
The point was: who cares if the original developers no longer exist or maintain it?
No strategy can keep you "safe" from that.
Re: (Score:2)
guess which one has had more serious vulnerabilities to date? you guessed it, java.
you guys are idiots.
Of course, they were all security problems with the Java browser plugin, which in no way would have any effect on server-side java, or any Java use case similar to Node.js. Reality....
Re: (Score:2)
Re: (Score:3)
About the only company that vaguely impressed me with their support was Sun in that if one of their machines died they bent over backward to get it working again. In one case they sent a guy in to swap out a
The project list, or ANY c++ programmer on the pl (Score:2)
That's why node.js isn't for enterprise use.</quote>
If Java has an issue, ONLY Oracle could address it. If they don't care to fix it, you're fucked.
Node.js, being open source, could be fixed by the current project team, or any C++ progra
Java maintenance stops when Oracle's suits decide they have something better to do.
Node.js maintenance
node.js has a very serious issue (Score:5, Insightful)
Re:node.js has a very serious issue (Score:4, Informative)
node.js is strong when you don't actually necessarily want nginx or apache sitting in between. for web services and alike it's nice. for serving the actual site you might want to go with nginx.. as for serving, it doesn't exactly do all that much so there isn't that much to configure or iron out.
Re: (Score:3)
That's essentially what node.js does.
Re: (Score:2)
Except that it leaves you stuck with javascript, while libmicrohttpd is in C, which means both much better performance, and access to some of the largest and best-tested libraries in the world to create the rest of your app. And, of course, C also allows you to embed perl, python, ruby, lua, tcl, and even, yes, javascript, in your app as well. Heck, even more than one of those, should you be so inclined. In fact, a C library opens you up to using just about any language you can imagine, compiled or interpre
Re: (Score:2)
Node.js supports the use of addons written in C/C++.
Use JS for libraries that are shared between client & server (e.g. HTML templating) and for logic that changes frequently or needs to be accessible to dedicated front-end devs (e.g. request routing). Use compiled C for code that needs to be extremely fast &/or robust (e.g authentication & creation of dynamic resources).
Here's a handy example addon from the node.js docs:
http://nodejs.org/api/addons.html [nodejs.org]
Re: (Score:2)
Re: (Score:3, Informative)
Re: (Score:2, Insightful)
IBM HTTP Server comes bundled with all versions of IBM WebSphere, and really, it's just Apache. So yeah, in our world free software is indeed used in the Enterprise (or: 'commercial http servers'). In OS-space you've got RHEL and Suse Linux Enterprise, at the very least.
In some cases, even in Enterprise solutions, it does make sense to use free software rather than roll everything in-house, especially when http-serving is not really your core business model.
Re: (Score:3)
Agreed. In enterprise it's not what you bought which determines support, it's who you bought it from and for how much.
Re:node.js has a very serious issue (Score:5, Insightful)
I'm not really a fan of node.js (because it's redundant) but I think you misunderstand the point of node.js. If you're reimplementing a full fledged HTTP server with it then you're really using it wrong because it's not meant for tasks that heavyweight and really uses a different request processing model than that.
But I take issue with it because even in that role you can configure technologies like IIS, various JAS' and WCF to work in pretty much the exact same manner but with the benefit of being able to use languages and tools more well designed for large scale development on top whilst also having the benefit that these technologies automatically scale better than node.js and perform better to boot. WCF for example can be run in single threaded mode but such that it automatically uses a thread per core or processor, whilst with node you have to set up clustering to make it do this. Most of node's advocates make inflated claims of it being better than these sorts of server products for no other reason than they are inexperienced with these products and don't understand them and their flexibility.
Effectively node.js allows inexperienced developers to do something that people who understand IIS, many Java Application Servers, WCF, or even raw sockets programming have already been doing for many years already.
So to answer the OP's question I think as I say that in the enterprise node.js is really quite redundant. It doesn't do anything that can't already be done with better performing, more tried and tested, more scalable more enterprise friendly technologies already.
Effectively it's become popular because Javascript developers have had to start working on the server side and it's an easy jump for them, but what server side developers already have is much more secure, much better performing, and much better for development.
About the only valid argument I've heard for node.js is it means you can share code between server and client and write once as a result, but I'm not sure how useful this is in practice given that you'll normally be doing different things server side to client side and hence having different data structures and processing needs anyway. Technologies like Java and .NET make serialisation/deserialisation to/from JSON happen automagically anyway so it's not as if getting data structures between the two is any kind of chore.
If you already have server side developers who know their stuff then use them and don't waste your time with node. If you only have Javascript developers then use node.js until you can't. I say can't because Javascript's language design and node.js' limitations do make it increasingly more difficult to write anything of any real complexity after a point whereas C, C++, Java, C# all allow a much greater degree of scalability. It all depends on what developers you have currently and how far your needs are going to scale as to whether the deficiencies of node.js and Javascript will become a problem.
Re:node.js has a very serious issue (Score:4, Informative)
As the AC said I'm talking about code scalability - the ability for a codebase to grow without becoming unmanageable. This is difficult to achieve with Javascript because it's prototype approach and lack of decent support for things like namespaces, libraries and so forth coupled with the inherently greater difficulty of capturing many classes of bugs in a dynamic language and Javascript in particular means it's a nightmare getting a Javascript codebase to scale beyond a point when compared to something like C#, Java, or C++.
Re: (Score:2)
Python scales pretty well to a medium size codebase (Java scales better to a large codebase than anything I know of - old-school Java may have been painful to develop in, but this it did well).
Javascript doesn't really seem to, at least with most common tools (if you move to using Typescript and the like, it may do a better job). However, Javascript has nowhere near the level of library and tool support for non-web-browser-based tasks that a mature platform like Python has.
If you just need to do very simpl
Re: (Score:2)
That is exactly the problem that Phusion Passenger [github.com] solves. It is a Node.js application server, built on Nginx, and not only provides world-class HTTP management but also things like auto-scaling processes, supervisoring, load balancing, resource management, etc.
Re: (Score:3)
the thing with node is that it can handle things that your server can't necessarily handle. Things like websockets and server sent events. If you were to build a site that needed websockets for real-time feeds using traditional technologies (like php + apache), you'd wind up with apache having n open connections with n instances of your application loaded into memory. The power of node.js is the fact that a single instance of the app will stream content to an arbitrary number of clients with a single instan
Re: (Score:2)
Re: (Score:2)
An Enterprise should be using an ESB from someone like Tibco. Then they should have a heterogenous set of apps that publish endpoints to that ESB. Some could be Java backed, some .Net, some Node/Python/Erlang or straight C/++ (throw some COBOL or Haskell in). These apps should subscribe to each other as needed for data interchange.
The client apps used for managing and reporting can be anything at this point. Node would be just fine for a web based GUI. It loves to consume endpoints. Sockets, REST, streams -
I think... (Score:5, Interesting)
My oppinion is that Javascript is not bad as a scripting language, but we are abusing it and twisting it beyond its original purpose. The main issue is actually that Javascript is too flexible. Untyped code has an habit of hiding mistakes in hard-to-debug ways. But once you add types to Javascript, it's not Javascript anymore.
So, if you are working on a "pure" Web App, and you want to use one common language for the client code and the server code, then go on, use Node.js, add some packages for web services, database access, etc. and get it done. But if you want an environment that detects the mistakes as soon as you type them, runs relatively fast, can be statically verified, and still manages to keep a decent amount of flexibility, then there's nothing that compares to C#/dotNET.
I can not speak about anything more enterprise-oriented, but I assume the more oriented something is, the more rigid it becomes at thinking anything out of it's "ruleset" must be a mistake.
C++ is what it is. It's fast, mature, complicated, and flexible. If you want something done ASAP, don't use C++. If you want the result to be easily portable to other platforms, don't use C++. If you want the code to be safe (against hacking) without much effort, don't use C++. If you want the code to be easy to maintain, don't use C++. But in the end, it's your choice.
Re:I think... (Score:5, Informative)
Well, obviously the right answer for the OP depends on precisely what he wants to do. That notwithstanding...
C++ is what it is. It's fast, mature, complicated, and flexible.
Going for the less mature end of things, C++11 is now pretty much done (GCC has almost full support, LLVM is close and amazingly even VisualStudio has most of the goodies).
It also ain't you father's C++.
It has taken great strides in the areas such as making the safe thing easier and quicker to write and generally less hassle and less faff all around. Additionally, the quality of implementation of things like the standard libraries has improved beyond measure. In the areas of security, other than making the secure things easier to write, between address space randomization, getting GCC to instrument pointer accesses and the NX bit, the space for exploitable (but not obviously DOSable) holes has shrunk considerably.
C++ has changed immeasurably immeasurable since what was practical in 2003. That's not to say of course that C++ won't let you do bad things. Of course it will. But they're not all the easiest way of doing things now :)
Still, like any material (I have seen an excellent argument that languages are more like materials than tools) one has to choose an appropriate one for a particular job. Given that I can't really tell what the OP is trying to do, it would be hard for me to commit to a given language...
I'm not going to claim C++ is simple. That would be silly, but a rather fun fact is that the despite Java being promoted as simpler than C++ for so many years, the latest Java language spec (excluding libraries) is shorter than the latest C++ spec (excluding libraries).
Re: (Score:2)
My oppinion is that Javascript is not bad as a scripting language, but we are abusing it and twisting it beyond its original purpose. The main issue is actually that Javascript is too flexible. Untyped code has an habit of hiding mistakes in hard-to-debug ways. But once you add types to Javascript, it's not Javascript anymore.
A couple of points. First, the argument you're making is for static -- i.e. compile-time -- semantic checking. I was hearing the very same argument thirty years ago among people who advocated Pascal over C; on paper it's sound, but decades of practice have convinced me that static checking, while probably helpful, is not as efficacious as it seems like it should be. After all, you *still* run into mishandled exceptions in Java, and many Java programmers do an end-run around around much of the compile-time
Re: (Score:2)
My oppinion is that Javascript is not bad as a scripting language, but we are abusing it and twisting it beyond its original purpose.
I actually agree with this statement whole-heartedly. However, I can't help but find it amusing that you immedately go on to propose using one or more of the modern updates to C, Ken Thompson's slightly higher-level replacement for PDP-7&11 Assembly language [wikipedia.org].
Re: (Score:2)
I hate JavaScript but I've been using CoffeeScript for a project and I've been reasonably impressed at how it removes many of the worse parts of JS - how does TypeScript differ/improve on Coffee?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Why is mono dead on Linux?
Re:I think... (Score:4, Interesting)
Re: (Score:2)
Re: (Score:2)
I have been using .NET for several years and Visual Studio doesn't hold a candle to IntelliJ. You can't even do continuous integration with .NET. Visual Studio stores each project file separately in the "solution" so you have conflicts all the time. It doesn't help that the VS merge tool is brain dead. It's pathetic that we have to work with such garbage from a company like Microsoft.
Re: (Score:2)
We do CI with C#, using TeamCity. I don't know what these "conflicts" are that you see all the time, but perhaps you're the problem?
Re: (Score:2)
C# is an ok language, but the lack of checked exceptions make it harder to write high-stability software.
Re: (Score:2)
There's a million of them. Take your pick. Or, you could just write maintainable/testable code without relying on some jackass' DI "framework".
Re: (Score:2)
Er, no?
Re: (Score:2)
http://helpdesk-software.ws/it/29-04-2004.htm [helpdesk-software.ws]
Re: (Score:2)
Wow. Perhaps you should find some newer material dated after .NET reached version 1.1 (hint: It's at 4.5 now, nearly 10 years later)
Errmmmh ... what was your question? (Score:5, Interesting)
Sorry, your rambling - that is supposed to be a question I presume - is a tad incoherrent. But I do think I catch your overall drift, so I'll chime in:
I think the overall issue is basically about programming languages. Wether it's some software runtime enironment or the other - in the case of JS Node.js just happens to be the first to revive JS on the serverside.
To the case: .... ok, scratch that. Take for instance PHP. PHP was a joke when it becam popular. 2 guys had a thing called Zend engine and they decided to craft it around a Perl based templating "language" that was becoming popular - mostly because Perl is quite bizar to handle and it was the most popular web scripting language back then. They built PHP 3 based on the zend engine, then a mod-php was added for the popular webserver Apache and the rest is history. All things went web, as a result we have PHP pissing into serious Java territory today. I remember when PHP was a joke and JSP seemed to be posed to rule the webworld for decades to come. That didn't happen, mostly due to political reasons. ...
Wether or not a PL takes over is dependant on things that usually have nothing to do with the PL itself. Once a PL is sufficient enough
Had Netscape released their webserver as FOSS back in the mid-90ies, we'd all be using JS as serverside language ever since, since JS was the serverside language on the Netscape Enterprise Server.
I think compiled languages are impractical for web environments, for reasons everyone can come up with, so that rules out C and C++. For every environment that is set up from scratch I can't think of a single expert that would recommend .Net. .Net exists because it banked on the existing Windows/MS legacy. The MS CLR may be a neat feat, but it is a MS lockin trap, and today it's mostly pointless, since abundant server power, virtualisation and simular things have made optimisation concerning multiple runtimes on one setup a non-issue.
This leaves us with JIT/bytecode compiled or interpreted languages. Here I see Java vs. all the rest (Python, PHP, JS, Ruby, etc.). It's basically Java vs. FOSS languages. Java *is* a FOSS language by now, but the problem is that Oracle is a very bad herald for FOSS Java, and the FOSS alternative, OpenJDK/SDK is bad/slow.
For the future of web I do see Node.js gaining lead position. Google put serious cash into aquiring V8 technology, improving it and putting it into Chrome. Flash was killed by Steve Jobs/iOS, pushing brilliant no-Flash-allowed devices (iPhones and iPads) into millions of end-user hands, so Google had to come up with a serious alternative. Hence JS/V8.
Not being stupid - selling software is *not* Googles business - they released the impressive V8 engine as FOSS, and some smart people put in the effort to port that engine to the serverside, where it is about to kick PHPs and Rubys ass, simply because it's at least as good as either of those *and* it is the same primary non-lockin language on the serverside as is on the clientside. Mind you, clientside JS only became popular once a guy wrote a famous blog article [adaptivepath.com] in which he renamed "doing important smart things with JavaScript" into "Ajax", which is a cool name and thus made JS on the clientside popular with a lot of people who formerly had no interest in looking into JS seriously. We have the same effect when some smart guy decided that plain Java objects weren't used and other things like EJBs were more popular simply because regular Java objects didn't have a cool name. So he named them Pojos (Plain Old Java Objects) and solved the problem. Any serious respectable Java toolkit today uses Pojos at its heart.
Bottom line: Wether a tech or PL catches on, gains traction and becomes the next big thing is usually rooted in issues one would not think as relevant right away - things like 'Does the tech have a cool name?', among others. That sa
Re: (Score:2)
If the question is about languages?
maybe the question is about frameworks instead. A framework is a set of libraries for a certain language. E.g. The language is java, the framework is J2EE. .Net is not a language, but mulplie languages can use the .Net framework.
For C/C++ the question leave it open, but i think C/C++ should be mainly used for support/intermediate software, and not for the business logic.
Node.js is not a complete framework, you need to add things to make it complete.
In a enterprise you hav
Compiled languages (Score:2)
"I think compiled languages are impractical for web environments, for reasons everyone can come up with, so that rules out C and C++. "
Yes - C & C++ are complex, hard to learn and require a deeper understanding of a computer than browser documents, which pretty much rules out web "developers" being able to use them. Is that one of the reasons you were thinking of?
Re: (Score:2)
Hey not all of us are bad, I'd say I'm a "web developer" because it's mostly what I do, but I use C/C++ for some server products because when performance and flexibility matters it's not like I'm going to use a toy such as node.js.
I absolutely agree with you and think node.js is redundant for this very reason, everything it does can be done in languages like C and C++ and in fact if you want to do anything that requires performance you have to drop back to C with node.js in the first place which begs the qu
Re: (Score:2)
"Web developer" has a stigma due to the early days of people learning HTML and using FrontPage and comparing themselves to people who actually used a programming language. I think the fact that web applications attract the most new people is why this stigma still exists. Who knows? I generally tune it out and judge people by their ability not by their chosen specialization.
Re: (Score:2)
Yeah to be fair there's some truth to it, if anything the reason I do know languages like C, C++ and so forth is because I come from a desktop and server background as opposed to web. I do find a lot of developers who have done nothing but web development all of their lives do seem to be extremely low calibre.
Re: (Score:2)
Sorry, your rambling - that is supposed to be a question I presume - is a tad incoherrent....
Wether or not a PL takes over is dependant on things that usually have nothing to do with the PL itself. Once a PL is sufficient enough .... ok, scratch that...
Re:Errmmmh ... what was your question? (Score:5, Informative)
What's the V8 Javascript engine written in?
'nuff said.
Code it in C or get out of the way and let a real programmer finish the project.
What does the machine actually execute?
'nuff said.
It depends on what you have and what you need (Score:5, Insightful)
The short answer is: it depends. The longer answer is slightly more complex. It depends on the problem you have, the knowledge of your programmers, and the server environment you'll deploy.
If most of the developers in your house are web developers, and have extensive knowledge on JavaScript, then node seems to be a more organic solution. However as others pointed, JavaScript has been abused to code everything from databases to ray tracers, but you should keep real world performance in mind. For most tasks node (backed by Google's V8 engine) will be 2x to 10x slower than an optimized C/C++ program in the real world. You're basically trading developer performance for runtime performance.
Additionally using a dynamic language, especially modern JavaScript requires discipline. If you do not have a proper packaging or testing systems you'll run into problems. Fortunately node community already prefers doing things the modern way, so this should not be a concern for most (sane) people.
On the other hand, one should never discount the performance benefits of C++. For our latest project we converted one of the smaller, but very CPU intensive services from PHP into C++. This offered an order of magnitude performance increase (going from a minute to a few seconds). So use your common sense, and all available tools on hand depending on situation.
As for Java, and C#, you'll have a performance similar to C++ (same to 2x slow), as long as you have sufficient amount of RAM (a recent paper I read cited 6x RAM requirement for a GC to function properly). The only concern is that for C#, you'll most likely want to stick to Microsoft ecosystem (Visual Studio is a great development environment, but you'll have to deploy to Asure, whereas you have more choices with Java, including Amazon and Google Linux clouds).
The bottom line is: look at the task at hand, and the people you have to choose the tools. And do not be afraid to experiment -- especially early on in the project.
Re: (Score:2)
GC = Garbage Collection? Six times the RAM req's?
Sounds high but possible, can I get a link or citation on that article? Sounds like a decent read.
Re:It depends on what you have and what you need (Score:5, Informative)
The paper is at the following link: http://www-cs.canisius.edu/~hertzm/gcmalloc-oopsla-2005.pdf [canisius.edu]
I ran into it while reading the discussion at http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ [sealedabstract.com]
Re: (Score:2)
Re: (Score:2)
Overlapped I/O (or, on Unix, AIO). Learn it. Live it. Dedicating a thread to each open socket is the most brain-dead way to implement a system. It's like bubble sort for sockets. It's simple, it's easy, it's what the noobs do the first time around, but it should never, ever, be used in a system that requires performance.
By the way, C# supports asynchronous I/O using completion ports (on Windows). I don't know for sure if Java does, but I think NIO.2 might.
Re:It depends on what you have and what you need (Score:4, Informative)
> The only concern is that for C#, you'll most likely want to stick to Microsoft ecosystem (Visual Studio is a great development environment, but you'll have to deploy to Asure, whereas you have more choices with Java, including Amazon and Google Linux clouds).
Err what? You can deploy to hundreds of hosting providers... including AWS.
http://aws.amazon.com/windows/ [amazon.com]
Re: (Score:2)
but you should keep real world performance in mind. For most tasks node (backed by Google's V8 engine) will be 2x to 10x slower than an optimized C/C++ program in the real world. You're basically trading developer performance for runtime performance.
It's been a long time since the execution speed of the program was the bottleneck in web programming. Generally the thing that causes performance issues will either be network latency/bandwidth or database issues. The speed of the compiled code can be solved by adding a few more servers, and you will have a lot of servers before their cost is more expensive than the cost of a single developer you would have to hire to take care of C++ issues.
Re: (Score:2)
6 times the RAM required for a GC to function properly? Over what? Just how, exactly, is malloc()/free() not a garbage collector? It serves the same purpose, it simply requires more handholding to do so.
Application for mobile devices? (Score:3)
Is the application you are mentioning runnint into the mobile device? Or is it a web application for mobile devices?
In the former case, I think you need to stick with the device architecture constraints, like ObjectiveC for Apple mobile stuff.
In the latter case, the choices is up to the developer team and what they know better.
I would personally choose C++ with Wt [webtoolkit.eu]. But that's just me.
So, please, explain better your problem.
The Enterprise (Score:2)
I'm pretty sure the Enterprise doesn't use JavaScript. It either uses C or a Starfleet-specific language.
I only see one majour problem/challange (Score:2)
Node.js is a JavaScript platform. So you need languages that ultimately compile down to JavaScript (like CoffeeScript, or you can abuse the GWT compiler and use Java).
The problem with JavaScript is weird syntax for real oo programming on one side and dynamic typing on the other.
Dynamic typing means you have to have a very gout test harness and really unit test nearly everything.
I also would not wonder if you might get into new security risks. After all the server is a bunch of not compiled text files ... If
LinkedIn uses Node (Score:3)
LinkedIn Moved from Rails to Node: 27 Servers Cut and Up to 20x Faster http://highscalability.com/blog/2012/10/4/linkedin-moved-from-rails-to-node-27-servers-cut-and-up-to-2.html [highscalability.com]
Having said that, I've started using Node in a limited way and it is obviously immature. NPM is a mess. There are far too many almost the same packages, and no obvious way to choose between them without reviewing the code. A package may not be compatible with the latest release, but there is no way to tell without installing it to try it out. These are signs of a still evolving ecosystem.
Still, it's only a matter of time until the rough edges are smoothed out and Node becomes accepted as a legitimate server side alternative.
Re: (Score:2)
A package may not be compatible with the latest release, but there is no way to tell without installing it to try it out.
This is the first thing I ran into as a newcomer to Node. Not just packages but programming techniques. You're trying to learn how to do something trivial for the first time, so you hit Google and then drop into Stack Overflow and find plenty of questions and answers about your very problem. Then you try to use the solution and it falls apart. That's when you look back through the comments and you discover, "Oh yeah, I wrote that answer / released that package for Node 0.4.x: it really doesn't work anym
Re: (Score:2)
LinkedIn uses it for their mobile backend.
But I more than suspect that the mobile backend is just a simple frontend to the real backend. And that is written mainly in Scala.
As far as I know the closest thing to node.js in Scala would be something like Finagle, which they use at twitter:
http://twitter.github.io/scala_school/ [github.io]
For my current hobby project the backend is written in Scala, Akka and Play! - though I am considering replacing Play with Spray, since all the backed does is serving JSON from REST servi
My 2 cents on Node.JS (Score:2)
What I'm saying for long term support you'll need to roll most of your own code. Pulling in external modules may be slow because of the lack compiled code. Don't expect much from third party libraries. I've only bee
Re:My 2 cents on Node.JS (Score:5, Informative)
http://en.wikipedia.org/wiki/V8_(JavaScript_engine) [wikipedia.org]
I know that facts are not fashionable on Slashdot, but please make the minimum effort for a reality check before you mindlessly repeat whatever drivel you've been listening too. I don't know about the Python requirements, but given your misinformation about V8 you are most likely wrong about that as well.
Re: (Score:2)
Also, Python (the language) is for people who didn't think VB's whitespace-significant syntax went far enough.
Huh? (Score:2)
I think you're jumping on the Node.js bandwagon without understanding why.
Node.js is a good asynchronous server, like Tornado (written in Python). However, it sounds like you are writing a backend for a RESTful (mobile) web application. Web is rarely asynchronous and has no special benefits from using an asynchronous server. You will not be more scalable just because you choose Node.js as your platform.
However, if you're excited about JavaScript on the server -- wonderful, because you get to use the sam
Throw Angular in the Mix? (Score:2)
I've been primarily working with XML databases (eXist) on the back end the past several years. But the need for doing more client-side work (via JavaScript) has been increasing. Having dealt with Microsoft's weekly build breaks in IE 4 (I seriously had a list of build numbers from each week that different customers installed IE and a different aspect of my web application broke), and their inability to follow the ECMAScript standard, I've gone very grudgingly back into the whole build apps with JavaScript
JavaEE : Node.js :: Apples : Oranges (Score:3)
You're asking for the classic apples to oranges comparison here.
Node.js is all about scaling the number of requests/second -- about minimizing the number of boxen you need to serve thousands of requests per second. By using polling instead of threads (under the covers) and asynchronous event handling (above the covers), it becomes simple to respond to high volumes of requests without allocating huge volumes of resources.
But requests/second is only one dimension of scalability. There is management of the infrastructure. There is security (the number of Node tutorials which completely omit this is shocking). There is complexity (much of which in Node.js is pushed to the client side). There are features (e.g. the messaging and timer services in Java EE).
The buzz over Node.js reminds me of the buzz over Ruby on Rails a few years back. RoR also introduced an elegant new programming paradigm -- configuration by convention. People were amazed that the could field a simple example app without having to write XML configuration files for the ORM layer. Look! It creates all CRUD interfaces for me! But in the end those tasks really aren't that challenging for an expert programmer; they're more like sand in the gears when you're starting up a project. So while RoR remains a good tool for certain kinds of web apps, it's nowhere near as revolutionary as it seemed at the time, and it has little penetration in the enterprise market. It sees to me that most of the joy in Node.js is likely to be on the front end of the project, but in the long tail of the project you're still going to have a lot of drudge work, especially where you have to roll your own enterprise features.
Which is not to say Node.js isn't brilliant. It appeals to the old Unix man in me, because it does one thing really well. It's a superb piece of middle-ware glue. It makes exposing back end services like databases to RESTful web clients a snap, and if you've got to do that on a massive scale, where by "massive scale" I mean by retail web standards where you have to handle tens of thousands of simultaneous connections. For web applications where you don't have to integrate with a lot of back end enterprise systems and where there's a heavy emphasis on a rich HTML/CSS UI, Node.js is an elegant solution that reduces the information overload on the development team by taking advantage of the Javascript expertise they're bound to have.
Please (Score:2)
Re: (Score:2)
Interesting, would you care to expand?
Re: (Score:2)
I can 't comment on Node.js but I can see what large scale Ruby would be a problem. Because Ruby is so dynamic (classes and objects altered on the fly, not static typing, etc) there's simply no way to detect errors up front. Basically Ruby throws out everything that's been done over the last 50 years to make software development safer and more predictable. It's an interesting language, but for large scale development you're going to run into problems and hard to find bugs, as the GP mentioned.
Re: (Score:2)
Amen.
Seems like there's a cycle in this field where people forget everything that was already learned and have to learn it all over again by reinventing everything.
UI designers seem to be doing the same thing by throwing stuff away and giving all new everything instead. That gave us Metro. We'd have been better off if they hadn't bothered.
Re: (Score:2)
I don't think it's change for the sake of change necessarily. You've got to remember that this stuff is created by a young generation that's just entering the workforce. They see existing technologies as old and crufty. Declaring types? Get with the times grandpa!
Plus, there seems to be a fascination with making code as terse as possible...
Re: (Score:3)