5 ms·

Hopefully it's linear, or it's implemented wrong.

• bryanlarsen 9y ago
  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. :)
  • iends 9y ago
    It being implemented incorrectly is not a property of the Go language, though.
    • KirinDave 9y ago
      It is a property of the Go language that the most recommended and explained concurrency primitives are slower than even 20 year old implementations.
  • weberc2 9y ago
    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 words, in the worst case, some scenarios may require you to drop into `interface{}` in Go, which has the same safety guarantees as any type in JavaScript. This way only ~3% of your code is type-unsafe instead of JavaScript's 100%. While I think there are lots of valid criticisms of Go (concurrency correctness is still hard and its type system is not very good for certain tasks), none of these are reasons to switch to JavaScript, as the author did. If he was struggling with goroutines and channels, he could still elect for a Node-like architecture (even making it single-threaded by setting GOMAXPROCS=1). If he needed generics and unions (as he cited), he switched to a language without them and without any static types at all (or a single static type, if you will); in Go he could have downgraded to `interface{}` which is analogous to JavaScript's one static type, and he would have only gave up type safety in the bits of code where Go's type system was lacking instead of everywhere. I don't want to give the impression of overselling Go here; it's just that for the cited criteria, Go is strictly better than JavaScript.
    • bryanlarsen 9y ago
      Sure, if you don't mind writing your own websocket and pub/sub libraries.
      • deleted 9y ago
        [deleted]
    • adamweston 9y ago
      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?
      • Vendan 9y ago
        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
        • weberc2 9y ago
          To be clear, my point is that interface{} is the worst case in Go and the only case in JS.
      • weberc2 9y ago
        No, there's nothing special about it, and I probably shouldn't have used that term because it might convey that it is particular to Node. Event loop, callback based programming is easily implemented in most languages.
    • zsombor 9y ago
      Both Go and JS are async and callback driven. The difference is that with JS those nasty callbacks are painfully explicit, whereas it is all hidden in Go. Node's callstack is a goroutine, except that the latter can also be preempted. If you have 100000 requests in progress in Node, it will consume at least as much memory as a well written Go program would.