These kinds of perfectionism complaints keep the status quo of FPTP, which is the worst of them all.

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.

They chose Swift if they want to get money on Apple's ecosystem.

Designs have trade-offs.

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.

That transformation makes writing both variants similar, but you still need to read `await (await fetch()).body()`, which IMO is much worse.

> unless it's changed recently

In Europe it's changed 15-20 years ago, when EMV-capable terminals became required, and acceptance of magnetic stripe cards got phased out soon after.

Since Apple Pay became a thing a decade ago, we don't even get US tourists confused by inability to swipe their cards anymore.

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.

... such as this one: https://www.paxtechnology.com/a77

C++ syntax and semantics are optimized for C++ idioms, and Rust's aren't.

Rust is more related to ML-family languages than C-family and OOP, so it needs to "emulate" some C++ idioms.

This goes both ways, e.g. equivalent of Rust's pattern matching on enums with data translates to verbose and clunky C++.

So you are saying that this approach teaches C++ users to use the wrong idioms in Rust?

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.

The worst pitfall is Rust references == pointers.

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.

Probably similar to antennas — using phase shifting and interference.

Yes, probably, but my question was more about the glass cover and if it wouldn't basically destroy the effect?

If it is touching the glass it amplifies it, if anything. (Edit: I should say it amplifies some frequencies while attenuating others)

FSD in principle could be, but the overpromised misnomer we have right now isn't. Being better than a drunk driver isn't good enough when it's also worse than a sober driver. The stats of crashes per mile are skewed by FSD being mainly used in easy conditions, and not for all driving.

There are real safety improvements from ADAS. For safety you only need crash avoidance, not a full-time chauffeur.

I've always been intimidated by the number of little tools and configuration options when building Debian packages. In the end, it's not very hard, and the format is quite reasonable, it just feels more complicated than it is.

I'm maintaining cargo-deb that builds a .deb from a Rust/Cargo binary project with no configuration needed.

The main source of complexity isn't the .deb format, but the tooling and infrastructure around the format. It's mired in overcomplexity, and it's very much still in a '90s mindset of building locally with multiple layers of Perl-based tools. If it was rethought to be git-native using docker images or equivalent then it could be of equivalent simplicity to other contemporary systems. When I look at what you can do with the FreeBSD ports and Poudriere or with Homebrew and other systems, I see how much of the complexity has been added incidentally and incrementally, with good intentions, but a radical rethink of the basic workflows are necessary to consolidate and simplify them.

[I used to maintain sbuild and was the author of schroot back in the day]