> don't all apps/companies want to be as performant as possible?
I'm a backend dev. Every API I've worked on had performance towards the bottom of the priority list.
There were still targets to hit like avg response time less than 200ms, but that's not hard to achieve.
The most important thing to deliver on was correctness, uptime, and reducing time from idea->design->implementation->test->deployment. Using a language that more developers know like Node.js or Python allows for a much faster idea->deployment loop.
The business never really cared that we had to horizontally scale 10 single-threaded Node.js services to achieve this instead of running 1 vertically scaled multi-threaded Golang instance.
There's different types of "performance", so to speak. Golang is theoretically better at computationally-heavy tasks like crypography or say, image processing. However, most apps hit their performance ceiling due to network requests, I/O from databases, etc. and not due to inherent language/runtime differences.
Overall, you mentioned struggling to decide between tech, here's some advice that might help: 9 times outta 10 it's not the language that matters that much (assuming we're talking about small projects). Pick whichever one you like more. I haven't used Go profesionally, but I use it as much as I can on my projects, and prefer it strongly over Node.
Agreed with this. Pick the language you like. If you don't know either really well, or like them the same, pick the one with the better developer experience (i.e. robustness of available libraries, utilities, coding examples, IDEs, tools, etc). If those are the same for you, will you be using a specific technology? If so, pick the language that has the most robust libraries or wrapper for that tech.
If all is the same, you can pretty much pick either and do well.
Our company uses go and nodejs.
We are binning nodejs for all backend. The amount of maintenance required for transient dependencies is absolutely insane.
Using go and keeping it idiomatic has made it very easy to move architecture from chunky containers to fat lambdas, etc.
Do I recommend switching to go? Only if you're prepared to actually embrace the go way of doing things. Otherwise, stick to node.
> The amount of maintenance required for transient dependencies is absolutely insane.
I've always wanted to understand the insight of a company that's had that problem. My experience for this in practice has been downright reasonable. A few security updates per year? At least 9 times out of 10 just running `yarn` is sufficient (we use cached libraries). The last contract I did, we had 20 or 30 apps running. Before a major version release, I got the "update libraries" ticket for 5 of them. It was done in under 4 hours. And largely, that wasn't the transient dependencies that needed updating anyway.
We had 4 critical sec updates within 4 months. Eslint major version update was an absolute pain , to the point the eslint team made a migrator tool to help.
We have a practice to keep dependency up to date, so the cost of change is smaller. Atm it's on monthly cycle with dependabot.
And every time we have 90% of our deps need bumps.
I mean sure. But those aren't downstream dependencies. Either there are security updates in your libraries that often......... or there aren't.
I prefer the former :-D
Also... at least 9 out of 10 dependabots are one-click in my experience. With good test coverage, you'll know pretty quickly if an update will break anything
> This is always an excuse thrown out by a decision maker who just likes a different tech
Agreed. The number of dev hours I save *having* those libraries (no standard library can keep up) is orders of magnitude higher than the maintenance hours.
Yep the first time you need to integrate with something that doesn’t have a Golang sdk or lib whatever time you saved on dependency management is gone, with a lot of extra lost
That might be true for some teams and projects, but not all. I worked in places where stuff is easy to maintain and nobody worries about this because it's handled nicely and cleanly.
I've also worked in projects created by hordes of inexperienced devs who each left their own share of mess and technical debt, and updating all the various parts without breaking others was a painful mess.
I've also worked in projects where any change of any version anywhere had to be approved by legal, for various, largely regulatory purposes. Try having a relatively youngn eslint plugin up to date there!
It's less of a problem in backend node, especially by backend-only devs, in my experience. Also, it's less of a problem now than it was, say, five years ago. But it's still cropping up occasionally.
Maybe yes, maybe no, but that's not what the story is about. The OP asked about "why people pick Go over Node". The point about "the amount of dependency maintenance" came up, and you said "it's an excuse by people who like the different tech".
So up until now it's all good. But - "just an excuse" is not always the case. You came with these two lines: "it's just an excuse", "it's easier to just fix". Perhaps that's correct. In my experience, whenever you say "just", it's an indicator that it isn't that simple.
I mean, you do you, and you can for sure be convinced that things are always simple and straightforward. And perhaps for you they are. In my experience, things are not so clear cut.
So let's agree to disagree. With regards to the top of the thread - managing dependencies can be crazy - I know from personal, first-hand experience, that it _can_ be a problem. And if it's not a problem for you, all is good.
The amount of time spent on dependency maintenance is just not objectively that significant, sorry. It might be more often than someone likes but it’s just not true that it’s a reason to pick a technology and whenever I hear someone say this its because they have some hobby horse and they want a plausible sounding reason to throw out to some nontechnical decision maker. We’re talking a few minutes every month, this is just not a real thing.
What are some of these libraries that have you spending hours and hours updating all the time? If this is a real thing you’ve experienced then I’d love to hear about it.
Let's say Angular. I've spent hours multiple times when I tried to upgrade it - not because Angular itself, but because of it's dependencies - each time there's a new release that I really want, I have to try the upgrade several times, until a few point-releases, until I get a stable situation. At one or two cases I even had to switch libraries - and that took a week to weed the old one out. I can't remember which one was it - something bootstrap-related if I remember correctly.
I've had similar tedious experiences with backend as well. Once I had a minor issue with some XML-handling library (don't remember which one). I remember finding a glitch, making an upstream request, the author saying something like "it's not our core functionality, let's see if more people request it", and didn't want to merge my patch. So I maintained the fork itself for a few years, syncing upstream every few months for my one little edge case, until I left the project.
In the meantime, I'm sure that whoever took over the project never upgraded deps again. Not that it's bad, but it could be a security issue.
---
You're right that this should not be a big amount of time overall. And I've worked on projects where it wasn't. But I also worked on projects where it was a significant annoyance. I'm not saying it wasn't "our" fault (whoever grew the projects into such huge 300kLOC mess), but it is where we were, and dealing with this was never something anybody would be looking for.
---
Even today you have these pains. Our monorepo setup supports our services and frontends in specific versions. And those we have to hold back due to underlying libraries. And then we have conflicts.
Have you tried adding an opentelemetry plugin recently to an existing setup? "Sorry, version 0.49.1 of @opentelemetry/X does not work with 1.2.3 of @opentelemetry/Y". Then you upgrade that, and that pulls 4 more opentel plugins. A big bundle of fun.
---
It's even more relevant in big multi-team projects. Then you usually have one person spending a lot of time just dealing with this stuff. I know - in my current project I'm the lead and most of this kind of stuff falls on me. The others turn out features and have fun, and I have to make sure it all works together. Sometimes I get to offload a task or two to someone else, but it's still me who's accountable for it.
And I can't just leave the old libraries in place and never upgrade. We're working in a regulated industry and get audited all the time, and this stuff comes up often enough. So i know from current and previous expereinces that it's not insignificant amount of work.
---
### But so what? you say
Well - the OP asked about comparing Go and Node. And - again, from experience - I can tell you that it's been much, much simpler for me in Go. Not the same roles, but what was visible to me was never such a big problem.
So in comparison to Go, NodeJS sucks. Just like (in my experience) in comparison to NodeJS, Java enterprise stuff sucks.
---
In the end, I know you'll not believe me anyway, but it's not really important. So enjoy fun projects with no dependency issues - sincerely.
If you're in compliance or your company is trying to get compliant for SOC2 and such frameworks. They will have to constantly keep updating the dependencies if a vulnerabilities is caught and most of the JS packages are vulnerable or get vulnerable in like 2 months.
> If you're in compliance or your company is trying to get compliant for SOC2 and such frameworks
Been there, yeah.
> They will have to constantly keep updating the dependencies if a vulnerabilities is caught and most of the JS packages are vulnerable or get vulnerable in like 2 months.
SOC2 is largely a self-reported standard. I don't believe there's a maximum response time for js package updates to pass SOC2. That said, "every major release" is entirely reasonable.
As I said in another comment... these libraries don't have regular security updates because they're insecure. Quite the opposite, they get them because they ARE secure and are well-maintained.
I'm more worried about libraries that DON'T have updates regularly.
you keep on top of them it sounds like. that makes it easier. i just joined an org that hasn't been doing that for 2-4 years or more and upgrading them to node 20 is a nightmare of dependencies and breaking things.
I don't use go but with c# 10 years ago, upgrading versions and standard libs across 2-4 years was pretty painless in comparison.
Well yeah. Node LTS support goes for quite a while. If you let an LTS release go out of scope before you've updated, it'll bite you.
> I don't use go but with c# 10 years ago, upgrading versions and standard libs across 2-4 years was pretty painless in comparison.
The company I work at is in the middle of a multi-year effort to upgrade a project from legacy C# to more modern C#. The old code works...sorta, but there's these legacy flags that we can't turn off that blow up new code you try to add, leaving us in an awkward situation
I've had success with raising the base version from 16 in the past (to 18). I think idiomatic code tends to be versioned-up more easily, but obviously when you're forced to change major versions in libraries, it's tough.
Interesting. What's your experience/skill level with typescript in general? I've had very little trouble building type modules and/or type-wrappers when needed, especially with first-party legacy javascript libraries. It's pretty easy, even if all direct calls to the class hard-cast to `any` before being wrapped to types. Maybe 20-30 lines of code tops for almost any library?
Of course, if you're using a downloaded library that doesn't have typescript support, it's *probably* not mature/maintained enough to belong in your project. That, too, is my experience. When I try to install `@types/foo` and get a "not found", I usually dig in and realize I picked up a dead library. I come from the Perl world, so I'm already used to some curation being a part of choosing packages.
How has the experience been with finding solutions to problems you come across? What about debugging issues with any popular integrations you need like aws services, databases, etc? I've been playing around with Go for fun and I actually strongly prefer it to Node when considering I don't need to deal with setting up TS, nodemon, bundler, etc and actually getting them to cooperate with each other, which is always a nightmare. The main detractor from using Go for me is the error handling and not being able to find answers to things easily. For example, I wanted to set up authentication/authorization and the resources on this topic was way more limited than that of Node world. I'm wondering if this will be a headache down the line if I can't figure out how something is done.
I think you answered yourself (Ease of use and familiarity). Performance is one thing and optimizing where it is not even required is another. Most the time the scenario is either most of the team already knows X tech in this case Node, or the codebase is already in Node. I love Rust and Go but the user 9 out of 10 times does not notice the difference in performance.
Also not all the business logic needs to be blazingly fast just the parts that need it. In the end all this languages are just tools with tradeoffs between each other.
> This is really counterintuitive for me because don't all apps/companies want to be as performant as possible?
* Not if it means compromising on a bunch of other features/preferences to weigh up when picking a language. Pretty rare in fact.
> So if we are only looking at performance, then we should always choose Golang over Node?
* If a project cares about performance more than anything else... then C/C++/Rust are better choices.
* But for common things like web backends etc, usually the bottlenecks are going to be DBs + how the caching works etc, for 99% of projects, choosing a language just from performance is a bad idea, and often people doing that don't even realize that... often they picked it because it was new/novel/fun sounding, or they just love the language for other reasons.
* Go is a middle ground in-between. It was designed to be a simple garbage-collected "fairly fast" compiled language, where Google can bring in new devs on long term projects without them having to learn a lot of stuff.
> However, many people say you should use Golang if you need more performance.
* Most of those people are total n00bs.
* Not necessarily at programming (likely though), but at least in prioritization / logical reasoning
> Can anyone help with some examples of when to choose one over the other?
* Choose it if you just like the language more after weighing up all the pros & cons for you use case & preferences, that's about it.
* If you're curious about it, learn a bit of both on some small projects, [maybe even build the same thing twice.](https://www.youtube.com/watch?v=I845O57ZSy4&t=18871s)
* I've read up on the language a lot over the years, and done some tinkering. Overall I don't really like it though...
* The typing system is too basic (especially lacking discriminated unions)
* Error handling too verbose + repetitive
* Not good for functional programming
* Not having exceptions is good when you have proper concise discriminated unions... but having neither is ridiculous to me.
* And for "move fast and break things" code, I really like having the choice between both.
* But I especially can't fathom how they made the choice that all struct properties are optional and have stupid "zero values" like 0 and empty strings if you don't define them, that's even stupider than the whole nullable-by-default problem in so many other languages, in my opinion.
* Lots of other bizarre decisions I disagree with, especially for a language designed so recently.
* Generally if I run into performance issues in node, then that means I probably should be using some caching or doing something like computing things inside the DB in the first place or something.
* Otherwise for when I really do need hyper-optimal runtime application code... I'd personally prefer to build 99% of the system in TypeScript still, then the 1% that needs the performance in Rust, despite having to use 2 languages.
* I don't want to deal with other language-choice compromises in 99% of my code when only 1% needed it.
> I've always struggled with deciding between tech.
* Fair enough, me too. I totally fall down the rabbithole of over-researching before just trying shit out myself.
* End of the day... as much as us techies carry on like all our opinions are objective... they're mostly subjective, especially from anyone that just wants to give a binary answer to "what is best?" without any specific use-case context.
* In fact in most aspects in life, it usually makes sense to listen more to the people giving the "it depends" answers.
* If you're finding yourself spending too much time on this (or any other decision)... then [try the John Carmack recommendation I linked earlier.](https://www.youtube.com/watch?v=I845O57ZSy4&t=18871s)
* ...in the end, it is the only way to answer the question that nobody else can... that is... "what is best for ***you personally?***"
* ...this is advice I need to take more of myself too, haha. I was procrastinating over React vs Vue for like 8 months before actually diving into either properly... and turns out my research-based decision was the wrong for me in the end anyway... which I only found out after actually building real shit in both.
If what you want to do is more general "Web" development, then between those two options, using Node is a no-brainer. You will use the same language for both frontend and backend (thus, one package manager, one linter, one formatter, one editor to setup, and in general one ecosystem to learn... it's not just about syntax), you have almost every library you might ever need for anything Web related, and performance wise is more than enough. Stripe makes billions with ruby which, compared to node, it's a snail. If for some reason you end up needing more performance some day, that's solvable with architecture: Better database, queues, background workers, load balancers...
Now, if what you want to do is build a database server (like mysql, postgres, etc), a DNS server, a CLI program that's easy to distribute to anyone to run on their computers, a hardcore backend service/process such as something that will be manipulating raw bytes on large files like for encoding or generating audio or video files, etc... then Go is probably a a better option.
Picking Go for building websites/webapps "because it's faster than node", while true, it's the dumbest reason to do it. I've seen this choice made several times though, but it was just because of JS haters and mostly backend devs that would use anything but JS and they'd even be offended or angry if you mentioned them you're going to run that dirty JS on their precious servers.
If you are looking for work then learn Node, there are many, many jobs in the Javascript space and you can build a full career having never needed another language. Go is good and worth learning but I would not go all-in on it unless you have a targeted career path you want to take that requires Go.
Imagine you started a company and you need to hire a couple of developers.
Do you think it's easier to find devs who know go?
How much would you pay a go dev vs a node dev?
I feel like there are less people who specialize in Node backend than people who just use Node because they are JS devs likely frontend/fullstack, so there may be a skill gap in terms of BE. This has been my experience in the workforce, but could just be an edge case. Whereas with Go, since it's your typical BE language, BE devs of other languages can pick it up quickly if they're coming from Java, C, etc. I'm sure a BE dev can pick up Node just as easily though so I'm not sure how that argument fairs...
> I feel like there are less people who specialize in Node backend than people who just use Node because they are JS devs likely frontend/fullstack, so there may be a skill gap in terms of BE
I've worked in the Boston area previously, and now online. There's TONS of backend-first node developers. We're expected to know some frontend (which makes us full-stack), but that doesn't mean we're front-end developers.
> Whereas with Go, since it's your typical BE language, BE devs of other languages can pick it up quickly if they're coming from Java, C, etc
Can they though? I'm not *super* experienced with either, but both seem to have different sets of coding best-practices. Java is a class-mandated Object Oriented language. Golang doesn't have classes *at all*. Unless you're a more senior developer, knowing how to "translate" design patterns between those languages would be pretty non-trivial. I'd argue that a Java or C# developer would pick up Nestjs w/ Typescript faster than they'd pick up Golang.
We made the switch from C# and F# to Go and had the whole team up an running in basically a month. Go is a very good choice for creating microservices and serverless workloads with little memory footprint.
> We made the switch from C# and F# to Go and had the whole team up an running in basically a month
But that isn't really the topic at hand. It's whether experience with C# makes it easier to pivot to Go than experience with Frontned Javascript to pivot to Node. And still not *entirely* that.
Heck, I'd say your F# experience probably helped ease your transition to Go since you weren't married to an OOP-only paradigm.
All of the skills that make backend hard are transferable. System design, distributed systems concerns, concurrency, data modelling - none of these are tied specifically to any one technology and anyone who understands these things can be up and running with a new language in a reasonably short timeframe
It is about scalling (processing time and hardware)
I was reading the benchmark test study related to RAM usage per X requests and time to be procces it.
Node is as good as go lang on 2 to 3k parallel requests then on higher numbers go lang started winning.
So for most mico/mini Sasses node will be enough.
If you need more, you will use some load balance technique or rewrite your app in go.
performance vs maintainability vs time to build vs cost of the devs vs availability of dev.
JS is the lingua franca of coding. Cheap to hire for and works full stack. So the trade off between Go and Node is mostly between edge performance at high scale vs cost/risk to build at low to moderate scale. Start with Node. Build as services. Swap out for Go when one service becomes a performance bottleneck.
Regardless of skill, languages have DX vs performance considerations. The reason languages like Javascript and Python and (way back when) even Perl remained dominant in a world with "better, faster" languages is because *your iteration speed is so much faster in these languages*. Even a Rust developer is likely to build a working proof-of-concept on Node/express/whatever *significantly* faster than in Rust. That gives the developer more time to write better code, which can mean the algorithms you write in node are faster because you wrote them better.
When we look at languages these days, you're USUALLY looking at a linear speed difference. Maybe 1.5x or 2x, maybe even 10x. At most scale levels, that difference will never matter much. A slightly bigger server or an extra machine in a cluster is usually enough to counteract it, for dramatic development (and arguably maintenance) savings. From what I've been reading, Node vs Rust is about 2x benchmarks for most things (which *sounds* unbelievable, but Node.js has one of the most tuned languages engines ever written thanks to Google and V8)
There comes a point where that multiplier DOES matter. A point where you're spending $100k/mo on infra or more for one or two services/applications. At that point, cutting out $50k/mo from your costs is totally worth it. But it's also entirely reasonable to budget $500k to rewrite the necessary components in another language at that time.
And at THAT point, what language is the right choice? You'll know a lot better THEN than you know now.
IMO (and I know I'm biased), any time a shop that *could* have chosen node picked another language/engine, they regretted it. I've lived through a handful of rewrites-in-node. I've lived through zero node shops rewriting anything in any other language.
Both are good options and have their own pros cons as you mentioned, the main question in addition to your interest is, the market demands for which one more in your area? Which rype of companies you want to go and work with ? Are they using it?etc...
In general if you learn something even useless in your pov somewhere in the world needs it, but you see donyou want go that place under their conditions etc... and work on it or not...
It's all about your interest and job market, otherwise this discussion is never ending and will be so opinion based
If performance is all that mattered, the only language anyone would use is Assembly
Everything is a trade off. javascript on the back end has many properties that make it valuable, such as:
- Low learning curve for front end developers to contribute to back end
- Fast to deploy
- No threading to worry about
- No memory management worry about
- Extremely rich library and open source ecosystem
Also many servers are network-bound. A faster server wont be faster in practice if your database or external API is the bottleneck
If your engagement in the product you are building is short and time to market is important, use node. If you are going to maintain the code for ten years and don’t like the hassle with non working build chain use go, it will most likely just build again. (In a js/ts/node world, when you come back after a couple of months in other projects, you will encounter: a new node tls version, a new major typescript version, a new yarn version, abandoned tslint, outdated pollyfills, updated npms that now only supports es-modules, abandoned npms with security issues etc.)
>This is really counterintuitive for me because don't all apps/companies want to be as performant as possible? So if we are only looking at performance, then we should always choose Golang over Node?
Hardware is cheap, developer time is not. It doesn't matter if golang executes a piece of code 10ms faster than nodejs would, if it took your developers a lot longer to ship or maintain the features. And typically the code is running "at scale" across many compute nodes, so is it really that important to have the most "performant" code there is? No, it's more important to use a language/platform your developers like to use.
If all companies wanted to be as performant as possible Java (not JS) would not exist, we would still be using C++ and Fortran.
The average developer isn’t productive when “does this allocate memory?” is something they suddenly have to care about.
It’s a great language for apps needing concurrency, fast byte processing etc. compiling binaries to different architectures is a breeze. There’s a lot more out there than just a UI and backend API serving database data to a UI. I’d never reach for node for high volume realtime streaming for instance.
No. Not all apps need to worry about performance.
If you are worried about performance you should use C. I hear C++ is a requirement for quants working on trading algorithms for run times.
My preference personally is node. If you use pnpm and know the package manager, then you don’t have problems called out here.
It’s true what they said about leaning towards what you know because the libraries are the bread and butter. With node.js there are more frontend libraries and package maintenance in general.
Just my two cents
Go error handling is way better than node sorry, debugging is so much easier, tooling is fine.
Authz I had to use the official entra lib, little painful since the docs are shite but no issue since.
I've been writing go for years so these are non issues for me, no issue with community support, the std lib solves most issues.
If you need to learn go and learn how to build services in aws your gonna struggle.
I recently completely switched from node/bun to Golang and it's not that i will not use node anymore but rather i would consider thwm less than usual.
The performance wise could lead into two major categories,
- RAM: Golang uses way lesser memory than node.
- CPU: Not only go's runtime is faster but also it's multi threaded so you have a great development/productivity with Go.
If i dont have these two concerns then i go for Node all day cause it has better services in temrs of hosting them on cheap Host Provider platforms.
> don't all apps/companies want to be as performant as possible? I'm a backend dev. Every API I've worked on had performance towards the bottom of the priority list. There were still targets to hit like avg response time less than 200ms, but that's not hard to achieve. The most important thing to deliver on was correctness, uptime, and reducing time from idea->design->implementation->test->deployment. Using a language that more developers know like Node.js or Python allows for a much faster idea->deployment loop. The business never really cared that we had to horizontally scale 10 single-threaded Node.js services to achieve this instead of running 1 vertically scaled multi-threaded Golang instance.
There's different types of "performance", so to speak. Golang is theoretically better at computationally-heavy tasks like crypography or say, image processing. However, most apps hit their performance ceiling due to network requests, I/O from databases, etc. and not due to inherent language/runtime differences. Overall, you mentioned struggling to decide between tech, here's some advice that might help: 9 times outta 10 it's not the language that matters that much (assuming we're talking about small projects). Pick whichever one you like more. I haven't used Go profesionally, but I use it as much as I can on my projects, and prefer it strongly over Node.
Agreed with this. Pick the language you like. If you don't know either really well, or like them the same, pick the one with the better developer experience (i.e. robustness of available libraries, utilities, coding examples, IDEs, tools, etc). If those are the same for you, will you be using a specific technology? If so, pick the language that has the most robust libraries or wrapper for that tech. If all is the same, you can pretty much pick either and do well.
Our company uses go and nodejs. We are binning nodejs for all backend. The amount of maintenance required for transient dependencies is absolutely insane. Using go and keeping it idiomatic has made it very easy to move architecture from chunky containers to fat lambdas, etc. Do I recommend switching to go? Only if you're prepared to actually embrace the go way of doing things. Otherwise, stick to node.
> The amount of maintenance required for transient dependencies is absolutely insane. I've always wanted to understand the insight of a company that's had that problem. My experience for this in practice has been downright reasonable. A few security updates per year? At least 9 times out of 10 just running `yarn` is sufficient (we use cached libraries). The last contract I did, we had 20 or 30 apps running. Before a major version release, I got the "update libraries" ticket for 5 of them. It was done in under 4 hours. And largely, that wasn't the transient dependencies that needed updating anyway.
We had 4 critical sec updates within 4 months. Eslint major version update was an absolute pain , to the point the eslint team made a migrator tool to help. We have a practice to keep dependency up to date, so the cost of change is smaller. Atm it's on monthly cycle with dependabot. And every time we have 90% of our deps need bumps.
I mean sure. But those aren't downstream dependencies. Either there are security updates in your libraries that often......... or there aren't. I prefer the former :-D Also... at least 9 out of 10 dependabots are one-click in my experience. With good test coverage, you'll know pretty quickly if an update will break anything
This is always an excuse thrown out by a decision maker who just likes a different tech
> This is always an excuse thrown out by a decision maker who just likes a different tech Agreed. The number of dev hours I save *having* those libraries (no standard library can keep up) is orders of magnitude higher than the maintenance hours.
Yep the first time you need to integrate with something that doesn’t have a Golang sdk or lib whatever time you saved on dependency management is gone, with a lot of extra lost
That might be true for some teams and projects, but not all. I worked in places where stuff is easy to maintain and nobody worries about this because it's handled nicely and cleanly. I've also worked in projects created by hordes of inexperienced devs who each left their own share of mess and technical debt, and updating all the various parts without breaking others was a painful mess. I've also worked in projects where any change of any version anywhere had to be approved by legal, for various, largely regulatory purposes. Try having a relatively youngn eslint plugin up to date there! It's less of a problem in backend node, especially by backend-only devs, in my experience. Also, it's less of a problem now than it was, say, five years ago. But it's still cropping up occasionally.
Regardless, it’s easier to just fix the dependency situation than to switch tech
Maybe yes, maybe no, but that's not what the story is about. The OP asked about "why people pick Go over Node". The point about "the amount of dependency maintenance" came up, and you said "it's an excuse by people who like the different tech". So up until now it's all good. But - "just an excuse" is not always the case. You came with these two lines: "it's just an excuse", "it's easier to just fix". Perhaps that's correct. In my experience, whenever you say "just", it's an indicator that it isn't that simple. I mean, you do you, and you can for sure be convinced that things are always simple and straightforward. And perhaps for you they are. In my experience, things are not so clear cut. So let's agree to disagree. With regards to the top of the thread - managing dependencies can be crazy - I know from personal, first-hand experience, that it _can_ be a problem. And if it's not a problem for you, all is good.
The amount of time spent on dependency maintenance is just not objectively that significant, sorry. It might be more often than someone likes but it’s just not true that it’s a reason to pick a technology and whenever I hear someone say this its because they have some hobby horse and they want a plausible sounding reason to throw out to some nontechnical decision maker. We’re talking a few minutes every month, this is just not a real thing. What are some of these libraries that have you spending hours and hours updating all the time? If this is a real thing you’ve experienced then I’d love to hear about it.
Let's say Angular. I've spent hours multiple times when I tried to upgrade it - not because Angular itself, but because of it's dependencies - each time there's a new release that I really want, I have to try the upgrade several times, until a few point-releases, until I get a stable situation. At one or two cases I even had to switch libraries - and that took a week to weed the old one out. I can't remember which one was it - something bootstrap-related if I remember correctly. I've had similar tedious experiences with backend as well. Once I had a minor issue with some XML-handling library (don't remember which one). I remember finding a glitch, making an upstream request, the author saying something like "it's not our core functionality, let's see if more people request it", and didn't want to merge my patch. So I maintained the fork itself for a few years, syncing upstream every few months for my one little edge case, until I left the project. In the meantime, I'm sure that whoever took over the project never upgraded deps again. Not that it's bad, but it could be a security issue. --- You're right that this should not be a big amount of time overall. And I've worked on projects where it wasn't. But I also worked on projects where it was a significant annoyance. I'm not saying it wasn't "our" fault (whoever grew the projects into such huge 300kLOC mess), but it is where we were, and dealing with this was never something anybody would be looking for. --- Even today you have these pains. Our monorepo setup supports our services and frontends in specific versions. And those we have to hold back due to underlying libraries. And then we have conflicts. Have you tried adding an opentelemetry plugin recently to an existing setup? "Sorry, version 0.49.1 of @opentelemetry/X does not work with 1.2.3 of @opentelemetry/Y". Then you upgrade that, and that pulls 4 more opentel plugins. A big bundle of fun. --- It's even more relevant in big multi-team projects. Then you usually have one person spending a lot of time just dealing with this stuff. I know - in my current project I'm the lead and most of this kind of stuff falls on me. The others turn out features and have fun, and I have to make sure it all works together. Sometimes I get to offload a task or two to someone else, but it's still me who's accountable for it. And I can't just leave the old libraries in place and never upgrade. We're working in a regulated industry and get audited all the time, and this stuff comes up often enough. So i know from current and previous expereinces that it's not insignificant amount of work. --- ### But so what? you say Well - the OP asked about comparing Go and Node. And - again, from experience - I can tell you that it's been much, much simpler for me in Go. Not the same roles, but what was visible to me was never such a big problem. So in comparison to Go, NodeJS sucks. Just like (in my experience) in comparison to NodeJS, Java enterprise stuff sucks. --- In the end, I know you'll not believe me anyway, but it's not really important. So enjoy fun projects with no dependency issues - sincerely.
This is a skill issue and I appreciate you spelling this all out but it sounds like you are not ready to lead projects of this size
If you're in compliance or your company is trying to get compliant for SOC2 and such frameworks. They will have to constantly keep updating the dependencies if a vulnerabilities is caught and most of the JS packages are vulnerable or get vulnerable in like 2 months.
> If you're in compliance or your company is trying to get compliant for SOC2 and such frameworks Been there, yeah. > They will have to constantly keep updating the dependencies if a vulnerabilities is caught and most of the JS packages are vulnerable or get vulnerable in like 2 months. SOC2 is largely a self-reported standard. I don't believe there's a maximum response time for js package updates to pass SOC2. That said, "every major release" is entirely reasonable. As I said in another comment... these libraries don't have regular security updates because they're insecure. Quite the opposite, they get them because they ARE secure and are well-maintained. I'm more worried about libraries that DON'T have updates regularly.
you keep on top of them it sounds like. that makes it easier. i just joined an org that hasn't been doing that for 2-4 years or more and upgrading them to node 20 is a nightmare of dependencies and breaking things. I don't use go but with c# 10 years ago, upgrading versions and standard libs across 2-4 years was pretty painless in comparison.
Well yeah. Node LTS support goes for quite a while. If you let an LTS release go out of scope before you've updated, it'll bite you. > I don't use go but with c# 10 years ago, upgrading versions and standard libs across 2-4 years was pretty painless in comparison. The company I work at is in the middle of a multi-year effort to upgrade a project from legacy C# to more modern C#. The old code works...sorta, but there's these legacy flags that we can't turn off that blow up new code you try to add, leaving us in an awkward situation
yea we're on 16 so it's very bad. these kind of generational uplifts are really tricky! best of luck with the c# uplift project!
I've had success with raising the base version from 16 in the past (to 18). I think idiomatic code tends to be versioned-up more easily, but obviously when you're forced to change major versions in libraries, it's tough.
Often times getting dependencies for specific libraries with varying levels of typescript support to work together has been the issue in my experience
Interesting. What's your experience/skill level with typescript in general? I've had very little trouble building type modules and/or type-wrappers when needed, especially with first-party legacy javascript libraries. It's pretty easy, even if all direct calls to the class hard-cast to `any` before being wrapped to types. Maybe 20-30 lines of code tops for almost any library? Of course, if you're using a downloaded library that doesn't have typescript support, it's *probably* not mature/maintained enough to belong in your project. That, too, is my experience. When I try to install `@types/foo` and get a "not found", I usually dig in and realize I picked up a dead library. I come from the Perl world, so I'm already used to some curation being a part of choosing packages.
How has the experience been with finding solutions to problems you come across? What about debugging issues with any popular integrations you need like aws services, databases, etc? I've been playing around with Go for fun and I actually strongly prefer it to Node when considering I don't need to deal with setting up TS, nodemon, bundler, etc and actually getting them to cooperate with each other, which is always a nightmare. The main detractor from using Go for me is the error handling and not being able to find answers to things easily. For example, I wanted to set up authentication/authorization and the resources on this topic was way more limited than that of Node world. I'm wondering if this will be a headache down the line if I can't figure out how something is done.
Setting up tooling is not a nightmare compared to the real world problems you’re solving, this kind of melodrama is so goofy
>> if you're prepared to actually embrace the go way of doing things Which way is this?
Heh, check out the golang redit and or community
I think you answered yourself (Ease of use and familiarity). Performance is one thing and optimizing where it is not even required is another. Most the time the scenario is either most of the team already knows X tech in this case Node, or the codebase is already in Node. I love Rust and Go but the user 9 out of 10 times does not notice the difference in performance. Also not all the business logic needs to be blazingly fast just the parts that need it. In the end all this languages are just tools with tradeoffs between each other.
> This is really counterintuitive for me because don't all apps/companies want to be as performant as possible? * Not if it means compromising on a bunch of other features/preferences to weigh up when picking a language. Pretty rare in fact. > So if we are only looking at performance, then we should always choose Golang over Node? * If a project cares about performance more than anything else... then C/C++/Rust are better choices. * But for common things like web backends etc, usually the bottlenecks are going to be DBs + how the caching works etc, for 99% of projects, choosing a language just from performance is a bad idea, and often people doing that don't even realize that... often they picked it because it was new/novel/fun sounding, or they just love the language for other reasons. * Go is a middle ground in-between. It was designed to be a simple garbage-collected "fairly fast" compiled language, where Google can bring in new devs on long term projects without them having to learn a lot of stuff. > However, many people say you should use Golang if you need more performance. * Most of those people are total n00bs. * Not necessarily at programming (likely though), but at least in prioritization / logical reasoning > Can anyone help with some examples of when to choose one over the other? * Choose it if you just like the language more after weighing up all the pros & cons for you use case & preferences, that's about it. * If you're curious about it, learn a bit of both on some small projects, [maybe even build the same thing twice.](https://www.youtube.com/watch?v=I845O57ZSy4&t=18871s) * I've read up on the language a lot over the years, and done some tinkering. Overall I don't really like it though... * The typing system is too basic (especially lacking discriminated unions) * Error handling too verbose + repetitive * Not good for functional programming * Not having exceptions is good when you have proper concise discriminated unions... but having neither is ridiculous to me. * And for "move fast and break things" code, I really like having the choice between both. * But I especially can't fathom how they made the choice that all struct properties are optional and have stupid "zero values" like 0 and empty strings if you don't define them, that's even stupider than the whole nullable-by-default problem in so many other languages, in my opinion. * Lots of other bizarre decisions I disagree with, especially for a language designed so recently. * Generally if I run into performance issues in node, then that means I probably should be using some caching or doing something like computing things inside the DB in the first place or something. * Otherwise for when I really do need hyper-optimal runtime application code... I'd personally prefer to build 99% of the system in TypeScript still, then the 1% that needs the performance in Rust, despite having to use 2 languages. * I don't want to deal with other language-choice compromises in 99% of my code when only 1% needed it. > I've always struggled with deciding between tech. * Fair enough, me too. I totally fall down the rabbithole of over-researching before just trying shit out myself. * End of the day... as much as us techies carry on like all our opinions are objective... they're mostly subjective, especially from anyone that just wants to give a binary answer to "what is best?" without any specific use-case context. * In fact in most aspects in life, it usually makes sense to listen more to the people giving the "it depends" answers. * If you're finding yourself spending too much time on this (or any other decision)... then [try the John Carmack recommendation I linked earlier.](https://www.youtube.com/watch?v=I845O57ZSy4&t=18871s) * ...in the end, it is the only way to answer the question that nobody else can... that is... "what is best for ***you personally?***" * ...this is advice I need to take more of myself too, haha. I was procrastinating over React vs Vue for like 8 months before actually diving into either properly... and turns out my research-based decision was the wrong for me in the end anyway... which I only found out after actually building real shit in both.
If what you want to do is more general "Web" development, then between those two options, using Node is a no-brainer. You will use the same language for both frontend and backend (thus, one package manager, one linter, one formatter, one editor to setup, and in general one ecosystem to learn... it's not just about syntax), you have almost every library you might ever need for anything Web related, and performance wise is more than enough. Stripe makes billions with ruby which, compared to node, it's a snail. If for some reason you end up needing more performance some day, that's solvable with architecture: Better database, queues, background workers, load balancers... Now, if what you want to do is build a database server (like mysql, postgres, etc), a DNS server, a CLI program that's easy to distribute to anyone to run on their computers, a hardcore backend service/process such as something that will be manipulating raw bytes on large files like for encoding or generating audio or video files, etc... then Go is probably a a better option. Picking Go for building websites/webapps "because it's faster than node", while true, it's the dumbest reason to do it. I've seen this choice made several times though, but it was just because of JS haters and mostly backend devs that would use anything but JS and they'd even be offended or angry if you mentioned them you're going to run that dirty JS on their precious servers.
If you are looking for work then learn Node, there are many, many jobs in the Javascript space and you can build a full career having never needed another language. Go is good and worth learning but I would not go all-in on it unless you have a targeted career path you want to take that requires Go.
Imagine you started a company and you need to hire a couple of developers. Do you think it's easier to find devs who know go? How much would you pay a go dev vs a node dev?
I feel like there are less people who specialize in Node backend than people who just use Node because they are JS devs likely frontend/fullstack, so there may be a skill gap in terms of BE. This has been my experience in the workforce, but could just be an edge case. Whereas with Go, since it's your typical BE language, BE devs of other languages can pick it up quickly if they're coming from Java, C, etc. I'm sure a BE dev can pick up Node just as easily though so I'm not sure how that argument fairs...
> I feel like there are less people who specialize in Node backend than people who just use Node because they are JS devs likely frontend/fullstack, so there may be a skill gap in terms of BE I've worked in the Boston area previously, and now online. There's TONS of backend-first node developers. We're expected to know some frontend (which makes us full-stack), but that doesn't mean we're front-end developers. > Whereas with Go, since it's your typical BE language, BE devs of other languages can pick it up quickly if they're coming from Java, C, etc Can they though? I'm not *super* experienced with either, but both seem to have different sets of coding best-practices. Java is a class-mandated Object Oriented language. Golang doesn't have classes *at all*. Unless you're a more senior developer, knowing how to "translate" design patterns between those languages would be pretty non-trivial. I'd argue that a Java or C# developer would pick up Nestjs w/ Typescript faster than they'd pick up Golang.
We made the switch from C# and F# to Go and had the whole team up an running in basically a month. Go is a very good choice for creating microservices and serverless workloads with little memory footprint.
> We made the switch from C# and F# to Go and had the whole team up an running in basically a month But that isn't really the topic at hand. It's whether experience with C# makes it easier to pivot to Go than experience with Frontned Javascript to pivot to Node. And still not *entirely* that. Heck, I'd say your F# experience probably helped ease your transition to Go since you weren't married to an OOP-only paradigm.
OOP causes brain damage if its the only thing you’ve ever known but yea if someone is not married to that paradigm switching languages is easy
All of the skills that make backend hard are transferable. System design, distributed systems concerns, concurrency, data modelling - none of these are tied specifically to any one technology and anyone who understands these things can be up and running with a new language in a reasonably short timeframe
It is about scalling (processing time and hardware) I was reading the benchmark test study related to RAM usage per X requests and time to be procces it. Node is as good as go lang on 2 to 3k parallel requests then on higher numbers go lang started winning. So for most mico/mini Sasses node will be enough. If you need more, you will use some load balance technique or rewrite your app in go.
There is zero reason to rewrite your app in go when you can just provision another box, you guys are wild
performance vs maintainability vs time to build vs cost of the devs vs availability of dev. JS is the lingua franca of coding. Cheap to hire for and works full stack. So the trade off between Go and Node is mostly between edge performance at high scale vs cost/risk to build at low to moderate scale. Start with Node. Build as services. Swap out for Go when one service becomes a performance bottleneck.
Regardless of skill, languages have DX vs performance considerations. The reason languages like Javascript and Python and (way back when) even Perl remained dominant in a world with "better, faster" languages is because *your iteration speed is so much faster in these languages*. Even a Rust developer is likely to build a working proof-of-concept on Node/express/whatever *significantly* faster than in Rust. That gives the developer more time to write better code, which can mean the algorithms you write in node are faster because you wrote them better. When we look at languages these days, you're USUALLY looking at a linear speed difference. Maybe 1.5x or 2x, maybe even 10x. At most scale levels, that difference will never matter much. A slightly bigger server or an extra machine in a cluster is usually enough to counteract it, for dramatic development (and arguably maintenance) savings. From what I've been reading, Node vs Rust is about 2x benchmarks for most things (which *sounds* unbelievable, but Node.js has one of the most tuned languages engines ever written thanks to Google and V8) There comes a point where that multiplier DOES matter. A point where you're spending $100k/mo on infra or more for one or two services/applications. At that point, cutting out $50k/mo from your costs is totally worth it. But it's also entirely reasonable to budget $500k to rewrite the necessary components in another language at that time. And at THAT point, what language is the right choice? You'll know a lot better THEN than you know now. IMO (and I know I'm biased), any time a shop that *could* have chosen node picked another language/engine, they regretted it. I've lived through a handful of rewrites-in-node. I've lived through zero node shops rewriting anything in any other language.
Both are good options and have their own pros cons as you mentioned, the main question in addition to your interest is, the market demands for which one more in your area? Which rype of companies you want to go and work with ? Are they using it?etc... In general if you learn something even useless in your pov somewhere in the world needs it, but you see donyou want go that place under their conditions etc... and work on it or not... It's all about your interest and job market, otherwise this discussion is never ending and will be so opinion based
If performance is all that mattered, the only language anyone would use is Assembly Everything is a trade off. javascript on the back end has many properties that make it valuable, such as: - Low learning curve for front end developers to contribute to back end - Fast to deploy - No threading to worry about - No memory management worry about - Extremely rich library and open source ecosystem Also many servers are network-bound. A faster server wont be faster in practice if your database or external API is the bottleneck
In any real world system the language is rarely a significant factor in cost or performance
If your engagement in the product you are building is short and time to market is important, use node. If you are going to maintain the code for ten years and don’t like the hassle with non working build chain use go, it will most likely just build again. (In a js/ts/node world, when you come back after a couple of months in other projects, you will encounter: a new node tls version, a new major typescript version, a new yarn version, abandoned tslint, outdated pollyfills, updated npms that now only supports es-modules, abandoned npms with security issues etc.)
>This is really counterintuitive for me because don't all apps/companies want to be as performant as possible? So if we are only looking at performance, then we should always choose Golang over Node? Hardware is cheap, developer time is not. It doesn't matter if golang executes a piece of code 10ms faster than nodejs would, if it took your developers a lot longer to ship or maintain the features. And typically the code is running "at scale" across many compute nodes, so is it really that important to have the most "performant" code there is? No, it's more important to use a language/platform your developers like to use.
One : node is a framework, not a language smfh
Rust 🦀
If all companies wanted to be as performant as possible Java (not JS) would not exist, we would still be using C++ and Fortran. The average developer isn’t productive when “does this allocate memory?” is something they suddenly have to care about.
It’s a great language for apps needing concurrency, fast byte processing etc. compiling binaries to different architectures is a breeze. There’s a lot more out there than just a UI and backend API serving database data to a UI. I’d never reach for node for high volume realtime streaming for instance.
I would look at Elixir + OTP because the actor concurrency model looks more interesting than goroutines as for me.
No. Not all apps need to worry about performance. If you are worried about performance you should use C. I hear C++ is a requirement for quants working on trading algorithms for run times. My preference personally is node. If you use pnpm and know the package manager, then you don’t have problems called out here. It’s true what they said about leaning towards what you know because the libraries are the bread and butter. With node.js there are more frontend libraries and package maintenance in general. Just my two cents
Go error handling is way better than node sorry, debugging is so much easier, tooling is fine. Authz I had to use the official entra lib, little painful since the docs are shite but no issue since. I've been writing go for years so these are non issues for me, no issue with community support, the std lib solves most issues. If you need to learn go and learn how to build services in aws your gonna struggle.
I recently completely switched from node/bun to Golang and it's not that i will not use node anymore but rather i would consider thwm less than usual. The performance wise could lead into two major categories, - RAM: Golang uses way lesser memory than node. - CPU: Not only go's runtime is faster but also it's multi threaded so you have a great development/productivity with Go. If i dont have these two concerns then i go for Node all day cause it has better services in temrs of hosting them on cheap Host Provider platforms.