5 ms·

I still don't get why they provide a warn() to stderr but no print() to stdout. [1] [1] https://ziglang.org/documentation/master/#Hello-World https://ziglang.o

by lixtra 8y ago

I still don't get why they provide a warn() to stderr but no print() to stdout. [1] [1] https://ziglang.org/documentation/master/#Hello-World https://ziglang.org/documentation/master/#Hello-World

xyproto 8y ago
If you have a command line application, you probably either want to use a library that provides colors and more features, or output to file (where writing to stdout is more appropriate than "print"). When developing, "print" is more commonly used as an aid for the developer. Most "print" messages should either be removed or outsourced to a library when the program nears completion. "warn" fills a similar purpose as "print". If you really want "print", a small function that writes to stdout is quick to write.
- lixtra 8y ago
  warn() is just as complex to write as print(). One is included, the other isn't. If you classify all C-programs by what output they use (multiple counts allowed), printf/puts shows up with the highest percentage long before ncurses, X or anything else.
  - AndyKelley 8y ago
    What's not included is an easy way to ignore errors when writing to stdout. If that's your complaint, then Zig is not the language for you. Zig also doesn't provide an easy way to ignore allocation failure errors, for example. Edge cases matter. There's no excuse for failing to handle errors.
- Phylter 8y ago
  If I'm writing a command line application then, most of the time, I just want to let the user know what's going on. It doesn't always have to be fancy and I don't want to track down a third party library to tell the user all went well and give basic statistics. I'd go ballistic if I had to download a library to print out "35 records processed." It just doesn't make sense.
  - AndyKelley 8y ago
    Then use std.debug.warn? Quoting the docs linked above: > Usually you don't want to write to stdout. You want to write to stderr. And you don't care if it fails. It's more like a warning message that you want to emit. For that you can use a simpler API: const warn = @import("std").debug.warn; pub fn main() void { warn("Hello, world!\n"); }
    - tbodt 8y ago
      The message "35 records processed" isn't a warning, nor should it necessarily go to stderr.
  - xyproto 8y ago
    Tools following the UNIX philosophy pride themselves on only bothering the user with output messages when something goes wrong.
  - xyproto 8y ago
    You can still write that message to strout, there just isn't a brief "print" function.
- _kst_ 8y ago
  No, if I have a command line application, I probably want to write (possibly formatted) output to stdout -- very likely without colors or other features. A while ago, I tried to figure how how to do the equivalent of C's int n = 42; printf("n = %d\n", n); I was unable to find a straightforward way to do that. (Formatted output to stderr, on the other hand, is easy.) I submitted a bug report and haven't gotten a response. https://github.com/ziglang/www.ziglang.org/issues/15 https://github.com/ziglang/www.ziglang.org/issues/15
AndyKelley 8y ago
Here's a modified version with print. const std = @import("std"); pub fn main() !void { // If this program is run without stdout attached, exit with an error. var stdout_file = try std.io.getStdOut(); const stdout = &stdout_file.outStream().stream; // If this program encounters pipe failure when printing to stdout, exit // with an error. try stdout.print("number: {}\n", i32(1234)); }
- lixtra 8y ago
  Why don't you make it: const print = @import("std").print; pub fn main() void { print("Hello, world!\n"); } Why does it have to be more complex than warn? You admit the added complexity yourself by using warn instead of print in the parent wiki page.
  - AndyKelley 8y ago
    Because print can fail. See the comments in the above code example.
    - lixtra 8y ago
      And warn cannot fail?
      - AndyKelley 8y ago
        Correct: pub fn warn(comptime fmt: []const u8, args: ...) void { const held = stderr_mutex.acquire(); defer held.release(); const stderr = getStderrStream() catch return; stderr.print(fmt, args) catch return; } The tradeoff, however, is that when the function returns, it is not guaranteed that the warning message made it successfully to stderr. This tradeoff is not appropriate for stdout. Also the decision to use the mutex is not appropriate for stdout. The application may be single-threaded, or have its own synchronization strategy that makes the mutex redundant. Zig is optimal.

