The "Capture" trait looks very like the following proposal for a "Claim" trait, motivated by very similar pain points:<p><a href="https://smallcultfollowing.com/babysteps/blog/2024/06/21/claim-auto-and-otherwise/" rel="nofollow">https://smallcultfollowing.com/babysteps/blog/2024/06/21/cla...</a>
For those who missed the earlier article this is refering to, I think it's this one:<p><a href="https://loglog.games/blog/leaving-rust-gamedev/" rel="nofollow">https://loglog.games/blog/leaving-rust-gamedev/</a>
I am not a deep, low-level developer... I've only tinkered with some direct hardware access over the years. I will say, that I've toyed with Rust (Axum and others) for mid-tier API usage and found the results to be more than effective.<p>I didn't find working with Axum to be much more difficult than say Koa with Node or C# since .Net Core. It took a bit of structure to get things going, but in general it was relatively straight forward.<p>The couple things I've done on the UI side, mostly around Yew, has been much more difficult for me to wrap my mind around however. I think there's room for improvement, and I do think there's room for a better templating structure. There's definitely not a white box solution for getting things done like some other platforms and languages. You have to put a bit more of it together. It's the difference between Lego Mindstorm and Duplo.
A pain point, for me, is having to explicitly type private functions.<p>I like refactoring independent blocks out into functions, to separate the scopes and have readable summaries a la self-documenting code. Having to fish out and then explicitly enter some library's useful but complex type makes it unpleasant.<p>I'm starting to see a pattern here... Hmm, maybe private functions should be treated differently?
This is an interesting article, but as a Swift language designer, I'd really appreciate it if people didn't randomly throw out wildly inaccurate information like "Basically everything in swift is an Arc<Mutex<T>>".
> I argue that Rust’s success is social in nature. My hot take: Rust’s popularity does not come from its technical merits.<p>This is very true: Rust has found success because it arrived at the good time, in the good niche and pushed by the good people. Obviously it has technical merits because else it would not have succeeded, but its success compared to other languages that have also technical merits is based on other reasons
We use rust for all sorts of stuff at work and definitely don’t find progress on anything to be slow. If anything, we ship much faster and with a lot more confidence than most (all?) of the other teams in our org that don’t use rust.