How are these suggestions not pragmatic? You don't have to use them, but if you need them they are there. From a security point of view I can see many of these being incredibly useful.
How are these suggestions not pragmatic? You don't have to use them, but if you need them they are there. From a security point of view I can see many of these being incredibly useful.
No, that's not how it works. See for example async: I don't need it (and indeed hate working with it, because colored functions are incredibly unpleasant to work with). But a huge swath of libraries in the ecosystem are designed with the assumption that you will use it. If the language adds more features like the article is proposing, it will most likely balkanize the crate ecosystem even further. This stuff does affect people even if they never use the features in question.
If it slows down Rust development it's not pragmatic. And if it creates a cultural schism between full commitment and pragmatic approaches, it's also trouble. Remember Scala?
Rust is nowhere near the complexity of Scala wrt. seemingly arbitrary high-level features. There's a low-level, systems programming featureset that involves quite a bit of complexity but that's also less arbitrary when comparing across similarly low-level languages.
>If it slows down Rust development it's not pragmatic.
I truly don't understand. If you don't want rust to become complex, you don't want it to "develop" fast anyways. Unless you mean you think it will be slower to write code?
> And if it creates a cultural schism between full commitment and pragmatic approaches, it's also trouble.
Zero clue what this is supposed to mean. WTF is "full commitment" here?
> Remember Scala?
Scala, haskell, and others are high level languages in "academic terms." They have high levels of abstraction. The proposals are the opposite of high level abstractions, they instead formalize very important low level properties of code. If anything they decrease abstraction.