Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ditching Go for Node.js

github.com

Post reply on HN
Print view View original

151–160 of 185 posts

Re: Ditching Go for Node.js

#151

Post by thraxil »

grsblk wrote: post #99
chmln wrote: post #39

Earlier quoted context omitted.

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-brain…

> 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.

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.

Re: Ditching Go for Node.js

#153

Post by spraak »

MrBuddyCasino wrote: post #116

Ryan Dahl, the creator of Node.js: "That said, I think Node is not the best system to build a massive server web. I would use Go for that. And honestly, that’s the reason why I left Node. It was the realization that: oh, actually, this is not the best server-side system ever." Full interview: https://www.mappingthejourney.com/single-post/2017/08/31/epi...

What is your point? Are you trying to say that the OP is wrong because the creator of Node says to use Go instead?

Re: Ditching Go for Node.js

#154

Post by staticassertion »

grsblk wrote: post #99
chmln wrote: post #39

Earlier quoted context omitted.

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-brain…

> 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.

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.

Re: Ditching Go for Node.js

#155

Post by [deleted] »

drinchev wrote: post #88

I'm happy about this article, not because of what it says, but because of the popularity it got. NodeJS is not as bad as people think and I'm really excited about when it will regain status in the "pros" community.

[deleted]

Re: Ditching Go for Node.js

#156

Post by weberc2 »

always_good wrote: post #128
weberc2 wrote: post #63

Earlier quoted context omitted.

I don't think this criticism holds water since he opted for JavaScript. If he was having problems with goroutines and channels, he could have picked a Node-like architecture (single-threaded, callback-driven) and still likely enjoyed better performance (and optimization tooling!) than with Node. If his issue was Go's type system, then he shouldn't have chosen a language with a strictly worse type system. In other wor…

In Javascript you have the option to gradual type into Typescript which offers much better static typing than Go. So I wouldn't be too dismissive. Also, the "just write Node-like code in Go" isn't a solution at all. You're back to fitting a square peg in a round hole.

> In Javascript you have the option to gradual type into Typescript which offers much better static typing than Go. So I wouldn't be too dismissive.

It's not reasonable to switch from a language that gives you type safety in ~95% of cases to a language that gives you type safety in 0% of cases but which provides an easier transition to a type-safe language. This is why I'm dismissive.

> Also, the "just write Node-like code in Go" isn't a solution at all. You're back to fitting a square peg in a round hole.

You're wrong here. I read and write lots of Go code, and it's perfectly idiomatic to write single-threaded, asynchronous code. In fact, I'd probably do just this for his application, modulo a thin compatibility layer to deal with the fact that net/http spins up a goroutine for each request.

Re: Ditching Go for Node.js

#157

Post by badminton1 »

Open source software often makes use of the wisdom of the crowds to move forward, and when those crowds are in average less prepared, the results are comparably bad.

See the top answer for this question in StackOverflow: https://stackoverflow.com/questions/5062614/how-to-decide-wh... . The top answer with 1360 upvotes is wrong and had little to do with the question. This is a recurrent thing in the node world.

Go ask this same thing on an Erlang, Haskell, Rust, etc. forum and I am sure the right answer will come up quickly.

Re: Ditching Go for Node.js

#158

Post by acover »

mmcnl wrote: post #136
acover wrote: post #73

Earlier quoted context omitted.

Node's fs library changed within the last 2 years. I copy pasted code and it failed.

To be fair, you shouldn't be copy pasting code anyway. But I do understand your feelings, any tutorial from before 2016 probably isn't relevant anymore.

I remember the error now. I was using an older version of node (installed via apt) but the current version of the documentation.

Stupid mistake. Please ignore.

Re: Ditching Go for Node.js

#159

Post by 323454 »

rubber_duck wrote: post #150
iends wrote: post #65

Earlier quoted context omitted.

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 - expressive type system ? The bar must have been set really low by Go...

Java has generics, Go doesn't.

Re: Ditching Go for Node.js

#160

Post by Vendan »

KirinDave wrote: post #148
Vendan wrote: post #138

Earlier quoted context omitted.

No. There was a lot of effort put into things that make no sense in the go version, including using a concurrent, lockfree, snapshot iterating hash array, where they'd most likely have better performance in this case with a map and a mutex. This was NOT simple. The node.js version is simple. The Go version is overblown in complexity and abusing the language. Rewrite the go version using just as simple of structures,…

On the data structure: arguing for locked mutation is pretty an tricky because at low volumes it'll be faster and at higher traffic volumes it will be slower. And since it's a library, who cares? Golang isn't a language that's old enough to have accumulated a ton dissonance about the "right" way to do things. Golang encourages that kind of code and you see it all over GitHub. Too bad it's something of a trap.

JS is single threaded. Putting a mutex on one data structure is not going to reduce your performance significantly below single threaded.
Post reply on HN