3 ms·

I agree that the author is extremely qualified to write about this, but personally I also find the title a little jarring, mostly due to the word "couldn't". It

by saghm 6y ago

I agree that the author is extremely qualified to write about this, but personally I also find the title a little jarring, mostly due to the word "couldn't". It seems more that there are number of tradeoffs where allowing slight runtime costs by default (like reference counting) unlocks a lot of stuff that's needed to be able to make dynamic linking easier, and Rust chose to go a different route than Swift. I understand that changing the title to read "where Rust chose to optimize for different priorities" won't get as many clicks, but the title to me paints the lack of dynamic linking support in Rust as some sort of failing rather than an explicit design choice. Realistically, I think the fact that Rust and Swift picked different routes here is a good thing! Having languages which optimize for different things gives people more options to pick one that suits their needs better; in a world with both nails and screws, it's better to have both hammers and screwdrivers available.

steveklabnik 6y ago
Sure, that the author is an expert does not mean that she is infallible, or there's nothing to discuss. That's not what this sub-thread is about. This thread is about some sort of insinuation that this is born out of some sort of weird attempt at Swift to use Rust to gain prominence, or something.
kortex 6y ago
Those were some of the most memorable sections for me. I never really thought about the other side of monomorphizing. It made it really obvious where "zero-cost abstractions" start to fall short.
kungito 6y ago
I totally agree. I have a problem only with the wording of the title and it shouldn't matter who wrote it. It's a matter of integrity and we as software engineers should set higher standards to how we write professional articles
moldavi 6y ago
I don't see the problem. Rust made some explicit choices that meant it couldn't do something. Doesn't change the fact that it couldn't do something. No need to get so defensive, lots of languages have things they can't do.

by saghm 6y ago

steveklabnik 6y ago

Sure, that the author is an expert does not mean that she is infallible, or there's nothing to discuss. That's not what this sub-thread is about. This thread is about some sort of insinuation that this is born out of some sort of weird attempt at Swift to use Rust to gain prominence, or something.

kortex 6y ago

Those were some of the most memorable sections for me. I never really thought about the other side of monomorphizing. It made it really obvious where "zero-cost abstractions" start to fall short.

kungito 6y ago

I totally agree. I have a problem only with the wording of the title and it shouldn't matter who wrote it. It's a matter of integrity and we as software engineers should set higher standards to how we write professional articles

moldavi 6y ago

I don't see the problem. Rust made some explicit choices that meant it couldn't do something. Doesn't change the fact that it couldn't do something. No need to get so defensive, lots of languages have things they can't do.