Hacker News new | past | comments | ask | show | jobs | submit login

> It's easy to learn and and great for getting something useful deployed pretty quickly

I'd argue node.js is even easier to learn and even better for getting something useful deployed faster.




Node.js is absurdly complex in typical deployment scenarios leading to serious difficulties when you're trying to create production apps. Let's just look at the common case of transpilation from TypeScript:

- Did your TypeScript properly import all of the @types packages required for it to compile properly? They need to be installed alongside the source packages and match the version numbers. They are often maintained separately and may not match the underlying implementation of the code.

- How do you run this in production? Do you check the compiled TypeScript into the git repo? Do you run with ts-node? Do you do different things in production, development, and test?

- Do all of your native dependencies support the node versions you're using? How do you install the correct version of node? If you ignore these issues by using Docker, how are you managing your images and containers?

The list of problems requiring solutions goes on and on. And of course those solutions exist, but this is a summary of why node projects are not "easy to learn". Don't get me wrong, Node can still be the right tool for the job, in particular if you're sharing a lot of code between an app and something that will run in the browser.


You missed-out debugging.


The advantage of nodejs over go for web apps is the live reload / recompile tool chain. golang has some really nice apis for back end servers, single binary, no runtime deployment is really great. But golang lacks in that live reload feedback loop.

I do a lot of golang but whenever I want to do something web browser facing, I cave in for nodejs. Especially in the exploratory phase when building front / back end together.


Having used both go and node, the go compile speed is fast enough that I don't really notice a difference.


With the compile speed of go i mostly could get into that same style of development as with dynamic languages. I think with generics this will get even closer, because of the plethora of libraries that will be released when generics land.


You can try to use https://github.com/githubnemo/CompileDaemon, it is pretty stable and just works at least on Linux/OSX.


Except Node.js doesn't have a proper stdlib. Big difference.


https://nodejs.org/api/documentation.html

Everything I've needed has always been a `require()` or `npm add` away.


That's my point - not in the stdlib if you have to `npm add`. It's not just the libs you import that are affected. Npm is arguably the size it is because the libraries it contains are not written against a stdlib. Certainly not front-end JS libs. That has a quality effect on the whole ecosystem.


If you want a single-binary utility, node has a disadvantage.


My understanding is that one can deploy go application simply by copying. Can't get much simpler than that.


I know it's not magic, but is so nice when I build my go utility on my Mac with a linux target, copy it and its config to a linux server, and it runs. After dealing with setting up java, node, and python envs for so many years, go is a breath of fresh air on the deployment side.


I've been doing native applications something like forever and all those apps are exactly the same way. Just copy and enjoy. I just do not understand fun of "modern" apps where the amount of tooling and configuration will drive one straight to insanity.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: