People refer to the problem of callback hell
This has never been an issue for me. You can use whatever structure you want in your code. Any promise library may be helpful if you find that you really need 1,000 nested callbacks, but this is rare in most circumstances.
lowering performance of node.js once the business logic starts to be more complex than simple loops
Rarely is this a problem. Most applications are IO-bound. If yours isn't, you have a couple options. One is not to use Node.js. Another is to compile a native extension for the specific part that's dragging you down (since you'll be writing native code to solve this problem anyway) and call it from the rest of your Node.js application. That way you get most of the performance of your native code but still get the flexibility of working in JavaScript.
Since you linked to that Reddit post, I'll address some of the comments there.
Javascript is very fast. Yes this is true, V8 is very fast... however, only if you are benchmarking a simple benchmark. As soon as you start adding in complex application logic all that performance goes out the door because the virtual machine has a very difficult time correctly inferring the type and thus not being able to optimize. But if your application consists of a tight loop, it will be fast.. so its got that going for it :D
It's all relative. No doubt that weakly typed and interpreted anything is slower. It's a trade-off that you have to decide makes sense for what you're doing. Personally, it's far cheaper for me to fire up another box to handle the load than it is to rewrite all of the helpful modules and frameworks I use in Go. Maybe that's not the case for you, so you get to decide.
In my 3 years of full time node.js development, I have honestly only had ONE occasion where I used the same 4 lines of code both in the server and in the client.
This is generally true. I don't understand why shared client/server code is some sort of selling point for Node.js, as it isn't for most applications. I had one case where several classes I wrote for an RPC layer ran on both the server and the client. One thing I will say though is that there are a ton of NPM packages that run in both so if you get used to using a nice package on one, it will often times work on the other.
Ohh and did I mention Node.js isn't really all JavaScript? A good portion of the pakcages on NPM are also written in Coffeescript. Hope you don't mind learning another language to deal with a package you depend on. So much for using the same language for both server and client!
You don't have to learn Coffeescript to use an NPM package written in Coffeescript. Coffeescript compiles to JavaScript, and are used in your code the same way any other package is. Also, those same Coffeescript packages do run just fine in the browser since it all builds to JavaScript.
With Go you get type safety. This CANNOT be overstated.. except to maybe ruby-ists(jk jk! don't shoot me).
It's up to you to decide if this matters for your use case.
The one benefit you have with Node.js over Go is the massive number of packages available on NPM. But most of them are useless abandoned junk. So, even that is questionable.
Don't use abandoned junk, just like you wouldn't with any packages on any platform. It's very easy to see what's abandoned junk. NPM calls out what's been updated and when, whether or not its dependencies are up to date, and how many people are using that package. There are definitely a massive number of useful packages available for Node.js, just like they are for most popular platforms.
Testing: Lets just say that in Node.js/Javascript you would have to write tests that check the type of a variable. tsk tsk tsk... This is the only way to properly test JS and make sure nothing crazy is going on.
That's not really accurate, and I'm really curious what's going on in this person's application where this is necessary.
