While the article is an absolutely excellent analysis of Rust from the low, PL-level ergonomics point of view, it seems to largely miss (or, intentionally, skip) the bird's eye point of view of complexity inherent to software development.
I was recently tasked with developing a fragment of a mobile app written in Objective-C++ (an awesome PL powerhorse, BTW) that mixed multi-threaded (multiple dynamic UI layers, multiple levels of background processing) and async (multiple over-the-network downloads, multiple database updates, etc.) To make a long story short: even though I've been coding C++ for 20 years, I am still a bit depressed about how badly I got my own @$$ handed to me on my first try. It took a ton of bug hunting and code refactoring to get everything right. Being forced by Rust to throw together a couple of somewhat inelegant reference counted pointers is... trivial compared to the benefits Rust offers (safety).
I was also recently tasked with investigating serverless. To make a long story short: due to the fact that serverless is billed by the amount of memory used and the CPU time required to execute a lambda, so far in my analysis Rust is coming out on top over interpreted and garbage-collected languages to such extent that it actually makes the difference not just between a "good" and "very good" solution, but between an "impossible" and "feasible" one, cost-wise. Being forced by Rust to read a couple of books on how the new concepts of ownership and lifetimes work is... trivial compared to the benefits Rust offers (efficiency).
If you define "feasibility of a commercial success" as "finding a pain point and being the only solution for it on the market", then it becomes more and more likely that, with time, Rust will win over many other PLs.
Rust is not an appropriate solution for iOS, I don’t think it’s even possible to use it except through some hacks. So the options aren’t buggy Objective-C++ vs inelegant but safe Rust.
It’s having a product vs. not having one and the latter guarantees a lack of commercial success.
I'm not sure what you mean - I mentioned Objective-C++ mobile development only as an example of how challenging multi-threaded/async programming can be. The problem is analogous on other platforms and can be simplified by Rust on the platforms that Rust supports. Also, it wasn't Objective-C++ that was buggy, it was my brain that was bug-prone :). (BTW, when it comes to iOS development, I consider Swift to be significantly more complex than Rust.)
I disagree. If you want common code between all platforms (iOS/Android/Windows/macOS) your choices are pretty limited. Right now I work on a large codebase where C++ is used to solve the code sharing issue, but would much prefer it to be Rust.
I liked your thoughts but disagree with the conclusion.
It seems that serverless is cost prohibitive in many scenarios, and requires lots of optimization to be cost effective. So isn't it more of a fault of serverless than a strength of rust?
I see your point, but it all depends on whether the choice of a particular organizational infrastructure architecture is a priority for you or not.
If infrastructure is a priority, (e.g., "we don't really want to hire anyone just to setup/monitor/secure that Linux box with all those REST API server/database processes, thus we prefer serverless), serverless is important and Rust performance is its strength.
If infrastructure is not a priority, (e.g., "I was gonna roll out my own VPS anyway, I love this stuff"), serverless is all about its faults and Rust is irrelevant (it is logical to choose an easier PL, e.g., the excellent Golang).
I was recently tasked with developing a fragment of a mobile app written in Objective-C++ (an awesome PL powerhorse, BTW) that mixed multi-threaded (multiple dynamic UI layers, multiple levels of background processing) and async (multiple over-the-network downloads, multiple database updates, etc.) To make a long story short: even though I've been coding C++ for 20 years, I am still a bit depressed about how badly I got my own @$$ handed to me on my first try. It took a ton of bug hunting and code refactoring to get everything right. Being forced by Rust to throw together a couple of somewhat inelegant reference counted pointers is... trivial compared to the benefits Rust offers (safety).
I was also recently tasked with investigating serverless. To make a long story short: due to the fact that serverless is billed by the amount of memory used and the CPU time required to execute a lambda, so far in my analysis Rust is coming out on top over interpreted and garbage-collected languages to such extent that it actually makes the difference not just between a "good" and "very good" solution, but between an "impossible" and "feasible" one, cost-wise. Being forced by Rust to read a couple of books on how the new concepts of ownership and lifetimes work is... trivial compared to the benefits Rust offers (efficiency).
If you define "feasibility of a commercial success" as "finding a pain point and being the only solution for it on the market", then it becomes more and more likely that, with time, Rust will win over many other PLs.