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

131–140 of 185 posts

Re: Ditching Go for Node.js

#131

Post by always_good »

anonymoushn wrote: post #16
inglor wrote: post #11

Earlier quoted context omitted.

Yes, An async function is explicitly async (in its definition). The syntax is obvious which is why JavaScript chose to go that route (rather than adopt channels at a language level for example). Plus, 95% of the time I care about the singular return value of a function - I just want something that's a function but async - and not a green thread that's using a channel to send information back. Both conceptually and in…

Most of the time you write `let x = await foo()` in js should become `x, err := foo() if err != nil then return nil, err end` in go, not anything to do with channels

What about `const [a, b] = await Promise.all([thing2(), thing2()])`.

Or

    const results = await Promise.map(xs, x => process(x), { concurrency: 2 })
Or having 2 concurrent loops processing some data?

All things that require more boilerplate in Go while trivial in Node.

Re: Ditching Go for Node.js

#132

Post by KirinDave »

iends wrote: post #51
bryanlarsen wrote: post #29

Earlier quoted context omitted.

Hopefully, but all he said was "fanout" which could be either. He knows it's implemented wrong, that's the point of the article: that Go doesn't make it easy for him to implement it right. The only question is the degree of wrongness. :)

It being implemented incorrectly is not a property of the Go language, though.

It is a property of the Go language that the most recommended and explained concurrency primitives are slower than even 20 year old implementations.

Re: Ditching Go for Node.js

#133

Post by Vendan »

majewsky wrote: post #127

> Since go does not have generics or unions my only option right now is to decode message in a base message struct with just the @ JSON field and then based on that try to decode message in a full payload struct. If he is in control of his protocol, why did he not shape it to suit his parser library? Instead of this: message1 = { "@": "foo", "foo1": 1, "foo2": 2 } message2 = { "@": "bar", "bar1": 1, "bar2": 2 } Do th…

Better pattern is http://eagain.net/articles/go-json-kind/ Then you do one switch to get the correct message type to decode into, and boom, you can just `.Run` or `.Handle` or however you design the interface, and you are done.

Re: Ditching Go for Node.js

#134

Post by KirinDave »

Vendan wrote: post #49
Vendan wrote: post #47

One thing to note is that they were using boltdb, which is an in process K/V store designed for high read loads, and doing a lot of writes to it. boltdb also tends to use a lot of memory, as it's using a mmap'd file. The switch also moved them to sqlite, which I would say is a much better fit for what they are doing, but means a lot of this is an apples and oranges comparison.

And now to get ranty: Boltdb was being handled badly: https://github.com/maxpert/raspchat/blob/79315d861968c126670... You should be using bolt's helper funcs, so you don't forget to close the transaction https://github.com/maxpert/raspchat/blob/79315d861968c126670... At least this is actually deferred, but still. https://github.com/maxpert/raspchat/blob/79315d861968c126670... These messages are horrifying, would be m…

Illegal relicensing aside, this entire kerfuffle still makes anbad case for Golang.

If it's THAT much easier to make a more efficient server with a fully dynamic language using just coroutines then why should anyone ever use Go in this case?

Saying, "this implementation is bad" might work in another comparison, but given how much of Golang's implementation and engineering philosophy has been driven by an argument of "simplicity" it seems like we keep seeing precious few returns.

Re: Ditching Go for Node.js

#135

Post by Vendan »

KirinDave wrote: post #130
majewsky wrote: post #127

> Since go does not have generics or unions my only option right now is to decode message in a base message struct with just the @ JSON field and then based on that try to decode message in a full payload struct. If he is in control of his protocol, why did he not shape it to suit his parser library? Instead of this: message1 = { "@": "foo", "foo1": 1, "foo2": 2 } message2 = { "@": "bar", "bar1": 1, "bar2": 2 } Do th…

I support ports of a Golang library and protocol that did this and I am very tired of having to suffer Go's anemic type system in every other language I work with. Please stop infecting us with Go-specific type tags (that btw make the protocol versioning story much more complicated) and either demand Go support generics like every other modern statically typed language, or accept your language is ill-equipped for par…

While I don't support what GP is advocating, JSON based apis are often horrible. Apis that return a list of objects or an object based on having >1 or 1 result are just horrifying, and that's just the start of how badly JSON gets abused.

Re: Ditching Go for Node.js

#136

Post by mmcnl »

acover wrote: post #73
iends wrote: post #50

Earlier quoted context omitted.

You're comparing core libraries of Go with non-core libraries of Node.js. Since Go libraries are not versioned without a tool like dep, you're putting trust that master doesn't have breaking changes vs hoping the maintainer follows SemVer correctly. In fact, even the core Go team has problem with this and has to revert changes to things under golang.org/x/ when they break backwards compatibility.

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.

Re: Ditching Go for Node.js

#137

Post by KirinDave »

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.

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.

Re: Ditching Go for Node.js

#138

Post by Vendan »

KirinDave wrote: post #134
Vendan wrote: post #49

Earlier quoted context omitted.

And now to get ranty: Boltdb was being handled badly: https://github.com/maxpert/raspchat/blob/79315d861968c126670... You should be using bolt's helper funcs, so you don't forget to close the transaction https://github.com/maxpert/raspchat/blob/79315d861968c126670... At least this is actually deferred, but still. https://github.com/maxpert/raspchat/blob/79315d861968c126670... These messages are horrifying, would be m…

Illegal relicensing aside, this entire kerfuffle still makes anbad case for Golang. If it's THAT much easier to make a more efficient server with a fully dynamic language using just coroutines then why should anyone ever use Go in this case? Saying, "this implementation is bad" might work in another comparison, but given how much of Golang's implementation and engineering philosophy has been driven by an argument of…

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, and using a sqlite, and I'm extremely confident that it'd be more performant.

Re: Ditching Go for Node.js

#140

Post by tree_of_item »

KirinDave wrote: post #130
majewsky wrote: post #127

> Since go does not have generics or unions my only option right now is to decode message in a base message struct with just the @ JSON field and then based on that try to decode message in a full payload struct. If he is in control of his protocol, why did he not shape it to suit his parser library? Instead of this: message1 = { "@": "foo", "foo1": 1, "foo2": 2 } message2 = { "@": "bar", "bar1": 1, "bar2": 2 } Do th…

I support ports of a Golang library and protocol that did this and I am very tired of having to suffer Go's anemic type system in every other language I work with. Please stop infecting us with Go-specific type tags (that btw make the protocol versioning story much more complicated) and either demand Go support generics like every other modern statically typed language, or accept your language is ill-equipped for par…

Are you referring to majewsky's encoding? How is that a Go-specific type tag? This is a really common encoding of sum types in unityped languages: the presence or absence of a key.
Post reply on HN