Hacker News new | past | comments | ask | show | jobs | submit login

I've got over a decade of professional experience in C#, Python, and Java. I'd consider myself a Java developer before all else, yet I still turn to Node.js for proof of concept projects because certain things are just quicker to implement.

Here's the major caveat, out of, say 100+ PoC/prototype projects I've ever done, I've taken two to 'production'. I put production in quotes because they were actually internal services as part of our build and delivery pipeline. It's a major pain in the butt to monitor and keep Node.js running production-like in even remotely similar ways you would with Java, .NET, Python, or even PHP for that matter. I don't expect such drastically different technologies to be exactly alike for production workloads, but there's usually analogous ways to do X, Y, or Z.

You know where Node has been awesome? You land a project with a real tight deadline and its more of a fire and forget project (think interactive 'experience' at a major gaming conference for instance). It needs to run pretty well for a short period of time with a narrow scope of functionality, but some of that functionality is non-trivial. I absolutely love Node for that.




I've had several experiences with Node.js contractors handing over "finished" applications that were only configured to run under webpack-dev-server[0]

It clearly tells you in the README it's not for production, but I have this recurrent discussion with developers who tell me they have only ever run Node.js this way.

What that tells me is there is quite a trend a towards exactly what you describe, where a lot of what gets written never goes into production.

[0] https://github.com/webpack/webpack-dev-server


Webpack dev server simply serves up compiled assets for convenience, because it serves new assets as they are compiled and blocks when compiling. It should be fairly trivial to serve up static production assets as needed. I say this as a person who just converted a production rails app to use webpack as first class citizen.


> in the README [that it is] not for production but ... who tell me they have only ever run Node.js this way. What that tells me is there is quite a trend towards ... a lot of what gets written never goes into production.

No, it is worse than that I would have thought. The cynic in me (who is more often right then wrong) suggests that is means there is a lot of "proof of concept" level of code out there in production environments potentially running important things.


> yet I still turn to Node.js for proof of concept projects because certain things are just quicker to implement.

Why?

Writing Java is really very fast these days, especially with IDE's.

I can get a small web site serving JSON REST requests and memcache up in ten minutes with a simple Maven/Gradle build and full IDE integration.


You know what isn't as quick? Websockets, non-trivial asynchronous code, boilerplate, and build times. The vast majority of my company is built on Java and we're not encumbered by legacy code, so we get to play with all the new stuff. I don't need to be convinced that Java (or even more specifically the JVM) is a good choice for many practical reasons. I live in IntelliJ and Gradle (and Maven too) all day, you're preaching to the choir.

Between having a REPL, near instaneous stop/relaunch times, and doing in 8 lines of Node.js what takes me 70 lines using CompletableFutures, I'm still going to reach for Node to prove the idea.

Now, when it takes hold and looks like it might stick around, it immediately gets turned into a Java project. Or, if the event we were building for is over, it basically just gets deleted- which pretty much says it all in my opinion.

It's not a toy language, there's some real usefulness to it, but just like anything else, there's a time and place. Currently, that place is NOT production.


I agree that Java's async support is bad (haven't had to use it much since I've been primarily Scala for years now), but I'm surprised a PoC would need to be async in the first place? Conventional one-thread-per-request is fine for non-prod, no?


A lot of projects my team did at my last company were of the "You've got 2 or 3 weeks to build this awesome thing for a launch event that will have a crushing wave of usage for about 3-7 days".

It was really fun work, because even the 'simple' stuff we built had to address some of the big traffic issues you'd normally have at a much larger scale and the work was usually very high concept or cutting edge. It would've been a nightmare to maintain for longer than a week though.


I'm surprised that you consider it controversial that a highly dynamic language can be considered fast to PoC something in than Java. There is just less typing/code that needs to be defined (I know IDEs help). Also easier to do quick and dirty stuff that I imagine would be more restricted in Java. No classes to define, just throw your values in there.

I prefer python in general but for zero-to-simple-web-endpoint I may pick Node.


> I'm surprised that you consider it controversial that a highly dynamic language can be considered fast to PoC something in than Java.

Sure, but that wasn't the argument; GP talked specifically about async and websockets, which are areas where Java is particularly weak, but areas that I was surprised would be required for a PoC at all.


