If someone spouts untruths, that is a failing of theirs. Talking about how there's emotions of theirs that back this promulgation of untruths, emotions which you could understand if you tried, is putting the cart before the horse. First express things that are not trivially false, then I will try to understand what you mean by it.
You keep trying to twist what I'm saying into "guys you have to be nice to the ai haters and meet them at the middle, even when they insult you :))))". Once again you have this kneejerk reaction to the words "emotions" and "feelings" as if it would make you weak to acknowledge that "humans feeling a certain way act a certain way".
I'll once again have to remind you that all of what I said was just "yeah these guys are really pissed off, here's why they might be" and never once asked any of you to agree with them, or that their conclusions about rsync were right, or anything like that.
You act like "understanding" is only ever a gift/favor you do to someone else. While it's true that in many cases it is, "understanding" can also be something that just helps you and doesn't require interaction or agreement, it's when you think "oh there's no debating with these guys so it's probably not worth it to engage" or "oh these people are talking about X but it looks like the Y underlying issue is the actual problem, so talking about X might be a waste of time".
You completely disregard human emotions as if doing so makes you stronger, but all it does is make you more confused, surprised and angry whenever you're faced with irrational reactions you can't understand.
Now if you decide to interpret all of that as me saying "I am in moral agreement with the dogpiling and the witch hunts shown in that github thread", that is a failing of yours.
I don't think any of this relates to the post it's replying to. I appreciate the totally failed attempt to psychoanalyze my emotions, though. If you think I'm 'confused, surprised, and angry', you don't seem to be as good at the emotions thing as you keep acting like you are.
What in the AI discourse is trivially false? On one side we have almost all the money in the world, owners of giant social media companies, with easy access to media, who buy ads, etc. to tell you that half of us will be out of jobs in the next 6 months, that AI superinteligence is coming next year, that singularity is upon us, that Claude Mythos will cause so much harm it has to be contained, etc. etc.
I consider all of the above trivially false untruths. But on the other hand you have rsync users who are fed up with all the lies, all the propaganda, all the fear mongering brought up by literally the richest people the world has ever seen, who have experienced AI slop first hand, who have been tricked by AI music, are fed up by all the AI generated posters at their local coffee stand, have given up on trying to correct their coworkers AI generated code during peer review. And now these rsync users see AI slop has been pushed to their favorite tools, and see a new bugs popping up at the same time.
I consider the latter a completely understandable reaction. Yes they jumped to conclusion, but in doing so they have evidence. They have both anecdotal and circumstantial evidence for their conclusions. In comparison, the AI singularity people have nothing but vibes and science fiction behind their conclusions.
Why is the guy being rigorous worthy of criticism, but the guys being idiots aren't? Did you post any similar calm-down comments in either of the HN threads on the original attacks?
I am more inclined to be critical of AI boosters, so what? Am I supposed to crumble under the weight of immense cognitive dissonance because I have... a stance in the discourse?
These guys on the github thread aren't my friends, I have no concern for them embarrassing themselves or leaving a bad digital footprint by drawing ms paint gore. I also have no concern for OP, but it just so happened to be the post I found, and I just so happened to be in the mood to leave a comment.
Engaging in LLM discourse is already a waste of my time, I'm not going to waste more of it just to avoid fallacious accusations of double standards because I didn't "do the same for the other side".
You may notice no language on the planet does this. That is because it is bad. Type guesstimation is a great way of ensuring random problems crop up in random places where they aren't expected and of making the typechecker much slower and more prone to unresolvability (see Swift's multi-minute compiles). All to save you from having to learn what an iterator is, in case you come from a language where lists are more common than iterators; the experience of being scared by a type, and then discovering that the type is not scary in chapter 13.2, is not actually worth making the simple type system instead staggeringly complicated.
> You may notice no language on the planet does this. That is because it is bad.
Perhaps I've explained this poorly, but C#, Java, Perl, & Haskell (and I'm sure others as well) do versions of this already...
You even seem to imply that Swift does, though I have almost no experience directly with Swift.
The vast majority of times it is NOT ambiguous. The compiler can flag it, IFF you want it to.
If you're coming from Python and you want to ease your learning experience, you probably don't want to hit several brick walls before you can do anything...
If you have an enterprise codebase, you probably don't want to allow anything to be compiled that could be ambiguous, so you can force that mode of compilation (and likely should)...
I don't know of any major language which have progressive modes of compilation like this. I think people will find it useful.
Maybe it'll be a disaster. Time will tell. The whole point is to intelligent design the modes such that you can't ever get a MASSIVE surprise "upgrading" from one mode to the next, any error that is too hard to resolve basically automatically / through selecting options needs to be dealt with at the easiest mode.
In none of the languages you mentioned do stdlib functions either return an iterator or a list depending on whether you feed it into an iterator operation; in none of the languages you mentioned can a fully-generic return as a method receiver be inferred by the name of the method. It has nothing to do with how well you explained it; it just doesn't exist. Every single thing you are complaining about exists in all of the languages you brought up, although Perl does a small portion of that in some cases depending on the variable sigil (ie still not guessed).
Your post is a restricted special case of "it would be great if any old sequence of characters compiled correctly and the compiler just read my mind". Wouldn't it just, but the rules of programming languages exist for more purposes than just annoying the user.
I think you're stuck completely on the iterator example or only named functions (which makes sense, since that's all you've seen), rather than several languages supporting various types of polymorphic returns and/or downstream target typing (mainly in lambdas or with sigils).
Certainly if you allow a language do something like:
Which, essentially, defaults to calling collect to an Array for you when bound to a variable, or when chained to a function that doesn't take an iterator but does take a String Array. And in a different mode of compilation, there are no fallbacks (you're back to Rust).
Sure, I don't know a language that supports polymorphic return exactly on `.split()`, but there are languages that support all of the different mechanisms to do this intelligently.
You're assuming the implementation is going to do a number of things that would cause either code bloat or force ambiguity (and potentially a number of other assumptions).
I think you're also assuming the type is not resolved until who knows what happens to it, rather than once it's bound.
None of those HAVE to be true.
To the best of my knowledge, for the most common cases, this can be solved, and when it can't, the compiler can flag it.
None of the languages you mentioned support this 'eager_fallback' feature, no. I am not stuck on any one application of the feature (you'll notice I referred both to the individual application and the general feature, and then you ignored it), but rather you are overindexing on generic returns, which are insufficient for what you're describing in a load-bearing way. Rust supports what C# supports, on the subject of generics (in ways germane to this feature), and what Rust lacks, C# also lacks. So your reference to C# supporting this is false. The feature you are proposing exists in zero languages on the planet. The thing you can get, top-generic returns, exist in Rust and the languages you mentioned, and don't accomplish your named goal at all because you can't use them as a method receiver without disambiguating them.
In my experience working with newbies, the alterations Brown makes to the chapters on borrowing are strictly worse. It is entirely focused on ramming the difference between the stack and the heap down your throat, which has nothing to do with ownership and borrowing, and newbies will frequently say that they are extremely confused by the chapter, then sigh in relief upon reading the original version. Just use the official guide, nobody has improved upon it yet. https://doc.rust-lang.org/book
And then you look it up once, and now you know what it means forever. By contrast, the former expression is much wider with more going on, and furthermore you can't skim past it being sure nothing funny is going on because it may or may not be a range compatible with the latter form.
Not, in fact, correct. Knowledge only cements itself in the brain when it's regularly referenced. Because `>=` and `<=` borrow well-established concepts well-established, they are both intuitive to people reading them for the first time, and easier to solidify or to re-infer for someone who's forgotten their meaning.
> Knowledge only cements itself in the brain when it's regularly referenced.
While true, this is a molehill, not a mountain, of a bar, like "coding once in a while". I'm doing mostly SRE work, and this syntax has no trouble sticking in my head, and I encounter it pretty regularly? (And heck, most of my work these days is in Python, so there I get the >=,< syntax and yearn for the ~mines~ caret, and I still recognize it?)
If you're actively developing a codebase, this definitely isn't going to be arcane trivia.
I'd argue that complaining about using combined "greater than" and "less than" operators instead of the caret is about the same size of molehill as complaining about the usage of it. Seeing either of them in dependencies at my job would be a pretty mundane event that I wouldn't bother trying to do anything about.
For what it's worth, even as someone who's known about the syntax for over a decade, I think there have already been two times this calendar year that I've mistakenly gotten the meanings of the caret and tilde operators on package versions mixed up and been corrected on it.
Also worth mentioning that a carat doesn't require quoting in your shell so you can type `uv add something^1.5` which is a hell of a lot easier to write than `uv add "something>=1.5,<2.0"`.
By 2021, we'll have completely abandoned light switches. We'll just use an app on our phones to turn off the light in the bedroom, or perhaps request out loud for Alexa to do so. The future is the Internet of Things.
I think this article is too soft a criticism by half. The iPhone defining the mobile era was not an artefact of the Apple logo being on it. Every bit of Apple's relentless productization went into what features the phone actually had and how they were integrated. This guy, in 2006, would have been telling Apple 'just release a feature phone like BlackBerry does, so you can define the era of feature phones like you did MP3 players'.
I've been using Siri (via homekit) to turn all my lights on and off for about 3 years now. It's steadily getting worse and worse as somehow, Siri is becoming less accurate and Apple is failing to adopt this new technology in a timely fashion.
I would like to tell it to turn off certain light in a certain room, but unless I get the exact string name of those light correct when I speak, Siri doesn't know what I'm talking about. And it can't do multiple things in a command. I can't say "turn off all the lights in XYZ room" or turn of "this light and this light".
Meanwhile, I can vaguely tell a computer behind my tv to do very complicated things (build me an service that ...) and it can execute on it fairly well. But in apple's "product vision" which I am apparently too dumb to decide for myself what I want, I can't ask for two lights to be turned off at the same time.
> crates.io is moving away from GitHub-only authentication
Crates.io has not moved away from Github-only authentication, and got into the habit of yelling at people who complained about it.
> crates.io's attachment to GitHub is a fact about crates.io specifically, not the Cargo crate registry protocol
Is this just trivia you wanted to share? I feel like I covered it in the second sentence of the comment you're replying to.
> Cargo's support for Git repositories is generic across Git and has nothing to do with GitHub specifically
I'm looking to compile Rust projects from the semi-standard commonly-used crates. I do not want a Github account.
> Radicle offers nothing to a crate registry that a Git remote doesn't
Radicle offers peer-to-peer hosting that does not require a Github account.
> none of this has anything to do with the GPL.
Radicle is a project being built in Rust that partially reimplements git. Git is GPL-licensed, Radicle is MIT-licensed.
> It feels like you're just listing off things you like and don't like aesthetically.
I am unconcerned about your feelings. What I was saying is that I would like a peer-to-peer hosted, namespaced code repository that mirrors (or replaces) crates.io, and I do not want a github account to be necessary to use it.
> They have nothing to do with each other structurally.
I have no idea what "they" is referring to in this sentence.
Thank you for repeating yourself in exactly the way I was criticizing without really reading the criticisms. So, once more with feeling: Radicle does not offer the Cargo crate registry protocol. Radicle does not offer anything to do with crate hosting that a generic Git remote doesn't. If you want a crate repository like crates.io, you do not want Radicle. The best crate repository software is Cloudflare's Freighter, but if you were to implement some sort of distributed version, that's also an option, but it wouldn't be called Radicle. If you just want the Git support that Radicle offers, you can do so just fine without Radicle; it is generic Git remote support, and you can declare Git dependencies in Cargo.toml from Sourcehut or Codeberg or whatever. Radicle is a product that puts issue/PR tracking on top of Git. It does not have anything to do with what separates git dependencies from crates.io dependencies, it does not have anything to do with automatically mirroring existing hosts, it does not offer anything to the git dependency experience, and it does not offer anything to the registry dependency experience.
> Crates.io has not moved away from Github-only authentication, and got into the habit of yelling at people who complained about it.
This was me updating you on the present state of the world. Replying with the previous state of the world, as though this is somehow new and better information, without even looking up whether it was still true, is a level of deliberate ignorance I can't fathom displaying on purpose. Again: crates.io is presently in the process of moving away from GitHub-only authentication.
But after enough people run it, that disappears. They implement crowdsourced trust, because it isn't a rent extraction exercise but actual concern about malware.
This sounds completely made up. The medieval taxman has no idea how much gold you have squirreled away, and even finding everyone to tax them was hard enough. Most peasant taxes were based on productive land and observable yields thereof, and the rest were import/export duties. IE income and not wealth, because nobody was stupid enough to implement a negative growth rate until the 21st century (unless they were actively trying to loot holdings for redistribution, e.g. varlık vergisi)
I do know why your post is downvoted, and I disagree with it. Here is my upvote.
I read the link that you shared. This is genius. To quote:
> Community backed
> Fody requires significant effort to maintain. As such it relies on financial support to ensure its long term viability.
> It is expected that all developers using Fody become a Patron on OpenCollective.
I can remember years ago reading some posts/writings from none other than Richard Stallman (yeah, that guy). He was talking about charging people for a copy of the source code to your open source project. At the time, I thought it was weird and did not make sense. This is basically the same thing but in 2026. After watching so much bullshit around open source projects (basically, assholes expecting free service for whining the loudest), I have come to the conclusion that "money talks" and helps to realign incentives that are warped by open source.
Are you being ironic or serious? I can see both pros (encourage people to see themselves as customers) and cons (less initial adoption) to the licensing, although I'd maybe leave bug issues open for everybody.
Serious. And although 'seeing yourself as a customer' certainly makes things slightly better, I'm also referring just to the amount of cash that enters the coffers once it's no longer a tip jar per se. It is open source on the subject of copyright, but as was described in an article on here the other day, open-source doesn't mean community. By positioning the community aspect as something you have to buy into to enter, you end up (a) selling a product for cash without compromising open source and (b) ensuring everyone you deal with is serious. It's like the Red Hat model but workable at the lower end of software at the expense of lower upside.
reply