71–80 of 265 posts
Problems with differentiating .await from .member can easily be solved by using syntax highlighting. Also, Rust is already strange to write, this is just one more quirk one will get used to.
> Its very easy to build a mental model of the period operator as simply the introduction of all of these various postfix syntaxes: field accesses, methods, and certain keyword operators like the await operation. (In this model, even the ? operator can be thought of as a modification on the period construct.) I like this explanation. But this whole post could really use some more concrete examples of the at the very…
My dislike for the ”dot keyword” syntax has been strong, but if it is selected, hopefully it’s at least generalized to other keywords in the future, so that `.await` doesn’t stay a lone awkward exception to what dot notation means. In particular, I wouldn’t mind if in the future `expr?` could be spelled `expr.try` for consistency (even at the expense of introducing redundancy).
> In particular, some members of the language team are excited about a potential future extensions in which some “expression-oriented” keywords (that is, those that evaluate to something other than ! or ()) can all be called in a “method-like” fashion. In this world, the dot await operation would be generalized so that await were a “normal” prefix keyword, but the dot combination applied to several such keywords, most importantly match:
In the off chance that some Rust developers are looking at this thread, I'd like to put forward a counter-proposal: 1. Use a postfix ?! instead of .await 2. Use a postfix ?? instead of .await? 3. Use the await keyword only in the "for await" construct Then the common case becomes: let resp = http::get(url)??.to_string() Which, imo, is a bit easier to parse than: let resp = http::get(url).await?.to_string() This would…
Earlier quoted context omitted.
While that's true on an individual basis you can't use that continually to introduce differences, because at some point if someone comes to rust and sees a heap of weirdness they're going to be less likely to adopt the language. I'm mostly a bystander since I've written some rust but not very much, but I think rust is neat and I don't want it to become an esoteric language.
If it's an effective solution it will only seem weird until it's proven to be more useful than the status quo approach. I read this post and thought 'async as a prefix is intuitive!', but that's only because I saw it first in C#. Rust already has an immense learning curve despite its ergonomics, I say it should continue to experiment. Same way Haskell does. I do wonder if `.await` could have a sigil equivalent the sa…
Perl was a very effective solution. Still lost. And I say that as a long time perl5 nut.
Rust is, indeed, just syntactically insane to a new learner (honestly, worse than perl ever was). And it's getting rapidly worse.
My first experience with futures was in the form of QFuture (https://doc.qt.io/qt-5/qfuture.html), and there you call .result() to block and wait for the result. This postfixing is intuitive.
Rust's "?" operator is neat. I don't know if I've seen a postfix operator anywhere else yet. It's certainly possible Rust got this language aspect wrong, but as a user it feels pretty right.
Given the existence of the "?" operator, and the fact that futures resolution via postfix is intuitive (and not a new thing either), IMHO the best course of action probably is postfix. I'm not sure if literally ".await" is the best, but it's in the ballpark.
In the off chance that some Rust developers are looking at this thread, I'd like to put forward a counter-proposal: 1. Use a postfix ?! instead of .await 2. Use a postfix ?? instead of .await? 3. Use the await keyword only in the "for await" construct Then the common case becomes: let resp = http::get(url)??.to_string() Which, imo, is a bit easier to parse than: let resp = http::get(url).await?.to_string() This would…
I agree that the syntax should have `await' somewhere, and the observation that it "clearly" is not a field access is actually credible to me. This also open the possibility to have other kinds of postfix keyword e.g. .try or .match
It seems they've settled on using a postfix approach. I can't help but feel this is a mistake. Rust is already a weird language to come to from the likes of python, Java, or Javascript, and it feels to me like this relatively unknown approach of putting the operator at the end is a mistake that will add another confusing aspect of the language. I feel like the committee has worried about the wrong things when conside…
The most scary thing that threw me off the most were lifetimes (which for beginners sake are gladly not needed all that often).
I have trust in the Rust developers and the community that they will choose something very well thought out, because for now the whole language feels incredibly well considered.
It seems they've settled on using a postfix approach. I can't help but feel this is a mistake. Rust is already a weird language to come to from the likes of python, Java, or Javascript, and it feels to me like this relatively unknown approach of putting the operator at the end is a mistake that will add another confusing aspect of the language. I feel like the committee has worried about the wrong things when conside…
> Rust is already a weird language Some folks came up with the idea of a "weirdness" budget - arguing that Rust had come close to using it all up. >I feel like the committee has worried about the wrong things There is no "committee" really, and all the worries have been expressed and weighed. The debate over this syntax has been going on for months and had huge community involvement. It's all been summed up in this d…
I don't really see how they refute this argument though? Clearly they state arguments both in favor of postfix and prefix but it feels like some framework for weighing the arguments is missing, otherwise it just comes down to how individuals weigh the arguments.
Earlier quoted context omitted.
It's just means there is lack of trust to core designers. They haven't proven themselves to users, that they are capable of addressing their problems and align with their interests. Obviously core devs of Google backed language cannot do better. They can only gain that trust from users within Google, not outside of Google. Not sure about Rust though.
> Obviously core devs of Google backed language cannot do better. They can only gain that trust from users within Google, not outside of Google. That's a non sequitur. Trust is not mandated by company boundaries. I for one trust in the competence of the Go maintainers, while at the same time having absolutely zero trust in Google as a company.
That's fine. But ultimately Go employees do not work for you and cannot put much effort into proving they are good at solving problems for you, since the company doesn't pay them to do it. There will not be a track record in users eyes of their design decisions and not much trust from users they are even capable of doing it well.
Nice insight into the amount of thought going into this design proposal. It's always tricky to introduce new syntax to a language and re-using the field access notation here isn't as icky an approach as it first looks. I don't know enough about rust to understand how this would operate during compile time w.r.t if a user tries to define a field named 'async'. Is that no longer allowed or would the compiler be able to…
Disambiguation is easy when `await` is a keyword. [0] ;) error[E0721]: `await` is a keyword in the 2018 edition --> src/lib.rs:2:5 | 2 | await: i32 | ^^^^^ help: you can use a raw identifier to stay compatible: `r#await` [0] https://play.rust-lang.org/?version=stable&mode=debug&editio...
https://en.wikipedia.org/wiki/Reserved_word
> Not all languages have the same numbers of reserved words. For example, Java (and other C derivatives) has a rather sparse complement of reserved words—approximately 50 – whereas COBOL has approximately 400. At the other end of the spectrum, pure Prolog and PL/I have none at all.
I don't really know why modern programming languages bother with reserved words. Yes, it would be confusing to have a variable named 'if', but compared to all of the other ways to write confusing code in, say, C, that's barely a drop in the bucket. Plus, it's something good tooling (highlighting, for example) could obviate, as it's entirely possible to use a grammar to show exactly what role each token is playing in a statement.