Fair enough. I was mostly responding to the thread of discussion overall. I realise now that I was probably reacting more to the viewpoint of hota_mazi.


Do you have any particular reasons to prefer Node (assuming Javascript) to Clojure/Groovy?

Asking, because I do most of my development in Clojure and find it much nicer than Node both for POC and production. There's also self-hosted Clojurescript now that runs without a dependency on JVM.


Honestly, because I'm pretty good w/ Node (or just JS in general) and haven't invested the time to get good w/ Groovy or Clojure at this point.

I've only just played around with Clojure and I've written a middling amount of Groovy, but the vast majority of it involved Jenkins build pipelines, so I don't really count it.


> I can get a small web site serving JSON REST requests and memcache up in ten minutes with a simple Maven/Gradle build and full IDE integration

Java guys always say how they have really developed tooling and look down on other languages. The problem is those nice tools have become a hindrance as well. You can't develop in Java/Kotlin if you don't use those huge complicated tools.

I can't speak for all, but at least for me it prevents me from ever using Java tech. I can develop just fine using a lightweight editor in any of the languages I use. I don't need huge tools or complicated build systems. Because my languages have nice tooling that I can write manually and fully understand.

I tried using Kotlin and step one is always install Intellij.


> huge complicated tools.

Oh please. Let's be real, Maven is not even remotely more complicated than the typical package.json, webpack.config.json, .babelrc triple you need for any useful NodeJS project (though you can put the .babelrc into the package.json, I've heard that's the way to do it at the moment). I was so taken back that nowadays JS needs a build step too. But it's a "transpiler", not a "compiler" - cause that's something completely different.

> I tried using Kotlin and step one is always install Intellij.

So? Atom and Visual Studio Code did need to be installed too on my machine. This mentality reminds me of someone using an axe head as a hammer "I'd have to pull the hammer out of the toolbox" (install it) - that's too complicated, I prefer light-weight tools!"


No I want to use the command line.

https://maven.apache.org/guides/getting-started/maven-in-fiv...

Maven quick start first command:

> mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false

Then it generates stupidly deep Java structure.

and next you have to write a verbose xml. They even say:

> The POM is huge and can be daunting in its complexity

All of this stuff is verbose and built to be generated by IDEs. It's not clear, it's not concise.


> Then it generates stupidly deep Java structure.

It generates enough structure to scale up to reasonable projects. The nesting is a price well worth paying for consistency. Every maven project puts its source in the same structure, with the result that you can jump into any project and know how its build will work and where to find the source.

> All of this stuff is verbose and built to be generated by IDEs. It's not clear, it's not concise.

Verbose is worth it for clarity, particularly in a file you edit rarely. It may not be concise but it absolutely is clear, as the example from your own link shows.


I'm sure the tooling is useful and a lot of it reasonable. I've never approached a Java project that I did not find intimidating, either Android with all the Gradles and XML.

I've never seen a barebones project as you would when using just node+npm without all the extra tooling (webpack and friends). Node+npm is to me as simple as python+pip. Is there a natural counterpart, Java+maven or something?

And to be fair. All my attempts at approaching webpack have been even worse. And most JS-framework seed projects are similarly complex and automagical.


I don't think you need anything other than java+maven. That's all my projects use as far as I'm aware. Android probably requires some additional stuff for its packaging but I just enabled the maven android plugin and trusted that to handle it - if there's any other config I haven't been touching it.

The grandparent linked to the maven getting started, https://maven.apache.org/guides/getting-started/maven-in-fiv... . That shows what the minimum looks like - a pom.xml, and application source code in src/main/java (under its package structure). (The unit test isn't strictly necessary but is good practice).

The pom's XML header and modelVersion are boilerplate, but the rest is pretty clear and self-explanatory (though admittedly verbose).

At that point for a library project you're sorted, for an application you can run your program via "mvn exec:java" which is adequate for development. To actually package up your application for distribution you probably want to use the shade plugin a la https://maven.apache.org/plugins/maven-shade-plugin/examples... , but that's something you'd do as part of "productionisation". (Back when I worked at an early-stage startup we had things running and serving user requests via "mvn exec:java")


