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

171–180 of 185 posts

Re: Ditching Go for Node.js

#171

Post by KirinDave »

tree_of_item wrote: post #140
KirinDave wrote: post #130

Earlier quoted context omitted.

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.

That kind of encoding is only the right call if you want for a message to be a foo, a bar, OR a foo+bar.

If you've got an opcode, name it semantically with a name field. If you've got a type to serialize, do it semantically and don't just do like what the library I ported does and put the Golang type annotation in a string.

And don't let objects inhabit a fusion like this. It leads to surprising behavior with malformed messages.

Re: Ditching Go for Node.js

#172

Post by KirinDave »

Vendan wrote: post #135
KirinDave wrote: post #130

Earlier quoted context omitted.

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.

I don't disagree that many JSON APIs are poorly designed.

Re: Ditching Go for Node.js

#173

Post by KirinDave »

Rapzid wrote: post #143
KirinDave wrote: post #130

Earlier quoted context omitted.

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…

This isn't Golang specific; most statically typed languages are going to fall back on a similar pattern(TypeScript, C#, Javascript, etc). Take a look at AWS's API schemas and you will see. Personally, I loath API schemas designed with the assumption of a dynamically typed language.

What steams my clams is folks using go type names in f Label fields, or making surprisingly behavior with fusion types that and up actually seeing use in the wild.

Re: Ditching Go for Node.js

#174

Post by KirinDave »

KirinDave wrote: post #168
Vendan wrote: post #167

Earlier quoted context omitted.

Go is multithreaded. Paying a small price to use multiple cores vs. only being able to use a single core? I'll take the multicore. It's not like concurrent lock-free datastructures are without cost...

If your workload is primarily I/O then coroutines will lose on the wall clock. And of course parallel workloads are fiddly. But it's also worth noting Golang's current implementation of channels and messages is (as I've noted) going to be notably slow. Odds are you are going to avoid channels entirely if you care about maximizing multi-core performance. Which is not to say that Golang "isn't fast". Just that it's not…

Erhem, please excuse me. I was walking my dog as I wrote this and I accidentally inverted first statement.

For workloads where lots of concurrent and contingent I/O dominate, coroutines win handily.

Re: Ditching Go for Node.js

#175

Post by tree_of_item »

KirinDave wrote: post #171
tree_of_item wrote: post #140

Earlier quoted context omitted.

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.

That kind of encoding is only the right call if you want for a message to be a foo, a bar, OR a foo+bar. If you've got an opcode, name it semantically with a name field. If you've got a type to serialize, do it semantically and don't just do like what the library I ported does and put the Golang type annotation in a string. And don't let objects inhabit a fusion like this. It leads to surprising behavior with malform…

Your schema can simply say it is illegal for an object to have both of those tags once. I'm not sure how you'd do any better with a unityped system like JSON. Unless you're advocating using something other than JSON? What do you mean by "do it semantically"? What other alternative is there besides a field for a type tag?

Re: Ditching Go for Node.js

#176

Post by Thetawaves »

lenkite wrote: post #79
tankenmate wrote: post #42

Why two (or three) go routines per connection? Why not one net socket (for reads) and two channels (one for writes, other for pub/sub) and select() between them? It seems like the OP is trying too hard to avoid event loops.

Please upvote parent. This is the first thing that struck my mind too. golang offers `select` for non-blocking calls. Deeply skeptical that node.js is the best solution for a chat service. (unless the backend is serving rendered UI's)

You generally need one thread to read for incoming messages, typical:

  for {
      select {
      case
You need another thread to listen for messages on a channel and send them out the socket typical:

  for {
      select {
      case

Re: Ditching Go for Node.js

#177

Post by krylon »

marcusramberg wrote: post #76
krylon wrote: post #45

So, I am not a big fan of Javascript. I do not despise it or anything, I just never got to like it. I guess. I did really love POE, though, so when I heard of Node.JS, I thought I will probably like this very much. I am not sure what happened. I think it was the tutorials being always out of date. Node.js seem so be such a fast-moving target. I do not mind asynchronous, callback-driven code. But when a tutorial that…

If you liked POE you might enjoy Mojolicious :) http://mojolicious.org/

Thanks for the hint, it looks very interesting.

Most (well, all) Perl programming I do these days is simple scripts for automating tedious tasks, reporting, etc., and the odd CGI script.

Funny story, though: during my training I spent some time in a team doing in-house Perl development, and I sat next to Sebastian Riedel's desk! :-) It's a small world!

Re: Ditching Go for Node.js

#178

Post by tankenmate »

Thetawaves wrote: post #176
lenkite wrote: post #79

Earlier quoted context omitted.

Please upvote parent. This is the first thing that struck my mind too. golang offers `select` for non-blocking calls. Deeply skeptical that node.js is the best solution for a chat service. (unless the backend is serving rendered UI's)

You generally need one thread to read for incoming messages, typical: for { select { case You need another thread to listen for messages on a channel and send them out the socket typical: for { select { case

Instead of?

  for {
    select {
    case

Re: Ditching Go for Node.js

#179

Post by jonathanoliver »

im_down_w_otp wrote: post #101
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…

On a really slow, in-order-execution processor w/ tiny caches and fairly awful front-side bus that's also all responsible for managing the network connection over USB? The thing about Intel non-Atom level hardware is that Intel has spent a lot of money over the better part of two decades packing processors full of features that make all kinds of theoretically inefficient things run pretty fast. This is not true of th…

Good point. Go channels weren't nearly as efficient on non-x86 hardware. When I compiled my Go Disruptor port and ran it on my Nexus 5 mobile phone, I was getting about 9 million messages/sec.

Re: Ditching Go for Node.js

#180

Post by jonathanoliver »

Zekio wrote: post #93
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…

have you tried seeing how many messages you can push if you change how often the garbage collector runs? after seeing the Golang garbage collector blog post from cloudflare?

I never tweaked GC. With channels, I imagine there would be quite a bit of garbage. With the Disruptor, it was zero allocations and zero collections so no garbage was produced because every element in the ring buffer was long lived.
Post reply on HN