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

81–90 of 185 posts

Re: Ditching Go for Node.js

#81

Post by Vendan »

adamweston wrote: post #70
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…

Node makes the Node-like architecture much easier than it would be in Go, sort of by definition. Also, wouldn't Node's JIT fare much better in the face of dynamic typing than using reflection (interface {}) everywhere?

interface{} is not reflection, and using both reflection and excessive amounts of interface{} are not a good idea in Go, and frankly, I don't see anything in this code that would require using either

Re: Ditching Go for Node.js

#82

Post by stmw »

iends wrote: post #65
blowski wrote: post #56

Earlier quoted context omitted.

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…

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

Re: Ditching Go for Node.js

#83

Post by stmw »

riskable wrote: post #23

I feel his pain about the lack of decent WebSockets support in Rust. There's a few Websockets implementations but all of them are meant to run on a separate port from the web server. As in, they want you to run your web server on port 443 and the websocket on... Something else. Which makes zero sense (browsers will deny access to the second port because of security features related to SSL certificates). Also, unless…

Interesting - I wonder if a much thinner, simpler library is the answer here. The part with websocket on same port is interesting, did you hear reasons why that hasn't been done?

Re: Ditching Go for Node.js

#84

Post by mattmanser »

fauigerzigerk wrote: post #60
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…

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

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.

Re: Ditching Go for Node.js

#85

Post by geon »

fauigerzigerk wrote: post #60
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…

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

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

Re: Ditching Go for Node.js

#86

Post by pera »

igotsideas wrote: post #41

I was curious about the memory usage for Elixir. It’s the second time I’ve read (without details).

I actually did some experiments with Elixir, and my conclusion from benchmarking them was that Elixir is in fact significatively faster and consumed less memory than Node. In any case, Elixir is a great language, and even if BEAM was slower than Node I would still suggest to choose Elixir (+Phoenix) over JavaScript.

Re: Ditching Go for Node.js

#87

Post by dullgiulio »

ryanplant-au wrote: post #48
iends wrote: post #8

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…

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.

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?

Re: Ditching Go for Node.js

#88

Post by drinchev »

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.

Re: Ditching Go for Node.js

#90

Post by [deleted] »

jonathanoliver wrote: post #75

It's interesting he's referencing the Disruptor pattern. I wrote the Go port of the Disruptor implementation that he links to ( https://github.com/smartystreets/go-disruptor ) a while back and it performed beautifully. That said, channels weren't slow either. Our finding showed that we could easily push 10-30 million messages per second through a channel, so I'm struggling to understand what he defines as slow. That…

[deleted]
Post reply on HN