I don't get it why is performance such a massive issue that they still need to have an artificially low limit on the number of windows.
M-series iPads are more powerful than most of Apple's Mac Pros were. They have 8GB of RAM, but until recently so did Apple's best-selling MacBook models.
It's a "unit" in the sense of calling `rustc` once, but it's not a minimal unit of work. It's not directly comparable to what C does.
Rust has incremental compilation within a crate. It also splits optimization work into many parallel codegen units. The compiler front-end is also becoming parallel within crates.
The advantage is that there can be common shared state (equivalent of parsing C headers) in RAM, used for the entire crate. Otherwise it would need to be collected, written out to disk, and reloaded/reparsed by different compiler invocations much more often.
> Rust has incremental compilation within a crate. It also splits optimization work into many parallel codegen units.
Eh, it does, but it's not currently very good at this in my experience. Nothing unfixable AFAIK (and the parallel frontend can help (but is currently a significant regression on small crates)), but currently splitting things into smaller crates can often lead to much faster compiles.
There is a circular dependency — the language strongly influences what libraries/engines can and will be written.
Bevy and Servo wouldn't exist without Rust. Unreal probably wouldn't succeed without C++.
Languages may also matter for other reasons than just their feature set. Node.js got traction specifically because it was JavaScript.
Even though Fortran had state-of-the-art numeric libraries, Python enabled numpy to have the sweet spot of usability with good enough speed.
The killer libraries need years of effort to build them. That won't happen if users don't want to use the language, or the language isn't good enough for the task.
For Swift to have killer libraries, users must first choose Swift to build them. Catch22.
In this case, it was important for await and error handling with the ? operator to be readable together.
The order of operations in `await foo()?` is ambiguous, but `foo()?.await` and `foo().await?` have an obvious and clearly visible order. As a bonus, the syntax supports chaining multiple async operations without parenthesis. `fetch().await.body().await` is much nicer to write than `await (await fetch()).body()`.
Since `await` is a reserved keyword, `.await` can't be a field access. Editors with syntax highlighting can easily color it like a keyword.
The problem looking like a field has proven to be total a non-issue in practice. OTOH the syntax avoided major pitfall of visually unclear operator precedence, inconvenience of mixing of prefix and postfix operators, and ended up being clear and concise. It's been such a success, that users have since asked to have more keywords and macros usable in a postfix form.
It's also worth considering that many editors have default snippets that transform something.await into (await something) for languages with prefix await, so it kind of makes sense to cut out the middle man and just make that the syntax to me.
Note that is for the merchant side, not for the customer side - my EU-issued card still has a working mag stripe (got a chance to verify that it works this year).
And on a tangent about confused customers - I wish where to tap was as obvious as where to swipe. It varies by reader and sometimes that contactless logo is hard to see.
Not to mention the (usually mobile) terminal designs where only the merchant sees the amount entered, usually doesn't flip it to show it to the customer, and the customer needs to tap it on their side without first seeing the amount entered.
Wrong is too strong. The code is okay given the constraint — this is a guide for C++ programmers thinking in C++ terms, not for teaching purely idiomatic Rust from the ground up.
Which, as a cpp programmer trying to pick up Rust, is honestly fine to begin with. Once you've written varying amounts of code in 5-10 programming languages, it is incredibly tedious to flip through pages trying to teach you how if conditions work and how for loops work: my brain doesn't pay attention even if I try.
This is more like: how to survive rustc as a cpp programmer which is honestly your mindframe when you start out, and it sets you up for "okay now that you speak the syntax, this is how to really think in rust terms".
One habit worth trying to adopt early in this mode is running clippy, Rust's linter. Typically invoked as `cargo clippy`
Clippy likes idiomatic Rust and will suggest you change code that's not idiomatic into code which is, even when the machine code would be completely identical - the rationale being that the maintainer (later you with more Rust knowledge, a colleague, or even some stranger) is more likely to follow the idiomatic Rust and the whole point of source code is that it's for humans not machines.
Clippy is no substitute for a capable human reviewer, it has no sense of taste or style, no higher level understanding of the problem, but it's free and it's right there and unlike a human reviewer you won't feel judged which can be sensitive when you're learning a new language and are used to having mastery.
They are implemented as pointers, but their role is to give temporary (often exclusive) access that is restricted to a statically know scope, which is pretty specific and fits only some uses of some pointers/C++ references. In C++ pointers typically mean avoiding copying, but Rust references avoid storing/keeping the data. When these goals don't overlap, people get stuck with a dreadful "does not live long enough" whack-a-mole.
>their role is to give temporary (often exclusive) access that is restricted to a statically know scope, which is pretty specific and fits only some uses of some pointers/C++ references
You could have a vector of references to heap allocated data, as long as the references were parametrized by the same lifetime. You might do this if implementing a tree iterator using a vector as a stack, for instance. That goes beyond a statically known scope. But implementing a mutable iterator the same way would require a stack of mutable pointers (and therefore unsafe code whenever you dereference them), since mutable references have to be unique. That does seem like a bad limitation.
Apple only sees developers as a revenue stream to squeeze dry. Investing into Apple-only technologies is getting yourself into an abusive relationship. macOS is still a good platform, but staying away from Swift gives you an escape plan.
There's also no point having a native UI on macOS any more. Apple ruined it themselves by switching to flat design, and making their own UIs and apps an uncanny valley between macOS and iPadOS. There's no distinct native look-and-feel on macOS any more.
M-series iPads are more powerful than most of Apple's Mac Pros were. They have 8GB of RAM, but until recently so did Apple's best-selling MacBook models.
reply