Appreciate the overview. It sounds similar to what I'm used to but, as you say, perhaps a bit more verbose. And some stuff is non-obvious to me, such as mvn exec:java instead of my-java-runtime main.java or whatever.

I've encountered a bit of this with most AOT-compiled stuff except for Go. Make or compiler-flags also requires a bit of learning to get going.

Most dynamic languages tend to be more straight-forward with this.


> some stuff is non-obvious to me, such as mvn exec:java instead of my-java-runtime main.java or whatever.

That's kind of our way to do virtualenv-like functionality, which is mandatory rather than optional. (Or you can specify the classpath manually in the same way you would for the pythonpath, but no-one wants to do that). IMO that's the right thing - having libraries installed in my system python has only ever caused trouble in the long- or even medium-term, even if it makes "hello world" use of libraries very slightly simpler.

There's probably a way to get a shell with the classpath set up correctly, but I always found that kind of modalness more confusing than helpful.

> I've encountered a bit of this with most AOT-compiled stuff except for Go. Make or compiler-flags also requires a bit of learning to get going.

In my experience it does all work without any flags or extra knowledge. "mvn" is the entry point for all the things you want to do - you don't ever have to know that there's a "java" and "javac" underlying it.


> It generates enough structure to scale up to reasonable projects.

It generates stupidly deep structure because Java requires a stupidly deep structure.

> Every maven project puts its source in the same structure, with the result that you can jump into any project and know how its build will work and where to find the source.

Rust, Elixir and Erlang achieve this with tooling that is practically trivial to use. Without an IDE.

> Verbose is worth it for clarity, particularly in a file you edit rarely.

Being concise is a big factor in clarity.


> It generates stupidly deep structure because Java requires a stupidly deep structure.

All of the depth is useful. The folder structure corresponding to the package structure makes it much easier to find the source for something.

> Being concise is a big factor in clarity.

True when there is large-scale structure that varies for the reader to comprehend. Less important in an inert declarative structure. Again, look to the example you linked.


> The POM is huge and can be daunting in its complexity

Because they are honest. Maybe it is because I'm more accustomed to poms, but the package.json/babelrc mix and webpack.config.jsons are daunting to me too.


Web ecosystem is a mess as well. What I meant was Rust, Elixir, Erlang build/project files. Those are trivial.


Maven is a "bad example" - it's horrible. Everybody agrees.


> mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false

Ah, I can see how this is much more complicated than the good old

    npm install webpack babel-loader babel-core babel-preset-es2015 babel-preset-react --save-dev


You don't have to use maven directly. Something like https://github.com/bodar/jcompilo would be much simpler and faster for a small project.


You don't need a build step for Node.js, 93% of ES6 features are already included in the latest version. Babel is more for client side than anything and that's because browser vendors take a while to implement new standards, so yeah JS has unique challenges and constraints as the de facto language of the web.


Or typescript frequently.


> So? Atom and Visual Studio Code did need to be installed too on my machine. This mentality reminds me of someone using an axe head as a hammer "I'd have to pull the hammer out of the toolbox" (install it) - that's too complicated, I prefer light-weight tools!"

You misunderstand my point completely. I was trying to say the Java ecosystem is complicated and the only way it works is by using large IDEs. Saying how awesome Java IDEs are is disingenuous because Java is unusable without them.


> because Java is unusable without them

This is like saying 'Javascript is unusable without IDEs', you know.


And this is making Java look good how exactly?


This makes all programmers liking to write code with maximum level of comfort - e.g. using IDEs.


Most Java people I know use IDEs mostly just to edit and debug the code, and does the builds/runs/tests from the command line.


What do you mean with "just to edit"? Aren't there any (compilation) errors, warnings displayed anywhere?


Yeah there are, sorry, a this point I consider them basically auxiliary editor features. I forgot that some other languages don't have this luxury.


Getting a node server running the first time is actually very difficult. The libraries constantly change so fast tutorials frequently don't work. It was easy once I understood everything, but it wasn't easy the first time at all.


IntelliJ is an awesome IDE, but it's not necessary. Part of it is Kotlin as well though, that's definitely as immature (as in age and mindshare, not attitude) of an ecosystem as there is with Java.

