This effect of <'a> spreading everywhere is very frequently a novice mistake of putting temporary scope-bound loans (AKA references) in structs that aren't temporary views themselves.
People used to C or C++ perspective tend to reflexively (over)use references to avoid copying, but references in Rust are to avoid owning, and not-copying is handled in different ways.
BTW, apart from edgiest of edge cases, &String is a useless type in Rust, because String already stores data "by reference" and is never implicitly copied. For loans it's generally better to deref to &str.
I feel like this could be a great in depth blog post...unless such a blog post already exists? It would greatly benefit novices and those who haven't gotten to that stage where this mentality kicks in.
There's a pretty good YouTube video I saw pulling all the types of strings in rust.
I find it confusing still... Been wanting to do a few things that would mean dealing with it streams that could be cp437 or utt8, generally and haven't been quite sure how I want to deal with it.
I'm thinking I want to convert to/from utf8 at the edges even for the encoding... Namely web/terminal, then the internal interfaces and relay in utf8, then back to co437 for door game interaction.
Basically a BBS door running service, with some extra niceties internally.
I am a novice when it comes to rust but as I recall the instant you put anything that isn't a scalar type you need lifetimes. Is that what the person you are replying to frustrated with?
How would not copying be handled?
Sorry for the basic questions. Your comment tickles something in my brain that suggests I need to know.
Very rarely do you need to pass around a lifetime-bound struct or enum that isn't _also_ meant to be temporary. (One database pool has database connections lifetime bound, for example, but the pool still owns the connection.) When I do, I generally eat the cost and put it behind a Rc/Arc, where cloning is cheap.
It is 'borrowing' because you don't own it, not because you don't want to clone/copy it. Sometimes it is cheaper to borrow than it is to clone/copy; sometimes it is not.
It’s 1440p of “screen real estate” logical resolution, like a 27” monitor with 5k pixels like the Apple studio display or LG UltraFine, full 4K video feed - not as high res as the LG UltraFine.
But that's not a real value created by the company, but value that would be extracted by self-dealing placement of their products on Amazon. I'm quite happy that EU is siding with the consumers, not the shareholders.
By squashing, you lose ability to effectively bisect.
Instead of finding an offending commit that has only a few lines to analyze, you only get a massive feature-landing commit that doesn't narrow it down.
Interactive rebase or amend can be used to squash "oops forgot a semicolon" junk commits.
This is literally furthest front the truth. Instead of having develop of all building test passing squashed commits you have to fiddle with bisect around commits that accidentally break the build and fail test and god knows why.
Squash is basically a hard requirement for bisect to be useful at all. Especially for compiled languages.
Such API allows showing an offline state immediately, instead of after some timeout. Online-checking request timeout unfortunately needs to be multiple seconds long, because bad cases of packet loss can add seconds of delay, and there's DNS, TCP, and HTTP handshake to perform.
There are also some horribly broken networks that get connections stuck and never time out (in browsers too), e.g. TCP-accelerating middleboxes will speculatively accept a TCP connection, and then may blackhole everything else due to a failure upstream. That will look like waiting for a response from the server, forever.
Even if you just went and turned off the Wi-Fi interface on your device, `SCNetworkReachability` would know straight away - and from the flags you can deduce exactly what happened and react accordingly.
(I do agree though that it's a dangerous approach if it misbehaves, as it happened to me!)
Chrome had many vulnerabilities that could be avoided with a safer language, but complex bugs in JIT are not one of them.
I think you could argue that the VM should be implemented in a less dangerous way that can be formally verified or better isolated, but that's not as simple as a rewrite in Rust.
Firefox is a special case, since it uses unreleased experimental features of the Rust compiler. IMHO it's unnecessary, but that's their choice (they get some nice-to-have features).
Most of the Rust ecosystem targets the latest stable release of the compiler. Updates for Rust users are very easy and reliable. It remains compatible with sources since 2015, so there's generally no obstacle to upgrading.
Changes between versions of Rust are very small, often just new functions in the standard library or some compiler flag. But people use them as soon as they're available, so everyone else has to use latest stable Rust as well.
This clashes with policies of many Linux distros that keep years-old software and prefer not to touch it. This is more of a culture/policy problem than a technical one. Rust wants to be up-to-date like Chrome, distros update Rust like Internet Explorer.
I know you've probably seen this, but some additional data for other folks, David Tolnay posted yesterday about Meta's experiences upgrading the rust compiler reguarly:
> For a server process the best reaction to a panic would mean abort and clean restart.
That's often infeasible, and creates a major DoS/reliability problem.
The server may be processing hundreds of different requests at the same time, and panic=abort will kill all of them. That creates a visible failure to other unrelated clients of the server, not just the offending request.
If you try to fix that and retry aborted requests, you'll retry the panic-inducing request and cause another failure (and it'll take several restarts to bisect out the offending request).
Plus a restart may be costly, require loading data, warming up caches, etc.
It's just way cheaper to catch a panic and return 500 to the offending request. Rust guarantees to panic before anything terrible memory-corrupting happens. Even if you don't trust it and would prefer to restart anyway, you have an option to gracefully hand over the traffic before the restart.
I think linkers don't go this far to rewrite the debug info. If libstd is used, libstd's debug info is used.
The second problem is dynamic dispatch. The overhead in "hello world" is from printing and panicking machinery (it handles closed stdout), and these features use vtables, so it's even harder to precisely analyze what's actually used and what isn't.
As I said, I was happy. In the end it is always the relation on how you balance quickly vs. spending money on a first-gen product. But yes, most iPad customers probably were happier with the 2nd gen.
People used to C or C++ perspective tend to reflexively (over)use references to avoid copying, but references in Rust are to avoid owning, and not-copying is handled in different ways.
BTW, apart from edgiest of edge cases, &String is a useless type in Rust, because String already stores data "by reference" and is never implicitly copied. For loans it's generally better to deref to &str.