Generally I don't do this (go ahead, have yourself a google). But the error was so blatant that I just couldn't not say anything about it. In a sense the article baited me into it.
Ignorance and having time are 2 orthogonal things. Your argument is not even close to valid.
And I haven't even mentioned the ad hominem, which is an automatic disqualifier for any argument.
Or the author should/could improve their writing style. Just a thought.
One concrete improvement would be not to moan about things that aren't even true (anymore).
> The cost of this borrow checker is huge: every reference in every program needs to be annotation with whether it's shared or mutable
No. You need to "annotate" a mutable binding since bindings are immutable by default. But that also means that immutable bindings (ie the vast majority) does not to be "annotated". And even when you do need to, you literally just add the keyword `mut` as in `let mut foo = 42;`.
> and you often need to splatter confusing lifetime annotations all over the place. It adds a big learning curve to the language.
Again an extreme exaggeration. There are a few cases here and there where you need lifetime annotations, but most often the compiler simply infers them for you, allowing you to elide them completely.
Specifically, you only need to do it yourself when it's ambiguous from which input(s) the output is derived.
You could just serve a webpage that queries your desktop, and visit that with the browser on your phone. Slightly more work, but definitely viable.
You can even make a shortcut on the home screen of your phone that automatically navigates to your custom search page.
They're failing, and hilariously so. The Gmail GUI is awful, it's slow (especially on non-chrome browsers), you're still being tracked (nothing new but still worth mentioning) and manipulated.
And worse, the slowness thing was done for (allegedly) anti-competitive reasons.
Then there's android and chrome: the new material design style is something you need to be a little brainwashed to really like, as a lot of space is simply wasted on eye-searing white backgrounds.
And finally, let's talk about search, Google’s raison d'etre. It's consistently dropped in quality. For example, a number of years ago I'd never even think about going to page 2 or even 3, or even going to another search engine.
But now it's par for the course, since page 1 is just chock full of garbage e.g. advertisements (nothing new, but still) and links that don't even come close to providing the answer to my question.
Quite frankly, properly justifying staying with Google is starting to get seriously difficult.
This is not as much as a problem as you believe. Rust is perfectly capable of making objects that have a C API and ABI precisely for this reason, and the most popular distros only work with supported compile targets anyway.
That said, a distro like Debian might indeed encounter some issues at this time for the less prominent platforms eg MIPS or PowerPC based chips.
That shouldn't prevent Debian from including Rust altogether though, they merely should exclude it on those less or even unsupported platforms.
Basically the net effects are a mix of:
1. Push more computation to compile time rather than runtime
2. Verify a lot more state at compile time, preventing dangerous or nonsensical state from occurring altogether
3. Because of 2,you get hard guarantees about the runtime state e.g there is no chance of encountering undefined behavior in safe Rust
4. Building, testing, and deploying are all quite straightforward in almost every Rust project. If you can get away with simple statistics, benchmarking is very simple too. The ones that don't typically have native non-Rust dependencies
It seems you are missing the point of Rusts safety. Yes that safety does prevent things like segfaults, but the real value is in security. As software becomes evermore critical to our lives in pretty much every aspect, having a system that can be derailed by malicious actors is not just unfortunate in the way that a segfault is, no. It is reckless. At this moment what we see is news about company X or Y being hacked,including some infrastructure like electrical grids. Fast forward a half decade and we will have people being hacked and killed from a distance. All made possible because of bugs.
While your use cases are definitely valid for you, this is not a Rust issue, but something that's 100% decided by your distro. They decide if, when and how they integrate Rust into it.
As for the multiple copies issue with Cargo:
I generally agree with you that this definitely feels like 1 source of major blow up in project compile times, and it would be nice and useful if that were reduced as much as possible.
But there is a reason that this system is in place: each crate defines how it compiles and consumes its dependency crates, so if crates A and B both depend on crate C, then A might compile and consume C differently than B does. This results in effectively different libraries once compiled, and ATM there is no way to predict in advance what the effect of any given compile flag will be since any flag can switch on/off arbitrary code. Hence Cargo keeps A's C dependency separate from B's.
Then there's the not doubting whether an application uses the latest patches. Up to a point, this can be automated through exploitation of SemVer: if Cargo could figure out that a new library version is API and ABI compatible with the previous version then I'd argue that Cargo should perhaps just auto-update it.
A bigger issue is what happens when a new major version of the library is released, as those tend to break APIs in order to perform maintenance. That is something that as of yet has not been automated.
That's not really all that relevant for most existing commercial code since legacy code tends to not get rewritten at all unless it's absolutely necessary, and thus remains stuck with the Old Ways.
Spoken like someone with plenty of money in the bank, which is of course a luxurious position to find yourself in. And in those circumstances I agree with you.
But the above doesn't hold for everyone, and thus I don't in general agree with your assessment.