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!.
It is like Go and Haskell, in that it supports structs and interfaces and that's it.
Rust's language ergonomics initiative
191–200 of 295 posts
Re: Rust's language ergonomics initiative
#192I'm an ergonomics nut and I've been looking to learn Rust. Any chance they're looking for a set of guinea pigs to report their experiences as new users, or are they mostly working on already-known issues?
Re: Rust's language ergonomics initiative
#193As I've said/posted this elsewhere, the Rust macro package is close to unusable. It makes easy stuff difficult and it doesn't exactly help with difficult stuff. It would be interesting to compare the number of macros defined in the crates corpus divided by total line count and compare that with other languages. I do not think that I am alone in not using it. Yes, I use macros; I just don't program macros. Obviously,…
I really hope one day I can build a macro for ternary operator with ? and :.
Is using the if statement as a ternary that much worse?
let x = if a { b } else { c };
Re: Rust's language ergonomics initiative
#194> Right now, such a signature would be accepted, but if you tried to use any of map’s methods, you’d get an error that K needs to be Hash and Eq, and have to go back and add those bounds. That’s an example of the compiler being pedantic in a way that can interrupt your flow, and doesn’t really add anything; the fact that we’re using K as a hashmap key essentially forces some additional assumptions about the type. But…
You can leave the inner type out...
Re: Rust's language ergonomics initiative
#195Earlier quoted context omitted.
> 10 minutes watching new users code in Rust will give you better ideas than 10 weeks thinking about the problem in your head. I am not sure whether 10 minutes of Rust would give you actionable info, I mean it certainly takes longer to get familiar with the basics in almost any language, even if the 10 minutes just stands for a short amount of time .
Things happen even in the first 10 minutes. It's not appropriate to limit user studies only to people who are already experts.
But it's also questionable to limit them to people who are not, depending on what you want to accomplish.
Re: Rust's language ergonomics initiative
#196Earlier quoted context omitted.
I have found using conditionals as expressions super useful, like: ``` fn foo(number: u32) -> bool { if number > 2 { true } else { false } } ``` I mean obviously in this situation you could just have the body of the function be `number > 2` but I write a lot of Rust code that does similar things now.
In Perl, it's fairly idiomatic to use a postfix condition on a return like that when doing early return. Some of that is obviated by Rust being typed, some is not. e.g. sub compute_interest( $amount, $interest ) { return $amount if $interest == 0; # Quick return die "We don't allow computation of negative interest rates" if $interest Edit: Also, it's worth noting that Perl enforces some behavior on this by only allow…
I've always disliked this aspect of Perl... I prefer control flow to be obvious.
Re: Rust's language ergonomics initiative
#197Earlier quoted context omitted.
Macros and the importing and scoping of them is a mess in rust right now and major rewrite of the macro system is underway. Currently crates have no way to re-export macros from other crates and #[use_macros] brings all macros in the imported crate to the local crate's namespace as-is (no way to prevent possible naming conflicts)
major rewrite of the ... is underway. That's a common response to criticisms of Rust. At this late date, that's a problem.
I mean, it would still have taken time. Should they have delayed 1.0 and stability for it? I don't see the benefit.
There have been plenty of quality of life features that were promised and delivered successfully. Many new ones have been discovered and are in active, visible progress, but are not implemented yet, so yes, you can always identify some pieces that are still being developed. The amount of resources is finite, but Rust is getting significantly better each year.
Re: Rust's language ergonomics initiative
#198> Right now, such a signature would be accepted, but if you tried to use any of map’s methods, you’d get an error that K needs to be Hash and Eq, and have to go back and add those bounds. That’s an example of the compiler being pedantic in a way that can interrupt your flow, and doesn’t really add anything; the fact that we’re using K as a hashmap key essentially forces some additional assumptions about the type. But…
You can leave the inner type out... https://play.golang.org/p/m3bLmneArB
Ah, maybe it's when they're alias types that that wouldn't work?
Re: Rust's language ergonomics initiative
#199I still can't get my head around rust. While all those features definitely make sense, I find it very confusing sometimes. Is there something like rust for c++ programmers?
Oreilly has a pre-release book that seems quite good at explaining rust from a C++ perspective.
Re: Rust's language ergonomics initiative
#200Earlier quoted context omitted.
> 10 minutes watching new users code in Rust will give you better ideas than 10 weeks thinking about the problem in your head. 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 c…
What's the language that takes that to the extreme? I remember it being used for fintech(?) or spreadsheets and I remember seeing one-liners that look like someone just mashed the keyboard. Apparently incredibly efficient once you are an expert in the language.
That would probably be Q used in kdb+, and J, which the previous response stated is an open source implementation of the same/very similar language.
The terseness even visible in the language name.