Hacker News Reader

Comment by Ygg2 | Hacker News Reader

Preface. I disagree.

I definitely don't get the feeling that C++ was that popular, I distintcly remember many Linus rants about it. It's just that after years of usage it carved its own niche.

However one pain point Rust does address is parallelism. If you want to use modern systems, and you're going with C++. Good luck. You're gonna need it.

As for the popularity, I think that's moot. But I do agree Rust can't be everything to everyone. One problem it will have for the forseable future, is the slow compile speed. But on the flip side, Rust has been super popular.

But it does one thing no other language does. Safe concurrency without GC. It's like a seatbelt in a car. Once you get used to it, you'll be paranoid its not there.

----

Where I do agree with article author was rate of change. IMO Pin should have never been added to standard library as it currently is. But async was rushed, for god knows what reasons.

View on HN

Async took years, burned out everyone involved, and many people complained about how long it took.

I know I am in the minority, but for me async is an anti-feature.

I'm not sure who is it for, but if it's responsible for Pin and it's related unsoundness issues, that just makes me dislike it even more.

A language with BDFL could have, took a more principled stance and said no async until we prove Pin is safe.

They could have said "we won't ship this yet," and they also could have said "ship it" to the initial design in 2015.

> took a more principled stance

This is very insulting. Bugs are often found in every kind of software. Virtually no languages that exist, let alone popular ones, require proofs before landing new features.

> This is very insulting. Bugs are often found in every kind of software.

To me it's not a bug. It's a foundational flaw. If Rust was a house, and a bug was a broken window, unsoundness issue would be water seeping into the foundation.

If standard library is unsound, that means pretty much everything derived from/relying on that functionality is unsound.

Adding unsoundness for the sake of pushing a feature out is just bad. It's cutting corners on essential things.

> they also could have said "ship it"

True. But if I know that BDFL is an asshat, then I avoid that project.

There is a difference between saying "I believe new features should have proofs of soundness before landing" and saying that developers are "unprincipled." The former is a specific technical critique, the latter is an insult directed at the people making decisions. Specific technical critiques are great. Suggesting a lack of principle from the developers is not.

Here's why this matters. This response from you is much better! Because:

> If Rust was a house, and a bug was a broken window, unsoundness issue would be water seeping into the foundation.

Yes. Everyone agrees, in principle, that Rust being sound is an important property. Your criticism isn't actually about principles, it (appears to me, anyway) that it is about the specific methods in which we figure out if something is sound or not. You can argue that nothing should be added without formal proof, and that's a fine position to take, but at least it is a specific, actionable criticism that can be discussed directly.

By this standard, virtually all languages have "unprincipled" designers. This isn't even true of only async! We didn't (and still sort of don't) have a formal model of the borrow checker. So you can't really criticize async specifically in this way, you'd have to criticize the entire language.

> the latter is an insult directed at the people making decisions

The way I see unprincipled is two fold: 1) You're breaking your promise 2) In a similar situation behave differently

1) Pin was a problem from the start. Allowing it into std/core was a mistake. The fact they allowed an almost blatantly unsound feature is unprincipled.

I'm not 100% sure of the timeline, but near or before the release there were examples floating of a possible Pin unsoundness. And defense was, it's an obscure thing, no one would really use that in practice. The moment designer says, no one would use that in practice, is the moment they lost.

2) Yeah, I get async was a feature everyone wanted. By same measure, why not add self-referential struct. People want it. It's probably unsound but you can't tell. Maybe there exist a model that allows self-referntial structs.

Similar situation, different behavior

Nobody promised full formal specifications before landing features. The pin soundness issue was found close to release, but a plan was made to fix it before it was released. Pin is not fundamentally unsound.

People do want it, and in fact, it is part of async, and directly related to the soundness issues you’re complaint about. The reason such things aren’t in stable is that, while people do want it, people wanted async more, and did the work. The work has to happen, features don’t just magically come into existence.

The only unresolved soundness issue for Pin that I can find seems to only affect nightly not stable. https://github.com/rust-lang/rust/issues/68015

It doesn't appear to be unresolvable.

I never said they were unresolvable. I'm glad they are resolvable.

But what if the issue was unresolvable? Rust would either have to rollback a feature or basically say, we're sound, except for that part.

You don't have to use async if you don't want to.

> If you want to use modern systems, and you're going with C++. Good luck. You're gonna need it.

if you're doing modern stuff you just use a task-based parallelism lib and pass things by value with libs such as https://github.com/taskflow/taskflow, https://github.com/cameron314/concurrentqueue ...

Linus wanted attention and C++ was perfect. Later down the road, he even ranted about Java. It's clear he is a hater of OOP and Abstraction in general. Now, Linus Cultists promotes Data Oriented Design.

The attention thing said by Bjarne by himself when asked on Reddit.

Reply on news.ycombinator.com