simon_o

Or maybe you don't want to.

If that's the hill you want to die on, good luck.

It's not an either or.

We have hundreds of languages made to please the corporate overlords.

Can't we just have one language that's actually nice to use?

That seems to be an absolute win to be honest. Not sure how you think this is helping your case.

Maven Central people nuked the artifact that may have caused confusion, and if the owners try anything like that again, it's likely their domain will be banned from publishing.

I think Rust's `async` has been a great success for commercial "sponsors" of Rust, because it increased the complexity of the language so much that it's hardly possible anymore to contribute to it without being full-time employed to do so.

The decision for `async` handed a lot of power to Amazon et al.

The problem is the ecosystem split and the decades of man hours of churn caused in libraries and user code – that's time and effort that could have been spent on making those dependencies better.

This applies to both suggestions ("fork" and "don't use it").

> Namespace is not a solution for name squatting: namespace is just yet another identifier that can be squatted. If you are worried about squatting, the only effective solution is sandboxing, everything else is just moving the goal post.

The problems crates.io struggles with have never been an issue with Maven, regardless of how creatively you try to redefine words.

That's a fact. Deal with it.

Unlikely, I'd expect most people to not have a meltdown about this.

Not to mention that this boats gentlemen is on account number 3 already, so it appears that moderators on this site have already told –him more than once– that he should offer his "generous donations of free time" somewhere else if he cannot adjust his behavior.

(His older accounts show the same patterns of throwing childish tantrums and blowing up on random people.)

I think there are some lessons that can be learned from Java's virtual thread approach – note that there is a huge gap in requirements and design trade-offs, especially around embedded, when compared to Rust.

I'd just wager that the effort of getting something like that into shape is smaller than the costs of async/await.

(And no, Rust's playing with green threads once 15 years ago and failing due to quality-of-implementation issues is not an excuse to dismiss everything that came after it off the bat.)

Though it's probably not worth discussing this whole topic with Rust fans currently:

Many made async/await part of their personality and have little experience to offer besides breathlessly pointing to one of the half dozen blog articles trying to defend async/await.

It will take a few years until that language feature runs through all stages of grief and one can have an adult discussion about it.

Some Rust people just have to be that dramatic.

It has everything to do with Rust's decisions.

Agreed, it's just that in Rust async/await hurts more than in e. g. JavaScript where the browser gives you enough hooks to have a "fresh start with(out) async".

This.

The harmful decisions Rust made highlight its ingrained culture of doubling down on previous mistakes at all costs.

There seems to be no reevaluation of the cost/benefit ratio once the "preferred approach" turns out to be non-viable.

"We want to have feature X, consequences be damned" is rarely a winning move in language design.

> you never need to think about it, only get smaller and more beautiful files

People said the same thing last time and it took more than 10 years until decoding worked reliably. I'm simply not interested in dealing with another JPEG++.

> Perhaps open up your thinking on this?

Nah, I'm fine. I went JXL-only for anything new I'm publishing, and if people need to switch browsers to see it – so be it.

> It's a yes!

Reminds me of "You Scientists Were So Preoccupied With Whether Or Not You Could, You Didn't Stop To Think If You Should."

The arithmetic coding feature was already painful enough. I'm simply not in need of yet another thing that makes jpeg files more complicated to deal with.

> After weighing the data, we’ve decided to stop Chrome’s

> JPEG XL experiment and remove the code associated with

> the experiment.

> We'll work to publish data in the next couple of weeks.

Did that ever happen?

Mozilla only does what Google tells them.

You seem to have serious issues, and I hope that you can work them out.

That's the prerequisite for me to engage any further with you.

That quote is programming language design's "We should improve society somewhat" – "Yet you participate in society! Curious! I am very intelligent."

I. e. it's stupid and embarrassing to watch people use it.

Most likely not wanting to repeat Rust's mistakes.

Ah, here it is, the clueless/idiotic comment about the CCC being left that is guaranteed to show up every year on HN.

If you know nothing, maybe don't comment?

Your "it's just a matter of taste" just shows a lack of research.

The decision has a lot of important second-order effects, and a lot of people are heavily invested in denying that because they are more familiar with "Type name".

Exactly. Mozilla management is the Stephen Elop of Firefox.

Citation needed.

I'm not comparing sandboxing against SELinux/AppArmor. It's a social problem, not a technical one.

I'm comparing "app developers holding themselves accountable" to "package maintainers dish out consequences for misbehavior".

I have absolutely zero trust in the former, and lots of trust in the latter.

This has to be the dumbest take on this thread.

If you want the dystopian hellhole you seemingly long for, just use Android and enjoy the ad-infested crapware? No reason to moan about things you seemingly don't understand.

> want sandboxing to work by default

Yeah, wake me up when Flatpak is remotely close to doing this. Most "apps" simply disable the sandbox.

Not to mention I'm not going to trust "app" developers setting their own permissions. That's the job of package maintainers.

Yes. Deal with it.

What kind of dystopian bullshit is this?

Occurrences of phrases like "better pay"/"higher wages"/"more benefits" in this BBC article: 0

Creative descriptions for intentionally burning people out: I stopped counting, but "maximise their potential" is certainly my favorite euphemism.

> could do automatic semicolon insertion a-la javascript

If you want to make a good faith argument against semicolon inference, that's not the way of doing it.