Comment by iends | Hacker News Reader

Comment by iends | Hacker News Reader

Parent Full thread

Some random thoughts as somebody who codes a lot of Node.js at work and a lot Go in my freetime (and sometimes at work):

Did you try using pprof and the other tooling go provides to better understand your performance limitations? Tooling is a lot better in go ecosystem for understanding CPU and memory consumption, so if/when you run into into issues with Node you're going to be in a world of pain (this is basically a large portion of my job in a large node.js code base in the $day_job). You'll basically have to resort to using lldb and heapdumps in the Node world. I'm surprised the number of concurrent clients you go with Go was so small. I know lots of people using Go and Gorilla websockets that exceed 1.5k clients with similar memory constraints. To be perfectly honest, it sounds like you're doing something wrong.

As of Go 1.4, the default stack size per goroutine was 2KB and not 4KB.

If you add in TypeScript, you'll have a better type system than Go provides in the Node ecosystem. That's a huge point for using Node.js, especially if there are multiple contributors and the code base lasts for many years.

I've found typescript an invaluable tool.

Having worked on large backend codebases in both TS and JS, the difference is stark. The TS API in my case had something like 90% less errors, and those were all subtle bugs in business logic.

On the other hand, the large JS API over time had all sorts of unexpected type errors and undefined behavior. I'm aware that this is anecdotal evidence, but TS is pretty much a no-brainer now on backend.

Is it not a problem in practice when TS type declarations and their associated JS code are written by different people at different times for different versions of a library?

I have no experience with maintaining TS projects over a longer period of time, but I have started some experimental TS projects where I was looking for type declarations.

What I found didn't seem to have any formal reference to a specific version of the library. I found that a bit scary. Not sure if it actually causes problems though.

Not caused us any yet over 3 years. You've got to think of it as the opposite, when we find a missing method because we at some point updated a library, we update the ts definition.

So it's not that it's a source of errors as most libraries are backwards compatible.

> Is it not a problem in practice when TS type declarations and their associated JS code are written by different people at different times for different versions of a library?

It can be. But most popular libraries have very good version syncing, or even include definitions in the module itself. In the worst case, or if there are no typings available at all, you can just import the plain js, and use it untyped, which can be acceptable if it is not used in a lot of places.

> didn't seem to have any formal reference to a specific version

Yeah. It mostly works if you install the latest version of them both at the same time. Sometimes I've had to fiddle with backing the definition or the module back a version to get them to match.

> The TS API in my case had something like 90% less errors

That sounds like a red flag to me. I hardly have any type related bugs in my pure JS server code. Must be a poor developer in the team. Too easy to blame JS for that.

If Typescript can deliver 90% less errors with the same team, saying "Must be a bad developer" is a useless comment.

If TypeScript let's that developer make good code, then the variable is JavaScript.

That's the great thing about Type systems. It doesn't matter if the development team is amazing or not. Typescript still makes huge classes of errors impossible. It also speeds up development due to superior IDE support.

I've only used TS on the frontend, but I had the same opinion as you until I dug into a couple of TS projects. I don't know if I've ever caused a JS production bug that was a type error at its core, but I've had plenty of bugs like that in development. TS lets me cut out those little dev cycles where I'll write some code, rebuild the app, then see an obvious error in the JS console when I run the app. That adds up to a lot of wasted time over a week of coding. Smart autocomplete and smart variable renaming is also really nice, and I have way more confidence refactoring a TS project than a JS one. I think using TS does result in fewer production bugs, but the big win for me has been having fewer development bugs.

Types are good for more than just "int instead of string". What you consider a type related error is likely not the full set of errors a type system can prevent.

Aside from the other responses you are getting, consider that the "90% less errors" doesn't actually tell you anything about the overall quality of either codebase. It could be a million lines of JS/TS with 10 errors found in the JS vs 1 in the TS. That would be a 90% reduction, but 10 errors in a large codebase would still be pretty excellent.

A great carpenter can hammer a nail with a screwdriver, but that doesn't mean it's a good idea.

When the tools help you, a good developer can focus on making better things rather than not making mistakes.

Tests are also a red flag for the same reason. Just suck less, I always say!

There are quite a few things I like about Go, but it's just so hard to leave the safety and reliability of TypeScript. Go's limited type system is its fatal handicap IMO.

It’s interesting how divisive Go’s type system is. For some people it’s the main reason they use it, for others it’s a fatal handicap.

FWIW I predominantly use PHP, so I have no dog in this fight.

I think a lot of the differences between how people view Go is based on where they are previously coming from. The C/C++ folks are used to worse or more complex type systems so they view Go as fresh air. The “better python” people love the easy to use type system and the performance improvements. But those “better python” people are used to things like package managers which the C/C++ have done just fine without. The Java people don’t understand why they should give up an expressive type system for faster compile times. (Might see this from people who love C++ templates too.)

At least that’s some generalizations I’ve observed, YMMV.

I think some programmers want to carefully select a type specialized data structure, and others just bury the problem under a pile of array iteration.

And to hell with compile time. If the build takes 10x as long but we run 5% fewer prod servers, that pays for itself in minutes. And if type and nullability checking prevents one prod outage, that saves more time and stress than every build I've waited for this year.

I often don’t understand the Go teams obsession with compile times, but I’ve never worked on large Java or C++ code based that take forever to compile. I mostly want them to optimize for runtime performance even at the expense of compile time, but this does not seem popular with the core team.

You're right. You need to have worked on Google scale C++ programs to understand and acquire the obsession.

What a great comment. I know it’s a bit of a generalization but it’s helped me understand why some might get fanatical.

Java - expressive type system ? The bar must have been set really low by Go...

Java has generics, Go doesn't.

Good points - where one comes from really makes a difference.

I am not too familiar with TypeScript (I only know that typing is optional for backwards compatibility).

What are some practical examples of strengths it has over Go?

Muh generix!

> Tooling is a lot better in go ecosystem for understanding CPU and memory consumption, so if/when you run into into issues with Node you're going to be in a world of pain (this is basically a large portion of my job in a large node.js code base in the $day_job).

Is there no movement to change that? What about `node --inspect`?

node —-inspect is a great debugger but last I looked the tooling around memory wasn’t very good. As far as I know, the best practice is to use Ben Nooordius’ heapdump tool (which is super flakey between bugs and Linux oom killer) or lldb with a node plugin. Joynet has/had some cool stuff for illuminos based OSes and IBM seems to be working on some tooling but it’s not there yet.

Reply on news.ycombinator.com