5 ms·
Oh, please, not that Paypal story again. Their legacy system was written on platform/language X, then Z years later, they have written another in language Y, an
by sz4kerto 12y ago
Oh, please, not that Paypal story again. Their legacy system was written on platform/language X, then Z years later, they have written another in language Y, and surprisingly, Y is faster! For Z>=5, this is going to be true for most of X-Y pairs because people learn from their mistakes, people know more about the requirements and pitfalls of their domain after having built the first version, etc. etc.
Other than that, the article contains zero interesting information. Somebody had an uninformed opinion of Node.js, then changed that opinion because he heard some good stories, and now he convinces himself with funny arguments that he's right.
(I had too many upvotes recently anyway :) ).
- calebm 12y agoIt was not ONLY the good stories, but the combination of things I listed. I work in the enterprise world, and the languages my company most often uses are Java and C#. I've been trying to push Python, but it has been difficult. Node has a lot of selling points which allow me to convince both management and other developers. I'm nearing the end of my first large Node.js project. I may do a retrospective after, but TL;DR - it hasn't disappointed :)
- antihero 12y agoWhat exactly is wrong with Java and C#? You can do amazing things with both. I'm a Python guy, and I constantly dislike the lack of static typing for back-end things in JS/Python.
- calebm 12y agoI don't prefer the verbosity of Java; I do like C# pretty well - it certainly has its place, but Node.js also has its place. My current project is a proxy between a modern web app and a legacy Java system; Node.js was a much better choice than either C# or Java for this use case.
- doorhammer 12y agoI'd be interested in an elaboration on why Node was a better choice than C# or Java. I don't mean that snarkily; I'm really interested. I work mostly in C# and actually feel pretty happy with it as a language (I've used Ruby and Java in other major projects, used to do a lot of my side hacking in Clojure, and I'm learning Haskell now). It's one of the more solid languages I feel that I've used, especially combined with LINQ and some other tools. Also was wondering if you had heard of SignalR in .NET, and if you had, what your thoughts on it are? I don't know a ton about it. I've heard good things from other C# dev friends, but it seems to be aimed squarely at the real-time/near-real-time web arena
- untog 12y agoI work with JS every day but used to work in C#, and I still miss it. But unless you're working on MS platforms it's just a huge pain to get it to work.
- rakoo 12y agoWhich is why Golang has exploded recently: it gives you static typing security of Java with a coding workflow of an interpreted language. What I personally find wrong with Java is the extreme verbosity of the language, the verbosity of maven (it's the only build system I've used for Java), the extreme memory consumption for little benefits and generally the Architect Astronaut mentality that is so easily associated with Java. [0] http://www.joelonsoftware.com/articles/fog0000000018.html http://www.joelonsoftware.com/articles/fog0000000018.html
- dragonwriter 12y ago> Which is why Golang has exploded recently: it gives you static typing security of Java with a coding workflow of an interpreted language. Sure, it has similar static typing to Java, but it also has the same coding workflow as any other compiled environment, not the workflow of an interpreted environment.
- ColinCera 12y agoI believe parent comment was probably alluding to compilation time. My experience with Go is that the compile times are usually close to zero seconds and this indeed makes it feel almost exactly like working with Python or JavaScript. Parent may also have been thinking of Go's concision, which feels more like using a scripting language than using a class-based monstrosity like Java, and certain other features, such as type inference that make variable declaration as painless as weakly typed languages.
- dragonwriter 12y agoAs far as verbose vs. concise (including the impact of type inference), I don't see Go as being much like a dynamically typed language. Sure, it is a bit lighter than Java, but for nontrivial code you still end up with plenty of type system related cruft -- a lot more than in Haskell, which is on of the few static languages which is anywhere close to dynamic languages in terms of being concise and having little of the empty type-related ritual that plagues most other static-typed languages.
- achr2 12y agoHow would you compare working in C# (with async / Rx) to Node in terms of non-blocking design?
- doorhammer 12y agoI'm interested in this and how SignalR would fit into the picture. I have a few projects at work I think I can squeeze SignalR, which should be interesting. I've heard good things from a few devs that I know of that have used it.
- _random_ 12y agoIt's quite good we use it for notifications with ASP.NET. But consider Akka .NET port as well if it fits your tasks.
- _random_ 12y agoASP.NET vNext should be compared to Node.js. In the end of the day Node.js is simply an implementation of the Reactor Pattern leveraging a third-party JIT and HTTP infrastructure + some package management. There is nothing magic about it.
- sheetjs 12y agoLet me try to give a different perspective on NodeJS: We've been building tools to work with Excel files. The hardest problems aren't related to writing code. It's all about finding files that use different combinations of Excel features from different versions of Excel (and files from external tools that read/write files). For example, if you start from Excel 2011/2013, you wouldn't know about the custom smart tags that were removed in Excel 2010. However, those records are still persisted (e.g. BrtWbFactoid in XLSB), so you would need to produce a file from Excel 2007 to actually reproduce the error. For other people to discover errors in python or java libraries, they have to try it in some capacity. That either involves installing something foreign (which may be prohibited or undesirable) or submitting data to a third party (which is most likely forbidden). A pure-JS in-browser solution can address both problems effectively. We have a cool little web demo which parses excel files in the web browser: http://oss.sheetjs.com/ http://oss.sheetjs.com/ No installation required. Files are processed in the web browser (HTML5). We've received reports from many organizations involving confidential data. Over time, we've built other tools to inspect features of files without requiring that people send us the original file, and this allowed us to test bugfixes without having to share files. Now for the really cool part: NodeJS exposes some features like Buffers that make data processing competitive with python or other scripting languages. But since it uses the same code for parsing, fixes to the web version immediately benefit the NodeJS version. As a result, our server-side code (http://npm.im/xlsx http://npm.im/xlsx and http://npm.im/xlsjs http://npm.im/xlsjs) benefits from the performance of V8 and from the exposure that a browser-based solution enables.
- orclev 12y agoSee, this is how you make an argument in favor of NodeJS. I'm not convinced that it's a particularly good argument in general, but in a specific use case like this is makes sense, you're gaining some nice advantages to offset the inherit weaknesses of JS. Nice job, this is the single best argument in favor of using NodeJS for something I think I've ever seen.
- debaserab2 12y agoThat is a pretty powerful example - things like data importing are things that I often end up needing to queue to process in the background. Offloading the heavy parts to the client is a really awesome alternate solution. I'll be saving this for the future for sure. Thank you!
- mgmeyers 12y agoPaypal developed the Node and Java code in parallel. "Our first adopter of node.js in production wasn’t a minor application; it was our account overview page and one of the most trafficked apps on the website. We decided to go big, but we also mitigated that risk by building the equivalent Java application in parallel." -- https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/ https://www.paypal-engineering.com/2013/11/22/node-js-at-pay... So, in this case Node wasn't being compared to a legacy system.