Comment by aw1621107
6 hours ago
> It claims to be "sufficiently fast by default", yet "sufficiently fast" depends entirely on the requirements of a specific user project.
I think that's why the "by default" is there; the goal is to offer a safe/convenient API that performs well enough that by default you don't need to reach beyond said safe/convenient API. And if you happen to be in a situation where the default performance of the safe/convenient APIs is insufficient, more advanced APIs will be provided.
It's a mirror of Rust's general design goals, if anything.
But it still depends on the requirements of the specific user project, whether the default is sufficiently fast, ESL. It is still entirely inconsistent. Basic logic 101, clear as day. Why do you even try to contest this?
> It's a mirror of Rust's general design goals, if anything.
Do you claim that "it's a mirror of Rust's general design goals, if anything" to be forced into memory unsafe, extra-difficult Rust code being required, when the going already gets tough regarding performance requirements? That is not a great design goal, and it is not conducive to memory safety nor high quality software.
> But it still depends on the requirements of the specific user project, whether the default is sufficiently fast
I mean, "by default" means "by default", not "in all cases". Situations that the default doesn't address are not inconsistent with the existence of a default; it's just that said situations are expected to be a relative minority.
Perhaps a more concrete example would help: say the API the devs come up with is sufficiently fast enough for 99 common use cases and not fast enough for 1 uncommon one. I don't think it'd be inconsistent to call said API "sufficiently fast by default" since "sufficiently fast" is an accurate description of the API for "normal" use (i.e., that's the "default" state).
> Do you claim that "it's a mirror of Rust's general design goals, if anything" to be forced into memory unsafe, extra-difficult Rust code being required, when the going already gets tough regarding performance requirements?
No, I think that's a rather... imaginative interpretation of what I said.