Hacker News Reader

Comment by kungito | Hacker News Reader

From reading the first few pages I get triggered because the whole "where Rust couldn't" feels like mentioning Rust in the title to piggy back on Rust's rising popularity. I personally don't find Swift interesting in any way while Rust revolutionized GCless (and GCless parallelized) typed programming.

View on HN

I'm one of the leads of the Rust language team, and I love seeing writeups like this. When we're designing Rust, we look carefully at other languages, to see examples of precedent, different trade-offs, and experiences; we don't design in a vacuum.

This is an extremely clear explanation of Swift making a different set of trade-offs to achieve a different goal, and it's worthy of consideration and evaluation. (I read it when it was first published.)

There are no attacks against Rust here. This is a professional write-up discussing two languages, by someone experienced with both.

To be fair, that sounds more like "didn't" than "couldn't," which is exactly what GP suggests.

Gankra worked on both Rust and Swift, and additionally wrote several very beloved Rust documentation resources, such as “Learning Rust With Entirely Too Many Linked Lists” and “The Rustinomicon.”

This is an extremely accomplished person writing about something she is possibly more qualified to than any other person on earth.

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.

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.

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.

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

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.

Gankra was heavily involved in low level rust plumbing such as linking, ABIs, unsafe code, and so on. Comparing to rust is both speaking to the other similar language she has experience with, and speaking to many of the people who were likely to read this article (those people being from the rust community). This article also really does achieve the goal in the third paragraph (at least when read by the right audience)

> Also some folks like to complain that Rust doesn't bother with ABI stability, and I think looking at how Swift does helps elucidate why that is.

Note Gankra is “she” not “he”

I care about Rust (mostly due to using it a lot), so I really hope more people spend the time to criticize it, and dig up the areas that need love and care compared to other languages.

But in this particular case, you should probably know that the author is not some nobody trying to piggyback on Rust's popularity :) They're a pretty well known contributor, in fact.

If by GCless you mean affine types, the only thing that Rust did was bringing affine types to the masses, which is already an achievement, agreed-

However in the big context of application programming, and how Swift is used on Apple stack, any form of garbage collection alongside memory ownership is much more productive.

Long term adoption for Rust will be places like where MISRA-C and SPARK are used nowadays.

If I have to spray my code with Arc, Rc and RefCell, I rather let the compiler type them for me.

Reply on news.ycombinator.com