The thing with Java is the amount of boilerplate, but the thing with Java is that all of that is ridiculously well documented or demonstrated ad nauseum. Are you building a jar with Maven? Your folder structure looks like this. War? It looks like that. Before Yeoman or any other generators even existed Maven has had archetypes that do the exact same thing.

If you compare Maven, heck, even Gradle to Webpack + Babel for even fairly trivial projects, there's no way that it's more complicated. The tools for Java are truly portable, I can't even recall the hell we used to have to go through when we had to run gulp builds on Windows because developers of various libraries had hard coded *nix style paths, etc.

Most importantly, Maven and Java really aren't a moving target. 9 months from now I'm not going to have to overhaul my entire build process because a wide swath of my plugins have completely changed directions. Stability is how you wind up with the time to make things run smoother in production. It's how you wind up with repeatable patterns and better instrumentation. You get a chance to take a breath and formulate an honest to goodness process vs. literally sprinting as fast as you can to simply keep up with the changes.


> You can't develop in Java/Kotlin if you don't use those huge complicated tools.

This is based on what? It is totally untrue from my experience. Quite the opposite.


I tried following the gradle command line guide for Kotlin to build a project and it did not work and I had no idea why. No errors and nothing happened.


The edit/refresh cycle starts to slow as the project grows in Java, but node has pretty close to zero startup time and is interpreted. That plus a repl supports a much more explorative coding style where things work as fast as you can add them. No JVM restarts, compilations, or going back to change types or api's in the middle of a thought.


> The edit/refresh cycle starts to slow

IDEA and Eclipse compile your code as you write it. And with Hotswap, you don't even need to redeploy anything. They also all offer REPL's that are much more sophisticated than anything Javascript has to offer.

I think you haven't used a JVM language and its ecosystem in a very long time.


> And with Hotswap, you don't even need to redeploy anything.

Except when you have to restart the JVM because you added a class or a whole bunch of other things that it can't hotswap in the new code.


It's true that the hotswap support built in to the JVM is somewhat limited, but there are tools that are more comprehensive and can hotswap new classes, methods, method signature changes, etc. (JRebel and spring-loaded are the ones that come to mind).


Still better than any dynamically typed language (I mean any) where you always have to redeploy everything since none of these language support incremental compilation, let alone incremental reloading.


If I'm using a truly compiled language (eg. C++, D), which have incremental compilation, I still have to redeploy everything since 'everything' is a single executable.

If I'm using an interpreted language I only have to deploy the changed source files. Git can do that for you.


I use Java today daily, and came from Node. It is slower to have the compile step, even on very powerful machines, dynamic types are faster to change, and there are many caveats to hot reload. The repl comment was about is about speed, not sophistication. When something happens instantly versus a tiny pause, you don't think about seeing your change immediately on save, versus batching many changes together and then testing them. This turns out to be faster for me for explorative work. Many people agree. Just trying to explain. /shrug


I've found myself getting much better at making testing changes in such a way they can be hotswapped, then batching them up into a change when it's necessary to do a JVM restart. Sometimes I impress myself with how long I can go with just hotswaps, kind of like a code golf, but it's absolutely the biggest time suck of a Java developer's day. Besides meetings.


> I can get a small web site serving JSON REST requests and memcache up in ten minutes with a simple Maven/Gradle build and full IDE integration.

Dropwizard is a great example of this. It's an opinionated (convention over configuration) Java framework for building REST web services. You can get a 'Hello World' web service up and running in literally 10 minutes following this tutorial http://www.dropwizard.io/1.0.0/docs/getting-started.html


I can understand it. If you want to just get something together quickly then dynamic languages do have an edge. They allow you to say "just give me whatever and if it fits, it fits" and if you aren't that concerned about it breaking you can build something extremely fast.


You're just repeating the same claim without any evidence.

Why is it faster to write code in a dynamically typed language?

Most modern statically typed languages have type inference so you don't even need to write type annotations for the most part, assuming these extra characters were the reason.

So what's that mysterious reason that makes writing dynamically typed language faster?


You're leaving out a lot when you say it'd take you "five minutes with a simple Maven/Gradle build". What's a maven? What's gradle? What's groovy and where can I learn it?

I literally don't know the answers to these questions so the same task would take me hours, possibly days. Getting from zero to JSON api in node.js is fast by comparison.

