Hacker News Reader

Comment by steveklabnik | Hacker News Reader

I'm always glad to get feedback, we're specifically going to focus on ergonomics and smoothing rough edges this year, so this kind of thing is invaluable.

There's some good discussion on the Rust subreddit: https://www.reddit.com/r/rust/comments/53ft4m/my_experience_...

View on HN

Off-topic, but since you're here, let me ask: where can I track the progress on rustup support for musl-based distros where musl is the host (void linux, alpine linux) and FreeBSD? I got everything but Rust working nicely on void linux, and it's the only thing holding me back right now. Since Docker defaults to alpine linux, the reach of such support will be wider than one might initially think.

For void: https://github.com/voidlinux/void-packages/issues/4570

And alpine: http://pkgs.alpinelinux.org/packages?name=rust*&branch=&repo...

https://github.com/rust-lang/rust/issues/31322#issuecomment-... is the latest news on the subject. It's not impossible, but we're not sure _how_ we want to make it easy. The real issue is the bootstrapping, my understanding is that cross-compiling a musl compiler from a gnu compiler does work today, which is how those packages were made.

Thanks for the pointers. Yeah, after you've bootstrapped once, you have a version to bootstrap another, especially since the new requirements to not depend on a nightly snapshot. rustup should be able to provide images that way which work on both alpine and void. The default would be a dynamically linked against musl rustup image which may still expose musl-static as a target just like it does on glibc hosts. I wouldn't complicate matters as a first step with questions of whether a musl image should be statically linked.

I tried rustup.rs on PacBSD, and everything just worked, so presumably it'll just work on FreeBSD too.

Great that you're open to feedback! I'm looking at this snippet from the guessing game in the official Rust documentation:

    let mut guess = String::new();

    io::stdin().read_line(&mut guess)
        .expect("Failed to read line");

There are two things wrong here: 1) I have to use mutability to read from standard input. 2) I have to use a pointer. How about something like this instead:

    let guess = io::stdin().read_line()
        .expect("Failed to read line");

Make it a macro or something if necessary. Personally, I just looked at this and decided that Rust wasn't ready for use by non-low-level programmers.

The API used to be what you suggest, but it was changed because it forces doing a new allocation for each line. By taking a mutable string, code can reuse the backing storage of a string (or append to an existing one), which is especially useful for efficient loops.

> Personally, I just looked at this and decided that Rust wasn't ready for use by non-low-level programmers.

That's definitely a valid sentiment, but I think a better framing would be "isn't ready for use in non-low-level contexts": Rust is (and aims to become even better) an enabling technology that allows higher level programmers to more easily write performance sensitive code, because the aggressive compiler checks help people sidestep days/weeks of subtle pointer pain. Of course, the language focuses on this low-level/performance-sensitive space, and other languages may make more sense if those benefits aren't important for your particular use case.

I'm not saying that the possibility of doing it the current way should be removed, I'm just saying that there should be a cleaner/easier way that's recommended in the Rust docs. If people really need to optimize this that's fine, but it should be opt-in, not the only way to do it.

> If people really need to optimize this that's fine, but it should be opt-in, not the only way to do it.

Be careful, you're taking goals of other languages and layering them on Rust. It's entirely valid for a language to decide that the default idioms should not be sub optimal where that's easily achievable. In a language meant to compete with C/C++ on performance, defaulting to a slower idiom when security is not in question may not be the correct choice. In a language that is accepting some level of non-negligible performance loss in idiomatic code already (such as Go), the decision may be different.

Valid point. My perception is that Rust wants to be a little more mainstream than C++ though.

That said, my conclusion after looking at Rust is that it's Haskell for compile-time memory management; i.e. it won't become very popular, but it'll influence languages that do.

I'm not entirely sure what you mean by "a little more mainstream", which I read as implying C++ isn't mainstream, and when I think mainstream programming languages the top two in my mind, when generalizing across domains, are C/C++ and Java. There are specific areas where they aren't somewhere very close to the top (webapps, but even there Java makes a showing in the enterprise), but those are the exceptions.

My impression of Rust has always been that it's trying to supplant C++, by providing something with similar performance characteristics while being safer and with somewhat improved ergonomics (given the required complexity increase for the additional security, which may yield a net gain or loss in ergonomics depending on your point of view and background).

> it won't become very popular, but it'll influence languages that do

That's entirely possible, and I'm willing to accept that as a good thing if it happens. :)

Reply on news.ycombinator.com