I don't think there are many options to host sourcecode and binaries in a way that is safe against an adversary like the US, and especially in such a way that technically illiterate users are protected. Because you'd have to assume that CAs are not off-limits either then.
I think GP is talking about a scenario where Microsoft would serve either malicious source tree or binaries to just one user, not all of them. that would be fairly hard to detect. but in such scenarios we'd also have to start asking questions about the state of the entire CA ecosystem.
Or detected easily with package builders like Arg Linux's makepkg that ship a hash along with the source URL. As soon as one user gets a different file, he has an alert and the compromised package for later analysis
the answer to this problem in general is NAT hole punching, but BitTorrent doesn't actually have an answer to your problem. if you are behind a NAT, you can only connect to peers that are not behind a NAT or have port forwarding set up. for popular torrents this is good enough because you don't have to connect to all peers.
> This is possible with port forwarding. But that's a niche set of peers, who have the power to configure port forwarding on a NAT proxy.
yes it's niche but I guess this means BitTorrent isn't as P2P in practice as one wants it to be, but held up by seedboxes.
Presumably they switch UA to Mozilla/something but tell on themselves by still using the same IP range or ASN. Unfortunately this has become common practice for feed readers as well.
browsing code is one usecase. opening issues (and having many tabs of issues open), discussing pull requests is another one. I don't think an SPA would be suited for that kind of content. Discourse might be a counter-example, but they had to do strange things for SEO, and some of its UX choices are also controversial.
I was mildly intrigued when github.dev launched and I could just open vscode in my browser. best of both worlds in a sense, just not very well integrated into each other.
It is my opinion. What else? I mean, what was the point of your response? You didn't even offer an opinion on the topic. You offered an observation and lazily concluded whatever-it-was with a rhetorical question?
> If we're not doing any state manipulation and are just using static props I don't see why we even need any abstraction at all.
People are using React outside of SPAs just because they're already used to it, and because it's got a rich ecosystem of reusable components.
I don't know how to implement setShowTooltip in vanilla js and webcomponents. It is probably really ugly. But also, making your web components work with progressive enhancement does not necessarily mean you have to get rid of React. You can still use React to define a custom HTML element, and combine the state management of React with the progressive enhancement of web components.
the problem is that react is being used outside of SPAs, for any sort of interactivity, because it is easy to hire for at this point and because there are a lot of existing components to choose from. so yeah, progressive enhancement doesn't work if the actual component is state-heavy, or the entire site is state-heavy. When React came out, its tutorial was very centered around being embeddable on existing web pages, and it was framed as more of a "jQuery replacement". IIRC the term SPA didn't even exist yet. The other commenter already pointed out what the end result is.
if you don't do it for accessibility, do it for SEO. yeah a lot of commenters here already pointed out that SSR is a thing now, but the concerns you had still apply then. There's two paths to test now, one with JS and one without. This kind of always was the case though.
This is a popular sentiment that I share to some degree, but I really wish we could just move on from this discussion. It happens in every post that is even just vaguely about Rust or async. It's like reading complaints about the GIL on a post that is loosely connected to Python! At some point it just gets boring.
"I will forever argue that [...]" -- Why are you forever arguing?
"I feel like I am alone with [...]" -- No, I read it every day on here.
to be honest, HN is one of the few venues where I think someone who is core to a project might actually see what is said about a language. I've tried getting involved in mailing lists and stuff, but they aren't often as welcoming to this discussion as one might assume.
My hope is that by raising these things on HN, someone will take notice in a different way and at least start considering / revisiting alternatives
All of this would be correct in an alternative reality where everybody in the Rust community, including every person ever involved in the language's evolvement isn't aware of these complaints.
Your comment is self defeating. The reason people are aware of these complaints is because they keep being brought up, over and over.
This is a serious wart on language design and while I can agree that it's likely too late to fix it for Rust, there is a kind of race among new languages to be a successor to C++ in many of the domains C++ is used in, and while I think Rust does hold a lead in that race, the race is not over.
A language that can provide an ergonomic solution to concurrency would absolutely provide a huge boost to any such language, and so to people in that space, listen to these complaints. Async/await is not a good solution to this problem.
You almost always hear people complaining about async/await in every language it's a part of but you rarely hear people complain about how Go manages concurrency.