by lixtra 8y ago

I still don't get why they provide a warn() to stderr but no print() to stdout. [1] [1] https://ziglang.org/documentation/master/#Hello-World https://ziglang.org/documentation/master/#Hello-World

xyproto 8y ago

If you have a command line application, you probably either want to use a library that provides colors and more features, or output to file (where writing to stdout is more appropriate than "print"). When developing, "print" is more commonly used as an aid for the developer. Most "print" messages should either be removed or outsourced to a library when the program nears completion. "warn" fills a similar purpose as "print". If you really want "print", a small function that writes to stdout is quick to write.

lixtra 8y ago
warn() is just as complex to write as print(). One is included, the other isn't. If you classify all C-programs by what output they use (multiple counts allowed), printf/puts shows up with the highest percentage long before ncurses, X or anything else.
- AndyKelley 8y ago
  What's not included is an easy way to ignore errors when writing to stdout. If that's your complaint, then Zig is not the language for you. Zig also doesn't provide an easy way to ignore allocation failure errors, for example. Edge cases matter. There's no excuse for failing to handle errors.
Phylter 8y ago
If I'm writing a command line application then, most of the time, I just want to let the user know what's going on. It doesn't always have to be fancy and I don't want to track down a third party library to tell the user all went well and give basic statistics. I'd go ballistic if I had to download a library to print out "35 records processed." It just doesn't make sense.
- AndyKelley 8y ago
  Then use std.debug.warn? Quoting the docs linked above: > Usually you don't want to write to stdout. You want to write to stderr. And you don't care if it fails. It's more like a warning message that you want to emit. For that you can use a simpler API: const warn = @import("std").debug.warn; pub fn main() void { warn("Hello, world!\n"); }
  - tbodt 8y ago
    The message "35 records processed" isn't a warning, nor should it necessarily go to stderr.
- xyproto 8y ago
  Tools following the UNIX philosophy pride themselves on only bothering the user with output messages when something goes wrong.
- xyproto 8y ago
  You can still write that message to strout, there just isn't a brief "print" function.
_kst_ 8y ago
No, if I have a command line application, I probably want to write (possibly formatted) output to stdout -- very likely without colors or other features. A while ago, I tried to figure how how to do the equivalent of C's int n = 42; printf("n = %d\n", n); I was unable to find a straightforward way to do that. (Formatted output to stderr, on the other hand, is easy.) I submitted a bug report and haven't gotten a response. https://github.com/ziglang/www.ziglang.org/issues/15 https://github.com/ziglang/www.ziglang.org/issues/15

AndyKelley 8y ago

Here's a modified version with print. const std = @import("std"); pub fn main() !void { // If this program is run without stdout attached, exit with an error. var stdout_file = try std.io.getStdOut(); const stdout = &stdout_file.outStream().stream; // If this program encounters pipe failure when printing to stdout, exit // with an error. try stdout.print("number: {}\n", i32(1234)); }

lixtra 8y ago
Why don't you make it: const print = @import("std").print; pub fn main() void { print("Hello, world!\n"); } Why does it have to be more complex than warn? You admit the added complexity yourself by using warn instead of print in the parent wiki page.
- AndyKelley 8y ago
  Because print can fail. See the comments in the above code example.
  - lixtra 8y ago
    And warn cannot fail?
    - AndyKelley 8y ago
      Correct: pub fn warn(comptime fmt: []const u8, args: ...) void { const held = stderr_mutex.acquire(); defer held.release(); const stderr = getStderrStream() catch return; stderr.print(fmt, args) catch return; } The tradeoff, however, is that when the function returns, it is not guaranteed that the warning message made it successfully to stderr. This tradeoff is not appropriate for stdout. Also the decision to use the mutex is not appropriate for stdout. The application may be single-threaded, or have its own synchronization strategy that makes the mutex redundant. Zig is optimal.