On Sat, Oct 29, 2011 at 10:17 AM, Patrick Walton <pwalton at mozilla.com> wrote:
> In my experience "log_err" is for quick and dirty "printf debugging", so
> stderr seems appropriate to me. It's not intended to be the main way for
> command-line programs to get stuff on the screen. It's not ideal for that
> purpose anyway, since it's polymorphic and you typically don't want to show
> the equivalent of toSource() output to end users.
>
> Perhaps "show" would be a better name, to make it clear that it's a
> debugging tool?
>
> Given what I just said above, maybe our hello world shouldn't encourage poor
> practices and should import the print function from the standard library.
> I'm a little concerned from a developer ergonomics/marketing perspective
> that we require an import statement for hello world (note that not even Java
> requires this), but I suppose it can't be helped unless we really want to
> have a std::pervasives module that's imported by default.
>
As someone who's been writing Rust I agree that an introductory 'Hello
World' should show probably the traditional means of printing directly
to stdout (via std::io::println.) It's the direct analog to something
like 'std::cout' or System.out.println after all for C++/Java, and
'log' as well as 'log_err' are both diagnostics facilities from my
view.
Just consider what it looks like right now between 'std::io::println'
and 'log_err':
$ cat hi1.rs
use std;
fn main() {
std::io::println("Hello World!");
}
$ ./hi1
Hello World!
And log_err:
$ cat hi2.rs
use std;
fn main() {
log_err "Hello World!";
}
$ ./hi2
rt: ---
rt: 4259:main:main: "Hello World!"
Personally I think this would be rather surprising at a first glance.
I feel log/log_err should definitely be explained in their own right
(or even just a small dedicated blurb) to explain their purpose as
well as e.g. RUST_LOG. I see the manual has been catching up on this
note.
As for renaming them, given that I think they're mostly diagnostic
utilities, I'm quite OK with just log/log_err as the names. In Haskell
there's a 'Debug.Trace' module for printing things in pure code, with
just a 'trace' function. So maybe just 'trace' for the log_err case?
It does print to stdout in any case. But maybe that's not explanatory
enough.
I am also +1 for a Prelude-ish module to avert the import but I don't
mind it much either way. std::option and perhaps some of the println
things from std::io would probably be sufficient for it.
--
Regards,
Austin
Locked