Note I am not arguing whether or not it's better in the long run to be the guy that went from zero to node.js or zero to Java, that's a separate discussion.


> You're leaving out a lot when you say it'd take you "five minutes with a simple Maven/Gradle build". What's a maven? What's gradle? What's groovy and where can I learn it?

You have similar concerns with node (What's npm? etc...) These are peripheral and necessary knowledge on both platforms.

> Getting from zero to JSON api in node.js is fast by comparison

It's only fast because you already have the knowledge.

Two equally proficient developers in Java and node will set up and get a server up and running in about the same amount of time.

The idea that it's a faster to achieve in a dynamically typed language is a myth.


> It's only fast because you already have the knowledge.

No, when I said "from zero" I meant from zero knowledge.

> You have similar concerns with node (What's npm? etc...)

What's the "etc..."? Install node and you get npm with it.

Writing a REST service IS simpler with Node when going from zero, I know because I have done (or at least attempted) both from zero in the recent past.

> The idea that it's a faster to achieve in a dynamically typed language is a myth.

Doesn't seem like you're open to discussion on this


This is a classic case of you forgetting all the learning and concepts you needed to get to "zero".


I don't think so. Npm is included with node and is very simple to use.


So your main argument is that you have to make two downloads with Java (JDK and Maven) but with Node you need to make one? Seems pretty weak.

It can't be anything else, because after you have Maven, it is literally a single command to set up a REST project using Dropwizard.


Well, to an extent this is a subjective question. With node, you get npm with it, npm is what everyone uses, and npm is clearly what you should be using too. Moreover, the basic functionality of npm is very very easy to understand.

I find the Java ecosystem terrifying by comparison. I have no idea whether Maven is what I should be using or if I should be using something else instead -- having it as a separate download makes a big difference in that regard -- and I have no idea by looking at a typical Maven config file what it does.


You should probably learn to expand your comfort zones more effectively, if the Java ecosystem terrifies you.


It's not a macho thing for me. I use the tools that are easiest to use and do the job. Anyway, I have used a lot of different programming languages, and it's the Java ecosystem specifically that I've always found overwhelming whenever I've tried to dabble with it. So I think the problem is Java, not me.


There's nothing "macho" involved in this, your language describing your own state of mind is inflammatory and (hopefully, for your sake) inaccurate.


You may need to expand your comfort zone with regard to mild hyperbole.


"Terrifying? What if something REALLY happens to you? You used 'terrifying' on the Java ecosystem!"[1]

[1]: http://zenpencils.com/comic/95-louis-c-k-we-dont-think-about...


It's not that it's terrifying. It's just... why make it harder for myself? Even if it's one step (which it isn't), why? If the only reason you can give is I need to expand my comfort zone, sorry, I'll keep my comfort zone small and productivity high.


I wasn't responding to you. The person I responded said, "I find the Java ecosystem terrifying" and I pointed out how silly that statement is.


The command to set up a Dropwizard project according to the getting started guide[0] is:

    mvn archetype:generate -DarchetypeGroupId=io.dropwizard.archetypes -DarchetypeArtifactId=java-simple -DarchetypeVersion=1.0.0
Which spends the first 30 seconds downloading a bunch of stuff before asking you for settings to start off your project. I then read the README it created and ran `mvn clean install` as instructed which started downloads that took 1:40 min only to end in a build failure with multiple large tracebacks.

Running `mvn --help` doesn't help at all and the pom file it creates is 143 lines of hard to read XML.

I've used gradle a little, I'm familiar with bundler/gem, pip, npm and dub. Maven just makes me want to run as far as possible from anything Java related.

[0] http://www.dropwizard.io/1.1.0/docs/getting-started.html


You just described my experience with npm, except there aren't any useful tracebacks, just a note absolving npm of all blame and advising me to contact some random module author.

Edit: and of course with npm the annoying downloads happen every time for each project, instead of once per dependency version...


Not excusing any crashes for npm (having those for any package manager sucks), but `npm init` doesn't download anything or make a project that needs to, it has readable config files and `npm --help` at least gives you a list of commands. A lot of the small stuff goes a long way to making things more approachable.


That's apples and oranges. You would have to set up some Express project or something to do what the Dropwizard archetype is doing.

Also package.json and pom.xml are equally (un)readable. At least Maven project files have a schema to help editors out.


> `npm --help` at least gives you a list of commands

`mvn --help` gives you a list of commands too.


Knowing how to use npm and what packages are useful isn't something that is flashed into your brain when you click download on the Node website.


For example, I've been doing a lot of Rust coding.

The code in question looks like:

    iter.next().ok_or(ErrorKind::NotEnoughArguments.into())?.parse().chain_err(|| "cannot parse argument")?
the compiler responds with cannot infer type information for `_`

the solution is of course to do

   iter.next().ok_or::<Error>(ErrorKind::NotEnoughArguments.into())?.parse().chain_err(|| "cannot parse argument")?
then the type inference is decidable

in a dynamic language, you wouldn't have to worry about this; in fact, you wouldn't need to call .into() either - there's just less typing and compiler errors


>So what's that mysterious reason that makes writing dynamically typed language faster?

Less ceremony.


But no ceremony is necessary in the cases where types can be inferred - and in the cases where types can't be inferred you probably do want to to be explicit about them even in a dynamic language.


It's not just the types, it's the whole APIs, culture etc.

Java, for example, is no picnic, whether it can now infer some types or not.

In Python I don't even need a main().


How is

    if __name__ == "__main__":
        main()
different from a main()?


It's only needed if you're importing the file as a library/module somewhere.


You don't even need that.

  print("hello world")
will run just fine


It's different in that it's optional in Python.


I agree Java is a high-ceremony language, but not all statically typed languages are like that.


The slow part of static languages isn't just typing out the annotations. Its needing to describe the type in the first place, and needing to change that type description if the shape of your data changes. If you want to prototype quickly in a dynamic language, you don't need to mess around with any sort of class description as you decide how you want your program to work.


Said dynamic language, not dynamically typed. Would be surprised if anyone considers Java more productive than Rails, Python (Django, Flask, etc) or Express.


You don't need to wait for them to compile.


Unfortunately, modern JS has Transpilers, which you have to wait for, so no, that's not the case anymore. I have not seen any NodeJS project which didn't have to be transpiled (i.e. compiled to a different JS version).


Totally false. Node.js pre-dates Babel by about 6 years so I wonder how that could possibly be true. Second, most ES6 features are already included natively in latest versions of Node so no need to transpile at all. You can even get async/await out of the box.


No one cares how you wrote 6 years ago, today the way to do it (as I've been told by many people who write NodeJS applications all the time) is to use transpilers. And:

> most ES6 features

Most. Ugly word. Really ugly word.


That's a way to do it. It is not the only way to do it, even if some people do it that way all the time.

I might add a transpiler for Typescript to my stack soon, if that language turns out as pleasant to work with as I've been hearing. If I do, it'll be the first time I use one. And I've been working with Node, in production, since 2013.


Go away. I've invested weeks to learn something which at least resembles NodeJS best practices and now you come along and say "nope, we do it different" ... :(

(That was a joke btw. Thanks for the info. The consensus seemed to be that Babel is the way to go, but if your variant works for you good to hear. I will still stay with it. I like ES6 imports in Node.)


Hey, you do you. I'm just here to say that not everyone agrees, or should, that real-world best practice necessarily involves a giant pile of transpilers and bundlers.


Can you elaborate on the "major pain in the butt to monitor and keep Node.js running production-like" What sorts of issues did you face? Certainly .NET and Java have more tooling, but I haven't noticed a difference between keeping a Node process up as opposed to a Python one. Hard to compare to stateless PHP.


The default behavior for Node when there is an uncaught error is to crash the process, killing all requests in flight. Even if you go out of your way to stop this default behavior, errors still likely leave the process in an inconsistent state. Node can't just unwind a few stack frames like synchronous platforms.

Do you read JSON from ajax post bodies? Do you access fields in that JSON without sanity checking it? Try passing JSON that's missing one of those critical fields (as, say, a griefer might do). What happened to your app?


You nailed it. Three major things I care about for my application:

- Logging

- Metrics/Instrumentation/Tracing (memory usage, transactional performance monitoring, etc)

- Surviving exceptions

All of these are either very immature in Node or simply so far behind they may as well not exist. By nature of running in an application server, you do get a lot of benefits right off the bat for all of those, but even if you're running an executable jar instead of deploying to Tomcat stray exceptions will in almost no cases cause your application to simply die for all requests.

Also, say what you want about the verbose try/catch Exception model, but at least you can count on it. Am I getting an Error in this callback or is an exception going to get thrown? Oh, they leaked an exception when I was prepared to handle an Error and now my entire server is down. Does your process automatically restart? Not likely unless you spent a lot of time hand crafting your service to be daemonized, which is generally FAR beyond the scope of most developers I've met in any language (which also upsets me).


Promises and now async/await go a long way to remedy the discrepancy between synchronous exceptions and asynchronous errors, by helping ensure that they both end up as promise rejections (as long as promises/async functions are your de facto async abstraction) while also being handleable with try/catch. The Koa framework (and in the future Express I believe) is designed around this concept, so middleware-level promise rejections can be handled in a single place, and by default simply produce an HTTP error response. It is a shame that it's going to take a while for the Node stdlib to catch up, however.

Also I thought something like PM2 (https://github.com/Unitech/pm2) or Forever (https://github.com/foreverjs/forever) was pretty much standard for production Node apps?


Spot on! And with node version 8, due out any week, we no longer needs babel on the server when doing async/await/import. It will all be there natively.

We use PM2 in production for web apps, long running processes (console apps with rethinkdb change feeds) and cron to spin up command line apps for data transformations, SaaS integrations, bots and more.

Most of us use VS Code now (I still use Vim)...so yes, having done enterprise work with a full blown IDE and tooling can be very helpful as the Node debugging and profiling experience is not great (but getting a ton better).

In the past we had a ton of C#/.net in production, then Ruby and now JS for the indefinite future. We build things that end up in production for 10 years or more, so having that talent pool to pull from in the future will be great.


If one is spending any time hand-crafting the program to daemonize itself on a Unix or a Unix-alike, one is doing things wrongly. On those operating systems, since the advent of the System Resource Controller in 1992 the right way to write a program that runs under a service manager is to write a program that runs in the normal way. No "daemonization" needed.

* http://jdebp.eu./FGA/unix-daemon-design-mistakes-to-avoid.ht...

* http://jdebp.eu./FGA/systemd-house-of-horror/


I for one consider that a feature - it is easy enough to write bad code in JS as it is, so anything that encourages defensive coding and solid unit/functional tests is very appropriate for this particular language.

A crash certainly draws attention to a problem much better than an error in a log that no one usually looks at.

Yes it's a pain, but you deserve it for writing buggy code and then not catching it in testing (that's what I keep saying to myself, anyway). ;)


That crash, in your high-concurrency environment, produced "bad gateway" responses or closed connections for your users. I'm pretty sure they don't consider this a feature.


If only node had exception handling and functions!


Node has - for me - the same problem as C#. Unchecked exceptions on every corner. You don't even know what can explode until it explodes. And then takes your Node instance down. But I am one of these weirdos who likes checked exceptions in Java, so maybe this is not a problem for others.


The same problem as C#? You're fighting a very old position.

Exception handling in C# is amazingly good, you can't run C# production level apps.

It suffers none of the problems that are being discussed above. All you're doing is confusing the discussion with a view point I haven't heard in a decade.


The default error middleware built into my framework caught it and responded with a 502.


...and almost certainly left a bunch of dangling state in your app that, at best, is a memory leak.


... or almost certainly was correctly dereferenced, logged, and garbage collected.


> The default behavior for Node when there is an uncaught error is to crash the process.

What language doesn't do that?


Love it or not, at least Python has uWSGI, which certainly helps keep things running through errors, and gives you more robust logging at a higher level, etc. if you lose your Node process it's just poof with no guarantees you'll get a good trace to pinpoint the fault.


Huh, that's weird, I've never had a Node process silently die in production without a good trace or robust high level logging. Are you sure you're‚Äč not just making stuff up?


pm2 + newrelic = problem solved?


Or just Systemd


Obviously systemd for keeping processes up, but is there a god way to centralise journald logs in one place (and search it). Hoping for something that's pure journald not a syslog equivalent (as I'd rather less software than more).




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: