3 ms·

That sounds like it could be a nightmare for error handling! How do you work with that? And aren't a great many performance benefits lost when you restrict Go t

by warent 9y ago

That sounds like it could be a nightmare for error handling! How do you work with that? And aren't a great many performance benefits lost when you restrict Go to stdout? I would think it would be better overall to just create a local http server in Go and use that instead. Or sockets if you're feeling up to it.

danenania 9y ago
The executable has really simple output--it either works and outputs json, or doesn't and outputs nothing--so there's no difficulty with error handling. I guess I can understand wanting tighter integration for more complex scenarios though... an http server is an interesting idea, but could you run into issues with ports being restricted on production servers? I'm not seeing any performance issues with stdout, but I'm also not writing much data.
- tokenizerrr 9y ago
  > but could you run into issues with ports being restricted on production servers Sorry, what? Just make the port configurable?
  - danenania 9y ago
    It was a question (note the question mark)... I don't see the need for snark. Anyway, for my purposes, this wouldn't work, since the executable is embedded in libraries that are meant to run anywhere without any configuration. But yeah I could see that being fine under other circumstances I guess.
    - tokenizerrr 9y ago
      No snark. Just puzzled. You can still just make it configurable. Or just pick a random port and communicate it with your child process.
Vendan 9y ago
The only performance issues with stdout is if you write to a console, the console is rendering it. For example, printing 100000 lines of `Hello World!` to stdout takes 2.134 seconds when output to a console on my computer, 43 milliseconds when redirected to `nul`, (the equiv of > /dev/nul), and 276 milliseconds when redirected to a file. So saying stdout is a performance issue is just FUD. Now, there's still issues with error handling, but that can be solved by implementing a message protocol over stdin/stdout, and you still have a cost associated with launching the binary, but that can similarly be replaced with message protocol over stdin/stdout, allowing the same running instance to serve multiple requests.

by warent 9y ago

danenania 9y ago

The executable has really simple output--it either works and outputs json, or doesn't and outputs nothing--so there's no difficulty with error handling. I guess I can understand wanting tighter integration for more complex scenarios though... an http server is an interesting idea, but could you run into issues with ports being restricted on production servers? I'm not seeing any performance issues with stdout, but I'm also not writing much data.

tokenizerrr 9y ago
> but could you run into issues with ports being restricted on production servers Sorry, what? Just make the port configurable?
- danenania 9y ago
  It was a question (note the question mark)... I don't see the need for snark. Anyway, for my purposes, this wouldn't work, since the executable is embedded in libraries that are meant to run anywhere without any configuration. But yeah I could see that being fine under other circumstances I guess.
  - tokenizerrr 9y ago
    No snark. Just puzzled. You can still just make it configurable. Or just pick a random port and communicate it with your child process.

Vendan 9y ago

The only performance issues with stdout is if you write to a console, the console is rendering it. For example, printing 100000 lines of `Hello World!` to stdout takes 2.134 seconds when output to a console on my computer, 43 milliseconds when redirected to `nul`, (the equiv of > /dev/nul), and 276 milliseconds when redirected to a file. So saying stdout is a performance issue is just FUD. Now, there's still issues with error handling, but that can be solved by implementing a message protocol over stdin/stdout, and you still have a cost associated with launching the binary, but that can similarly be replaced with message protocol over stdin/stdout, allowing the same running instance to serve multiple requests.