Hacker Newsnew | past | comments | ask | show | jobs | submit | simon_o's commentslogin

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?


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").


So does forking, as the parent originally suggested.


> 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.


How can you be that sure? :-) It is not even like that Maven repositories don't suffer from malicious packages with confusing names (for example, [1])...

[1] https://github.com/spring-projects/spring-ai/issues/537


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.


Yes, but that's not unique to Maven because virtually all software repositories have such policies. If that's about the required amount of "moderation" you claim, I don't see how Maven can even be considered better than others.


Or maybe you don't want to.

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


Maybe you wanted to say that policies do not imply actual "moderation". But that is demonstrably false, there are documented cases where crates.io removed packages solely because they were malicious and all those cases happened as soon as possible for crates.io. So Maven Central has to do something more in order to be ever considered better than crates.io, but I have no idea---it accepts any well-formed uploads after all. Do elaborate on that.


Only sith speak in absolutes.


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


I didn't exactly rage quit but did think it was silly.

I wouldn't describe teal as blue or green any more than I'd describe purple as red or blue, so being forced to pick felt silly. Like being forced to choose my seventh favorite Norwegian glacier - technically its a valid question but my answer is necessarily going to be arbitrary.


As someone who rage-quit on the third question, I'm going to say that frustration is a likely experience.


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.


I think he's talking about OS threads... it has nothing to do with rust's decisions.


It has everything to do with Rust's decisions.


Talking about a "decision" only makes sense if there's a reasonable alternative.

Do you think "actually fixing" OS threads was a reasonable alternative? What would you prefer for a high performance abstraction instead of async?


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.


True but I didn't just mean Rust... I meant virtually all async coding as a pattern.


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".


Despicable comment and false.


Is it 'despicable' just because you don't like what it says? You didn't do anything to refute it.


I've written thousands of words on my blog about the design of async Rust, in which I carefully explain every decision and discuss the strong and weak points. This person regularly post rude low-effort comments like this one. My body of work should be enough to refute the idea that all I'm doing is doubling down.


This person regularly post rude low-effort comments

https://news.ycombinator.com/item?id=41034778

https://news.ycombinator.com/item?id=41004954

My body of work should be enough

This is a separate discussion, maybe you can put some of that body of work here.


This is literally a thread about a post on my blog. If you can’t find my body of work, I cannot help you.


It's not about me finding anything, I'm saying that your expectations probably need to be adjusted. It seems like you thought you would post a one word title and have everyone just post compliments with no questions.


I didn't ask for this to be posted on Hacker News, genius. My engagement with this community is a generous use of my free time, but I do not suffer trolls and cranks like simon-o.


My engagement with this community is a generous use of my free time

I think this attitude is a major problem. You wrote something public and here you have lots of attention and engagement and you think you're being "generous" by replying to people. If you don't want people to read it, take it down. If you don't want to engage with people on hacker news, just ignore the whole thing. Calling comments "despicable" with no explanation is not a great reaction to people giving your article the attention you wanted in the first place.


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.)


https://news.ycombinator.com/item?id=33512918

You weren't kidding. It's the exact same attitude of focusing on authority rather than explaining things technically.


This comment contains a link to a detailed technical explanation of why the person I was replying to was wrong. Does your browser not support websites others than Hacker News? What is this peculiar delusion you have in which content not written into this little box is not real content?

Hacker News comments are divided between useful, inquisitive engagement, to which I react positively and smarmy, self-important bullshit, to which I react with scorn. You have made clear your allegiance to the latter. Sad!


What are your expectations exactly when you try to patronize people and tell them about their "total ignorance" while also just throwing out links to random blog posts?

If someone replies with insults and then just links to a google search page you wouldn't think they're some sort of authority because they promised you the evidence to their claim is out there somewhere.

If you want people to actually respect what you're saying you need to do things differently from both angles. Stop the toxic claims of authority and give simple explanations that are direct replies to what people are talking about.


I created new accounts because I didn't register with an email and lost the login. What a nasty person you are! Why don't you go create something?


Some Rust people just have to be that dramatic.


> 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?


I don't see any downsides with Jpegli. Your Linux distro admin exchanges the lib for you, you never need to think about it, only get smaller and more beautiful files. If you use commercial software (Apple, Adobe, mobile phone cameras, Microsoft, ...) hopefully they migrate by themselves.

If they don't, literally nothing happens.

I fail to see a major downside. Perhaps open up your thinking on this?

Yes, Chrome published data.


> 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 not a new JPEG++. It creates old JPEGs, fully 100% compatible.

(Of course JXL is better still.)


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

This makes your website only viewable on Safari (and by extension Apple devices) only, right?


Mozilla only does what Google tells them.


Why bother promoting firefox then? If they have no will of their own, you're screwed anyway. Might use chrome as well


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.


Well, I guess that I am stupid and embarrassing, then! :-) <g> :-)

You know, "I resemble that remark!" :-)

(But that doesn't change the fact that I actually like the Bjarne Stroustrup quote!) <g> :-) <g>)

Now let's understand your comment a little bit better. Your comment apparently arises from a Meme, specifically this one:

https://knowyourmeme.com/memes/we-should-improve-society-som...

While that meme is indeed entertaining(!) -- it is in no way actually relevant to the Bjarne Stroustrup quote!

It is a "Motte and Bailey" AKA, "bait-and-switch" argument/comparison.

Propagandistic agenda-driven AI chatbots seem to do this a lot -- but I'll be charitable (this time!) and assume, for the purposes of discussion, that you are human...

Perhaps we should all learn about what a "Motte and Bailey" argument/comparison/logical fallacy, is:

https://rationalwiki.org/wiki/Motte_and_bailey

>"Motte and bailey (MAB) is a combination of bait-and-switch and equivocation".

https://en.wikipedia.org/wiki/List_of_fallacies#:~:text=Equi...

https://pressbooks.ulib.csuohio.edu/eng-102/chapter/fallacie...

Phrased another way (in Billy Madison terms): "Mr. Madison... Everyone in this room is now dumber...":

https://www.imdb.com/title/tt0112508/characters/nm0235999#:~....

Incidentally, another one of my favorite Bjarne Stroustrup quotes is:

"Proof by analogy is fraud". :-)

https://www.stroustrup.com/quotes.html#:~:text=Proof%20by%20...


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.


Most likely not wanting to repeat Rust's mistakes.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: