2022-03-16
1286
#go#node
Victor Jonah
30312
Mar 16, 2022 ⋅ 4 min read

Is Go overtaking Node.js?

Victor Jonah I am a Software Developer with over three years of experience working with JavaScript and its frameworks. I currently work as a remote software developer for a tech agency.

Recent posts:

Implementing In App Updates For React Native Apps

Implementing in-app updates for React Native apps

Implementing OTA in-app updates in React Native apps can streamline the update process, preventing delays that hinder overall productivity.

Nelson Michael
Mar 1, 2024 ⋅ 7 min read
Exploring Stylex And The New Generation Of Styling Libraries

Exploring StyleX and the new generation of styling libraries

StyleX is a build-time, type-safe CSS-in-JS library recently open sourced by Meta. Explore StyleX and the evolution of styling libraries.

Ibadehin Mojeed
Feb 29, 2024 ⋅ 9 min read
Building High Performance Ecommerce Sites With Astro

Building high-performance ecommerce sites with Astro

Learn to set up a completely custom Astro ecommerce implementation that’s also highly performant and type-safe in this straightforward guide.

Onuorah Bonaventure
Feb 28, 2024 ⋅ 64 min read
Implementing Vector Search With Open Ai, Next Js, And Supabase

Implementing vector search with OpenAI, Next.js, and Supabase

Let’s build a Next.js app that implements vector search using Supabase and OpenAI to offer better search experiences for users.

Peter Ekene Eze
Feb 27, 2024 ⋅ 11 min read
View all posts

