5 ms·

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

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.
always_good 9y ago
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.
- weberc2 9y ago
  > 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.

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.

always_good 9y ago

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.

weberc2 9y ago
> 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.