Comment by dakiol

Comment by dakiol 9 days ago

Don't get it. Is it because your Go app relies in fewer dependencies? If so, it's just a matter of numbers I believe. JS apps tend to rely on more dependencies on average... but that doesn't need to be that way. I have plain JS apps that still work like the first day (even better than Go apps, since there's no compilation step involved).

TypeScript apps on the other hand, yeah, they tend to be more fragile (at least from my perspective: the tsc package has dozen of dependencies, so anything can go wrong)

hnlmorg 9 days ago

You can do that in practically any language however that doesn’t mean it’s easy nor the norm.

JavaScript has a culture of move fast and break things. Whereas Go has a culture of moving slow and backwards compatibility.

It also helps that Go has a pretty extensive stdlibs whereas JavaScript is really more like several distinct language ecosystems wrapped around a common specification. So what works on one JavaScript runtime might not even work on another.

Reply View 0 replies

danenania 9 days ago

> but that doesn’t need to be that way

It kind of does though. If you need to do something with security implications, reinventing the wheel is usually higher risk than using a popular dependency. So it’s not like you can realistically avoid this issue. At least not without causing bigger problems.

It’s also not just a coincidence that Go apps have far fewer dependencies. The comprehensiveness of the std lib (along with officially maintained /x/ packages) means that you need fewer direct dependencies. And just as importantly for the overall size of the tree, all the dependencies that you do need themselves have fewer dependencies. This can easily mean an order of magnitude difference in total transitive dependencies for a significant project.

Reply View 0 replies