81–90 of 295 posts
From moving from Perl to Rust, the only thing that I miss is the postfix "if": return true if number > 2; VS: if number > 2 { return true } I find that one-liners like these are really ergonomic.
ProTip: In both languages you can do the following: return number > 2;
Earlier quoted context omitted.
That was just a trivial example. Yes, you could use a const which would be difficult to share across files. Moreover, if you wanted to do something equally textual #define PASS_VERBOSE if (flag_verbose && first_pass) printf you just might be able to but only with a completely different tool. A macro processor is not of the language; it is above the language.
> which would be difficult to share across files. It's path::to::wherever::PI. That's it. Just like any other item. If you want to use only PI in your code, you'd use 'use', like any other name. Your second example is something better suited to a macro, it's true. I _think_ what you're getting at here is that you only want text substitution? I think we will have to agree to disagree if that's true :)
Yes, I do like textual substitution. Guilty. This is a common old school low level paradigm. Still, the underlying language and its compiler exist below to enforce the rules on any atrocities I commit with my macros.
Earlier quoted context omitted.
Is there a mailing list I can subscribe to that will tell me when I can turn this on? I'm hoping not to have to listen to rust-dev for the trigger phrase.
I don't know off the top of my head because it's been a while since we talked about it and I haven't paid super close attention to rustup's development. I am assuming that we would make an announcement on the blog because we'd want to be very clear about what's going on, and of course, try to convince people to opt in :)
I am not sure if this directly applies to your post, but it came to mind when I read the section about `extern crate`. It seems like the Cargo system is relied upon by almost all Rust users, and I am not sure if the following is an ergonomics problem or a lack of understanding on my part. A couple months ago I was exploring Rust's web server capabilities after seeing the "Are we web yet?" page. I decided to try out t…
Without commenting on the particulars of the iron API (I haven't used it), it makes sense for library authors to be able to make an explicit decision as to whether or not their dependencies are going to be a part of their backwards compatibility contract or not. You could imagine a circumstance where a library A that you used depended on some library B and wanted to switch, internally, to instead depending on library C. If library A had exposed library B to its consumers as part of a public interface, that would be a breaking change, but it wouldn't be if they hadn't.
Are there plans to do user studies? 10 minutes watching new users code in Rust will give you better ideas than 10 weeks thinking about the problem in your head. I feel like there's a real lack of user testing in software development tools land. If you're developing software for unsophisticated users it's obvious that you should be doing user testing, but it's an often ignored fact that developers are users too! APIs,…
"If you're developing software for unsophisticated users it's obvious that you should be doing user testing" Compilers actually have a unique opportunity to introduce some form of opt-out tracking of all of the compilation errors with sources, etc. This could really help to understand the users.
The file structure one makes me laugh, because one language that does implicitly create modules from file structure, in exactly the way Rust would need to, is Python, which is the one with the whole "explicit is better than implicit" deal!
[1] https://www.reddit.com/r/rust/comments/5whke7/deref_coercion...
Are there plans to do user studies? 10 minutes watching new users code in Rust will give you better ideas than 10 weeks thinking about the problem in your head. I feel like there's a real lack of user testing in software development tools land. If you're developing software for unsophisticated users it's obvious that you should be doing user testing, but it's an often ignored fact that developers are users too! APIs,…
I'd add: Do you want to focus on new or experienced users? For example, when implementing systems that will be used 8 hrs/day by its users, we look only at efficiency for experienced users (unless the political situation requires placating the noobs). They will be noobs for a day or maybe a couple weeks; they'll be experienced all day, every day for years. We explain it that way at the beginning and they thank us later.
An example many are familiar with is Vim: Steep learning curve, but I'm so happy that the focus is on efficiency for veteran users.
I forgot, what's Rust's opinion on OO? I would hope it's non-traditional. We need to get away from tradition OO and concentrate on what really matters - dispatch!.
Earlier quoted context omitted.
#define M_PI 3.14159265358979323846264338327950288
I thought that style was considered bad form in modern C/C++ (esp. the later, with `constexpr`). What's wrong with const PI: f64 = 3.14159265358979323846264338327950288; ?
I'll accept without looking it up that the statement is correct syntax in some language (it doesn't look like C++ to me).
Earlier quoted context omitted.
ProTip: In both languages you can do the following: return number > 2;
But that's different. Perl's variant isn't that intuitive.
x = 42 if y > 7;
x = match y > 7 { true => 42, false => 0 };
foo() if bar();
if bar() { foo() }