It’s really not. That is a fringe benefit; there are a dozen other reasons to use Rust over, say, C++. The syntax is cleaner, there are async await semantics, locking is way better, destructors aren’t a dumpster fire, macros aren’t the wild west, there just isn’t as much cruft... and et cetera.
FYI, the “et” means “and”. https://en.wikipedia.org/wiki/Et_cetera is good reading.
As an example:
The authors of the text were James, Malik, Susan, Srini, and Ying. ... <some more text goes here> ... This was the primary finding supported by Srini, James, etc.
Above, the usage of 'etc' is to shorten the sentence, by avoiding a second instance of the full list.
A simple translation to English shows that the common usage can leave much up to the interpretation of the reader.
As an example:
I like sweet foods: cherries, apples, grapes, and the rest.
So, do I actually mean fruits? Do I mean all other sweet foods that exist? This sentence leaves a lot of interpretation to the reader, and depends on shared context to have any useful meaning. This usage of 'et cetera' generally means "and more in a sequence made up of items categorically in line with what I've named, which I assume, you, the reader, can infer."
This reply is not meant to critique modern usage. Language is a fluid thing, and the use delineating implication, rather than eliding a fully enumerated list, is perfectly acceptable in the vernacular. I just wanted to share some additional nuance regarding the phrase.
Increasingly I’d say I observe et al. being used for (a) lists of people, and (b) finite, known lists; and etc. being used for lists of unknown length. (You may notice there is some unspecified area in that classification. This is deliberate.) This is a definite shift from the original Latin.
Thinking about it a bit more, there is a strong convention in functional languages to decompose lists into "first" and "rest" (regardless of what your language cares to name the functions that return these concepts). Especially in the case of infinite streams, "etc" seems to align with what you've described as the shifting usage in the term. I doubt CS is driving the shift in meaning. Just an interesting parallel I noticed.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p137...
> 7.7 Matchers and Extractors: Other Languages
Hmm... that "Other Language" looks quite familiar.
And still no sum types.
I do wonder how they are able to pull it off. It is truly remarkable in some way that they are able to have so many language features without it being detrimental to the language.
Or do you think that Fortran 2018, C17, C# 9, Java 15, Python 3.9, COBOL 2014, Ada 2014,... are any different?
But that's the whole point.
https://www.stroustrup.com/bs_faq.html#multiparadigm
You may prefer using 20 different languages for writing your app, I'd much rather write 20 EDSL embedded I a single host language.
https://pubmed.ncbi.nlm.nih.gov/21875228/
https://www.youtube.com/watch?v=EJ5rx5lDIoc
https://www.amazon.com/Creativity-Constraints-Breakthrough-P...
If you google constraints and creativity you will find an endless sea of research.
Otoh most useful large software is written in C++ - adobe software like Photoshop, Illustrator, Premiere, After Effects, most big music making software (Ableton, Cubase, etc), most big video software (DaVinci Resolve, etc) and they definitely don't seem to be lacking in the "creativity" department.
If your hypothesis was true, wouldn't we be seeing a lot of much more advanced software written in different languages ? Yet there are barely any - in audio there's Fruity Loops written in Delphi but other than that...
https://eli.thegreenplace.net/2015/c-deleting-destructors-an...
Quoting Stroustrup:
Introducing operator new thus made the use of free store more convenient and less error−prone. This increased its use even further so that the C free store allocation routine malloc() used to implement new became the most common performance bottleneck in real systems. This was no real surprise either; the only problem was what to do about it. Having real programs spend 50% or more of their time in malloc() wasn’t acceptable.I found per− class allocators and deallocators very effective. The fundamental idea is that free store memory usage is dominated by the allocation and deallocation of lots of small objects from very few classes. Take over the allocation of those objects in a separate allocator and you can save both time and space for those objects and also reduce the amount of fragmentation of the general free store.
I think almost no one needs custom new and delete today, not only because they are very clunky and obscure, but especially due to the fact that modern C++ features such as move semantics, allocators, std::optional<> and NRVO make them almost redundant and unnecessary.
It's not just a relic of the past. This was last year.
There are coroutines in C++20 now. It has the async/await syntax except it's extensible to any kind of coroutine semantics, not just Futures like in Rust.
> locking is way better
RAII was inspired by C++. For making a mutex own its associated data, that's a simple template class which is a well-known pattern. You're also not forced to use it when it is not a good fit.
> The syntax is cleaner
You got me, I have been trolled.
> You're also not forced to use it when it is not a good fit. But like all language criticisms that contain this sentence, it's better when the language makes it somewhat tedious to go outside of the norm, where the norm is defined as the 99% use case. C++ is the opposite; you have to go out of your way to use the generic, safe features like smart pointers or create copy constructors.
Rust's syntax takes cues from ML which means that things like switch statements (matches), if's, and even return are also expressions, which makes it nicer to refactor and allows you more choices when structuring your code.
So they finally sorted out the remaining issues with Drop traits and everything macro related works on stable?
No, the roots, the general unkempt hacked-together style had started by then already :( it's the efforts of last decade or so which made a relatively reasonable language out of C++. It wasn't corrupted by the industry, but it did corrupt the industry to some extent.
C++ helped me avoid C, because I could drop down to the C subset when obliged to do so, and still take advantage of C++'s improved type safety, just validating at the end that a C compiler would also be happy with the code, and thanks to its Bell Labs heritage it has always been a first class language across all major UNIX/POSIX platforms.
I know. It's hard to miss. :P My point was to reflect your claim of the suitability of C++.
Rust is still young. Much younger in some domains than others. GUI is obviously one of them, and I suspect it will be quite a while before it ever catches up, if at all. If that were my requirement to use Rust, then I'd forget about it and check back in five years.
I'm not sure where you are on the innovation curve[1], but I'd say Rust and GUI are all the way to the left right now. (I don't think Rust itself is, but GUI in Rust is.) There are bindings to existing toolkits, but as you say, they're hard to use. So I think some innovation is required and people are working on it.
My guess is that you're somewhere in the "late majority" group on that curve. Partially because you seem to require support by the platform itself (not just platform support by the language) and also due to requiring a mature solution to a deeply complex problem (GUI). Those things tend to take a really long time to happen, if at all, unless they are built and created by the platform itself.
Your desire for binary libraries isn't as out of reach though I think. It's just a hard problem to solve and there just honestly isn't a ton of motivation to do it as far as I can tell. It might require a well funded player to help move that along. (Not just in the work required to do it, but in the resources required to provide it I think.)
[1] - https://www.ou.edu/deptcomm/dodjcc/groups/99A2/theories.htm