6 ms·
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
by iends 9y ago
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.
- ryanplant-au 9y agoThere 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.
- blowski 9y agoIt’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.
- iends 9y agoI 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.
- w4tson 9y agoWhat a great comment. I know it’s a bit of a generalization but it’s helped me understand why some might get fanatical.
- stmw 9y agoGood points - where one comes from really makes a difference.
- erik_seaberg 9y agoI 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.
- iends 9y agoI 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.
- owaislone 9y agoYou're right. You need to have worked on Google scale C++ programs to understand and acquire the obsession.
- rubber_duck 9y agoJava - expressive type system ? The bar must have been set really low by Go...
- 323454 9y agoJava has generics, Go doesn't.
- dullgiulio 9y agoI 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?
- piano 9y agoMuh generix!
- chmln 9y agoI'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.
- fauigerzigerk 9y agoIs 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.
- deleted 9y ago[deleted]
- mattmanser 9y agoNot 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.
- geon 9y ago> 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.
- MuffinFlavored 9y ago> 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`?
- iends 9y agonode —-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.