@kohlrabi thanks for writing this up.

... I immediately tried to use a bufio.Writer, and everything was "fine". This code is obviously much more verbose, and it is of utmost importance to not forget flushing the buffer, since it apparently does not happen automatically on leaving main (and thus exiting):

The flush behavior is documented for bufio:

After all data has been written, the client should call the Flush method to guarantee all data has been forwarded to the underlying io.Writer.

I think this level of control is consistent with Go's API design of generally requiring the programmer to be explicit, and including tools like defer to make this easier to control.

I'm not sure if I agree on explicitly calling out that *os.File is unbuffered. Not all Go users are coming from C, and so may not have the expectation that fmt.Printf would be buffered.

/cc @ianlancetaylor

I can't see how it makes sense to add any comment about buffering to the fmt package.

For the os package a short sentence or two somewhere might be OK.

agreed wasted hours of time debugging on this...

It does not look to work as unbuffered. I launch the Go program as a subprocess with popen from a program written in another language and see it puts \n randomly and even mixes the order. Wasted hours already. I do Println the JSON string and it just gets cut in half so when I read the line it's not full and JSON is invalid. More than that, if I do another Println it gets between two halves of the JSON that was just splitted with no reason.

@Nakilon Unbuffered output means that concurrent output from multiple goroutines can be interleaved.

@ianlancetaylor ah, ok, I thought it means it gets flushed immediately preventing the mess.

But in my case I don't do anything concurrent, my program is pretty simple. It just accumulates JSON strings and then prints them out when asked. After this edit the issue appeared:

diff --git a/satellite.go b/satellite.go
index baec58d..479e769 100644
--- a/satellite.go
+++ b/satellite.go
@@ -12,7 +12,7 @@ func main() {
   var err error
   var line []byte
   var temp interface{}
-  var array []interface{}
+  var array [][]byte
   stdin := bufio.NewReader(os.Stdin)
   for {
     if c, err = stdin.ReadByte(); err != nil {
@@ -31,13 +31,10 @@ func main() {
       if err = json.Unmarshal(line, &temp); err != nil {
         panic(err)
       }
-      array = append(array, temp)
+      array = append(array, line)
     case 103:   // g print all and die
       fmt.Println(len(array));
-      for _, temp = range array {
-        if line, err = json.Marshal(temp); err != nil {
-          panic(err)
-        }
+      for _, line = range array {
         fmt.Println(string(line));
       }
       os.Exit(0)

Initially I was parsing the JSON strings (for other needs) and storing them in []interface{} but then I decided that I don't need to store them parsed and started store byte sequences in [][]byte right as they come from the stdin := bufio.NewReader(os.Stdin); stdin.ReadLine(). Now it inserts the \n instead of three other bytes (two commas and a digit) in one specific line at the same place whenever I run this. And if I add debug prints it even prints them in between where it put the corrupting \n.
Tried using os.Stdout.Write instead but the result is absolutely the same.
I wonder how to print to stdout in order.

UPD: other observations -- the corrupted line lacks leading two bytes, and it happens only when the array has more than one element.

@Nakilon That is best discussed on a forum, not on this issue. See https://golang.org/wiki/Questions. Thanks.