<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>athenot</author><text>Those are all very valid points.&lt;p&gt;However, having witnessed (different shapes of) the wheel being reinvented over the past 2 decades, my take is slightly different: each language&amp;#x2F;environment has its strengths. If you have the luxury of having a senior team that&amp;#x27;s decently versed in several environments, then you can have your cake and eat it too: for each tool, micro-service, component... use the right language for that. Then tie it all together on the network. Since the system as a whole is likely to be a network product anyways, embrace it to your advantage.&lt;p&gt;Joe Armstrong wrote a good post[1] about connecting programs a few months ago, that&amp;#x27;s quite relevant.&lt;p&gt;Node.js is a great environment for many microservices. Got a task to do which is 80% done in some npm module? Make a node.js service around it. Same idea for Perl &amp;amp; CPAN, C libs, Java tools, etc.&lt;p&gt;[1] &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;joearms.github.io&amp;#x2F;2016&amp;#x2F;01&amp;#x2F;28&amp;#x2F;A-Badass-Way-To-Connect-Programs-Together.html&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;joearms.github.io&amp;#x2F;2016&amp;#x2F;01&amp;#x2F;28&amp;#x2F;A-Badass-Way-To-Connect-...&lt;/a&gt;</text><parent_chain><item><author>beders</author><text>Now all of a sudden, having types and some standards to gather around doesn&amp;#x27;t sound like a bad idea anymore ;)&lt;p&gt;I agree with one of the commenters: Lessons already learned by older engineers (who went through similar woes with other languages&amp;#x2F;tools) are being re-learned again and again.&lt;p&gt;The software industry is in a sorry state.&lt;p&gt;Unless you are a very disciplined team with a very strong sense of writing modular code, don&amp;#x27;t use Node.js for any larger project. 
And even then, the single-most useful function in an IDE &amp;#x27;Show Call Hierarchy&amp;#x27; will never be available when using a dynamically typed language.&lt;p&gt;That is not an issue for smaller projects. However, long before you even get close to the the million lines of code project size, your tools will fail you.
Your debugging&amp;#x2F;refactoring times will explode and adding a new feature will seem unsurmountable.&lt;p&gt;Instead, let&amp;#x27;s just re-write everything from scratch because the cool hipster that wrote your backend a year ago has left for greener pastures...&lt;p&gt;I won&amp;#x27;t even try to guess the amount of technical debt produced with Node.js and the likes each day in the bay area.&lt;p&gt;And, yes, I just used Node.js to write a Slack-bot. It was fun, took me two hours and got me up and running quickly.
That&amp;#x27;s the beauty of it. Just be aware of the dangers.</text></item></parent_chain></comment><story><title>After a year of using Node.js in production</title><url>http://geekforbrains.com/post/after-a-year-of-nodejs-in-production</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>encoderer</author><text>I&amp;#x27;ve worked in three million+ loc codebases, in PHP, Python and Java. I don&amp;#x27;t share your opinion that you need static types in these circumstances. You need discipline, modularity, and most importantly you need to have been blessed with gardeners and maintainers throughout the life of a project and not just after a mess has already taken hold.</text><parent_chain><item><author>beders</author><text>Now all of a sudden, having types and some standards to gather around doesn&amp;#x27;t sound like a bad idea anymore ;)&lt;p&gt;I agree with one of the commenters: Lessons already learned by older engineers (who went through similar woes with other languages&amp;#x2F;tools) are being re-learned again and again.&lt;p&gt;The software industry is in a sorry state.&lt;p&gt;Unless you are a very disciplined team with a very strong sense of writing modular code, don&amp;#x27;t use Node.js for any larger project. 
And even then, the single-most useful function in an IDE &amp;#x27;Show Call Hierarchy&amp;#x27; will never be available when using a dynamically typed language.&lt;p&gt;That is not an issue for smaller projects. However, long before you even get close to the the million lines of code project size, your tools will fail you.
Your debugging&amp;#x2F;refactoring times will explode and adding a new feature will seem unsurmountable.&lt;p&gt;Instead, let&amp;#x27;s just re-write everything from scratch because the cool hipster that wrote your backend a year ago has left for greener pastures...&lt;p&gt;I won&amp;#x27;t even try to guess the amount of technical debt produced with Node.js and the likes each day in the bay area.&lt;p&gt;And, yes, I just used Node.js to write a Slack-bot. It was fun, took me two hours and got me up and running quickly.
That&amp;#x27;s the beauty of it. Just be aware of the dangers.</text></item></parent_chain></comment><story><title>After a year of using Node.js in production</title><url>http://geekforbrains.com/post/after-a-year-of-nodejs-in-production</url></story>