30 Replies to "Is Go overtaking Node.js?"

  1. Article is very inspirational to learn Go language. Yeah i am inspired.

    But Go is a language and nodejs is a framework.
    Why do we compare both?

    The proper way to do this is Go vs Python or Go vs Js or Go vs C# Or any other language comparison 🤔.

  2. I believe such comparison between languages is quite deceptive especially the title. A programming language may have better performance or better error handling than others. However, it’s pointless declaring it the winner if its an uphill battle doing certain projects with it. Its better to compare frameworks that solve similar problems than it is to compare programming languages.

    1. I was thinking the same thing. I am an old timer and back in the day I had to hand code all the threading (no helper stuff like promises and async/await). This guy clearly hasn’t or he would no that every program runs in the main thread and then you spawn other threads for concurrency. Exactly how node.js works with promises and async/await.

  3. First koodos for writing article. People dont realize how much effort that takes i think.
    I dont disagree with you overarching statement, dont think any programmer would. The tool is often decided by the projects needs. However you seem to make some false assertions on node end of things. Node while default is single threaded worker threads were added since mid 2018 giving it the ability for concurrence for example. Can also use clustering to take advantage of multi processor systems.
    No intentions of starting a “no my language is better” war lol. Just trying to help inject information that was missing. Thanks again for article was good read.

  4. With all due respect, this comparison lacks depth and it’s misleading. It’s mixing language characteristics with runtime engines.

    For concurrency, Node is designed to be deployed in production as a cluster for HA. Something like PM2 will run a node process on each core allowing maximum parallelization and independent recovery. Error handling is a JS spec not Node. Anyway, it is much better in JS because you can have custom error types extending from Error and you can catch each type independently and handle as you wish. Also, you can have a global error handler. High pay might be true, but there are many more Node jobs. Go is a pretty sweet language, but JavaScript is way more flexible.

  5. Go biased article I would say.
    But appreciate the efforts put in .
    Every language has its pros and cons we all can agree on that.
    Node.js is a runtime for that matter.
    Paypal, uber and many companies use node.js for their tasks because of its scalability and being able to handle much more requests in single thread which results in consuming lesser memory.
    Where in traditional web servers every request is handled by a different thread this is much more efficient when it comes to i/o intensive application.

  6. I must strongly disagree about Go being the winner in error handling. This is very application specific. While Go might be more disciplined, it also forces you to clutter your code with loads and loads of error handling scopes.
    Javascript’s types errors allow you to keep your business logic flow completely clean and handle all errors by some error handler at the top of the scope. You can define different handling strategies for each error (DbError, ValidationError, AuthError, etc.) at a single point in the application.

  7. Go and Nodejs can be compared against each other because developers need to make a decision to choose one over the other when developing their software.

  8. Go and Node.js can definitely be compared and developers need to compare them when choosing tech for project. If I chose Go, I also get the Go runtime compiled into my app. If I choose Node.js, I’ll be writing my code in JavaScript. “Go” and “Node.js” each imply a language and runtime.

  9. nah, any language “implementation” is beyond a language. Go is not only a specification but also implementation including compiler, runtime, and ecosystem. So it’s perfectly valid to compare them as a whole.

  10. Go does NOT have the same performance as C, they’re not even comparable. Just because it compiles to machine code instead of VM bytecode doesn’t mean it’s C level fast, the runtime garbage collector slows it down. This brings Go’s performance more in line with C#.

  11. It feels like the person that wrote this article has little to no understanding of how modern node works.

    First issue “node is single threaded”. Well so are a lot of language when you neglect the features that allows them to run on multiple threads. In node’s case it uses the cluster module to spread onto different threads. Node, like java, can also employ the help of native applications via the child process module. In theory allowing node and go to coexist.

    Second is the “node is linear”. Unfortunately this statement is outdated with the advent of modern asynchronous JavaScript. Which the more I read about goroutines…the more they start to sound like asynchronous JavaScript functions.

    On a broader spectrum. It might be worth bringing in one go programmer and one Nodejs programmer in for a debate when doing another one of these articles. As it would allow for a fairer comparison

    1. Even if we ignore modern JavaScript, Node has always been able to run things in parallel. The standard modules have always been able to run things in their own threads with libuv.

      It has ever only been the event loop that is single-threaded. Read a file – that goes to a worker thread. Write to a socket – that goes to a worker thread.

      People who have written their Node code as sequential awaits or inner .then()s have, practically, ran Node as single threaded.

      People who have used Promise.all etc have been writing concurrent code all the time.

  12. “Node.js is a single-threaded tool that uses the event callback mechanism. This means every function or method executes in a linear order. [..] So, Node.js lacks concurrency.”

    This is frankly very misleading.

    Node has a worker thread pool, used heavily by the standard modules like `fs`.

    The event loop runs a single thread and your JavaScript is executed by a single thread (well, not necessarily always true nowadays, but lets ignore the most recent developments).

    But a lot of stuff you actually do ends up utilizing multiple threads. Read a file? That’s concurrent. Send a HTTP message? That’s concurrent. You can, 100%, do those things at the same time, even ignoring web workers or anything like that.

    What you can not do is return to JavaScript from those functions at the same time. And what you can not do is call those functions from JavaScript at the same time. But they can, and do, run at the same time.

  13. If You don’t know javascript nor golang the javascript is actually hugly more difficult then golang.
    Javascript deals a lot with its past. E.g. You can declare variables using “var” or “let”/”const”. Both the options deal differently with scope. In ideal world, You only have let + const, but for BC You need both. And there is really lot of similar shit in javascript. Plus for some incomprehensible reasons, javascript tend to have way too many ways to do the same think in the end and You need transpiler (for typescript) to really have something usable.
    On the other hand, golang is really minimalistic and unambiguous. Most of the time, there is exactly one way to do some thing.
    I still don’t consider golang as the most comfortable language (more because its convention /community preferences kind of a punk culture, missing complex frameworks…). The other thing is, that as a golang developer You are more likely be expected to know devops+cloud-native-infrastructure.
    I can see a lot more jobs open for nodejs then for golang.

  14. Thank you for your kind words! I’m glad you found the information informative and enjoyable. If you have any specific questions or need further assistance, feel free to ask. I’m here to help!

  15. The Node.js community and ecosystem are undeniable assets. Finding libraries, tutorials, and experienced developers is much easier compared to Go. While Go’s strengths are attractive, I believe its wider adoption hinges on building a similarly robust community and resource library.

Leave a Reply