Why did not they make their stance clear? Make it clear you’re not accepting contributions.
Why should they? They’re just sharing their work.
Basic etiquette.
I think, with time, people will start to recognize that stale-botting is just putting a robotic coat of paint on the same boorish disrespect for others that is on full display in places like Twitter/X and YouTube comments.
If you don’t want to follow the implicit norms of the greater community, state so up-front. You don’t need to write a fancy legal document… just have the backbone and common decency to tell people what to expect of you, rather than ghosting them.
All of the perspectives raised carry an undercurrent of “I’m so special that I don’t have to engage in common decency”. Heck, now that I think about it, I think part of the reason stale-botting irks me so much is that, on some level, it feels like the decision to use a stale bot is passive-aggressive behaviour.
I dunno, I believe users who treat open source projects like they’re a product they’re paying money for, and who demand to be treated as paying customers, are the ones who are boorish and disrespectful.
Which is exactly the passive aggressive behavior the thread starter is referring to. I would say if you don’t have the mental energy, maybe let the issues sit open until you do.
Why is it passive aggressive? They have have a project, they are happy to let others use it, but they aren’t (yet) expecting to follow everyone else’s needs. Let them deal with their project how they wish, without having to apologize to everyone for everything in advance.
Because human communication has norms. If I spit in your face. It doesn’t matter if I think it’s not a grave insult. What matters is what the cultural norms we exist in consider it to be.
Yes, that’s my point exactly. Why did the commenter above think that this behavior is passive-aggressive? Because I don’t, and they apparently do.
So yes, human communication has norms, but as far as I know, one of them is “my house, my rules”. Why should users expect that some project runs issues just the way they, the users like it? Why can’t they just abide by the rules of the house? The maintainers could very well be passive-aggressive, but maybe they’re not, maybe they just don’t have a lot of time or interest in chasing bugs.
That’s what I’m referring to - we cannot assume someone has a certain state of mind (passive aggression) based only on the fact that they employ a stalebot. We would need other source of data. Stalebot is most certainly a norm that some projects use - but not all - so why can we say it’s wrong to have them?
Yes, that’s my point exactly. Why did the commenter above think that this behavior is passive-aggressive? Because I don’t, and they apparently do.
I’m the person who said it originally and I said it feels like passive-aggressive behaviour and that’s why it bothers me so much.
So yes, human communication has norms, but as far as I know, one of them is “my house, my rules”. Why should users expect that some project runs issues just the way they, the users like it? Why can’t they just abide by the rules of the house? The maintainers could very well be passive-aggressive, but maybe they’re not, maybe they just don’t have a lot of time or interest in chasing bugs.
Because you’re publishing your project into a public space with defined expectations. Psychologically, it’s closer to renting a space in a shopping mall than a private home, and people are upset at “how rude the staff are to window-shoppers”.
If you don’t want people wandering into your rented commercial space with expectations of your behaviour, then post proper signage. Just because the “mall” has effectively no size limits and offers space for free doesn’t change that.
Again, this is very situation-specific. I personally had had office space rented, when I was freelancing a lot. It was a small space next to a cafe. I didn’t mind people smoking on the caffee’s terrace, but I did mind if they did on mine. (I really didn’t. But it works for the example).
Now, I can expect that people will come in my commercial space because it’s next to that cafe. And I can also expect that some of them will be smoking a cigarette. Which is also fine. But despite all that, if I ask them to put the cigarette out, or if I stale-bot their stale issue, I don’t think I’m aggressive. I just think I have my rules, and in my (rented, commecial-space) back yard, I should not have to feel pressured to explain the reasoning behind those rules.
Once more: the bottom line is that the passive-agressive feeling is very personalized. I may really like some behavior where you might not, and we’ll feel different kinds of pressure when witnessing said behavior. That’s why I think that the passive-agressive comment can’t really stand as it is overly generic.
The comment about it feeling passive-aggressive was secondary anyway. The primary point was that it was an active violation of the etiquette of the public space they set up shop in.
The funny thing about my mall example is that you’re responding to draft #2, where I now think draft #1 addressed your point better. Originally, I couched it in terms of setting up a library in a mall unit and then sending out a “shush bot” to patrol the segment of hallway in front of it rather than setting up proper sound insulation.
It’d just make people want to kick the bot and resent its owner.
Yeah, the passive-agressive stuff is not really relevant. I still disagree your point though. Why is my issue tracker, for my project, public space? Why do passers-by get to dictate my rules?
I don’t think we’ll agree on this. You seem to think that issues should not be automatically cleaned up by stale-bots. I disagree - not in that that I think that they should be automatically cleaned up, but in that that the choice is on maintainers and maintainers alone, not on the users of the project.
Do you mind if I ask a question or two to try to get a sense of your position on that before we part ways?
I’d like to get a sense for what you believe is reasonable to allow the project maintainers to decide. For example, I doubt you’d argue that GitHub should be prohibited from kicking users off their platform for gross abuses (eg. using a bug tracker to coordinate treasonous or genocidal activities), so there has to be a line you draw and the question is where you draw it.
(eg. Which side of the line is it on for you if maintainers choose to set a “norm” where they verbally abuse people who report bugs?)
Oh, but those two aren’t exactly the same, deciding whether to use a stale bot vs. being abusive, it’s pretty much different things we’re talking about.
To be upfront, I believe it’s absolutely reasonable for the platforms to deal with abuse. I also think it should be required, but it’s hard to set the limits of “what is enough”. But that topic is moderation, we’re talking stalebots here.
If you’re asking me if I would use a stale-bot, probably yes. I frequently have some inner-source or closed source projects, so it’s a bit different, but I would still use a stale-bot if I didn’t have someone who’s already triaging the backlog. That is not applicable here, though, since I don’t think I ever had a project with 300 open issues. Or if I did, they would be neatly “organized” into epics and stories and stuff, and out of my “current sprint” or whatever, and I would actually be paid and reserve the time to triage them.
For open source, I probably would like some automatiuon if I didn’t have the manpower.
Do you think, what’s my position in general? After a small consideration, I believe on most of these things I am quite liberal.
Each person gets to decide for themselves, as long as they don’t impinge on other people’s freedoms or break public rules. It may be sucky, and we have to work on that, but as long as it’s “allowed” by the general rules, we can’t and should not force anyone to do anything a particular way.
But even more, I don’t like “having a position” at all, mostly. I like having observations on how things work. You know how it is in software: for most questions, an experienced developer will answer majority of questions with “it depends”.
It is very often a question of a trade-off, not of “should we or should we not”.
In this case (stalebot), I think it is absolutely okay for maintainers to decide to use a stale bot. 100% their choice. Even if it was something that is as widely used as linux kernel - they are the maintainers, and they have to maintain the thing, so they get to pick what they want to do about stale issues.
People picking stalebots are probably not doing so much triage. I’m thinking e.g. Angular, where I frequently found open issues on my topic that are untouched for a long time. Sucks, I have no clue what’s with the issue, why is it still open, is it being worked on or what. (To be honest, I haven’t visited Angular GitHub repo in a while now).
People leaving open tickets probably do a bit more triage, but the already mentioned Angular example shows it’s not always the case.
As an end user in such a project, I am stuck either way. Either the issue is stale-closed, or it’s open but untouched, and I have no clue what to expect. Well, with a stale-closed issue I can probably expect nothing, with the open-but-untouched issue, I probably have nothing to look forward to as well, but there’s some false hope that it may be tackled sometime.
So, for me as a user it is usually irrelevant about what the maintainers decided.
Is it okay for Microsoft/GitHub to say, “no stalebots allowed”? Absolutely. Their company, their rules. We do have a choice (and I mostly do choose to go elsewhere). So now if maintainers want a stale bot, they have to go to GitLab or something.
Again, all perfectly within the bounds.
I don’t think my thoughts on any of that matter, though, they are just observations. Again, this is more a trade-off, then a final position - what is more valuable to me, at this time, vs. maintainer, vs Microsoft.
I don’t know if I answered your somewhat-open-ended question well enough, feel free to ask more.
I think you answered it fairly well and I’m not opposed to stale bots in general. In fact, I think it’s probably a good idea to have bots that tag things as “stale” for easier filtering for or against. It’s just the closing of issues that is the problem.
Likewise, I’m much less opposed to stale-botting with closure if the maintainers post clear notice so people know what they’re getting into before they invest their time, but I’ve said that before, so let’s not start that up again.
A house is a poor framing for open source…it lacks the collaborative element.
Or… maybe it’s apt after all, but only if we think of it like a community barn-raising. You need a barn, so all your neighbors help you raise it. In turn, you’re expected to help them out when their time comes.
And if one of your neighbors barn gets struck by lightning and burns down, you’d have to be a terrible person not to offer to let them store some of their stuff in your barn until a new one is built.
No, I didn’t mean for the house to be the analogy, I meant, it’s their project, not a community project.
I get that a random third-party can get interested and involved and challenge the rules, but it’s still those project’s rules.
Look at the extremes. If someone came, and raised a pull-request on your latest zig hobby project that rewrites everything in Rust, or PHP, or whatever else, you would probably reject it. You made the technology choice for your own reasons. Perhaps to learn zig, perhaps for the fancy comptime. Rejecting that PR is pretty straight-forward, right? They can offer reasons (“it’s better”, “it’s faster”, “it’s slower” or similar). They can open a discussion. But with or without the discussion or reasons, if you simply reject the pull request with just a note “We decided to do this in Zig”, it would not be a problem, right? It was your technological choice.
I see it the same with the stale-bot choice. It was your project-management methodology choice. You could accept discussions, or be willing to change your potentially-inefficient project management ways, but if you don’t it’s your choice, since it is your project.
I know the two decisions are not in the same area (tech choice vs project management methodology choice). But those are the chosen ones for that particular project anyway.
That is what I meant by “my house, my rules”.
Does my reasoning make sense to you? I mean, I get that you still may not agree, but can you at least accept my point of view on why we shouldn’t expect people to stop using stale-bots, even if it’s inferior?
I understand your framing, yes. I just don’t think it’s correct to ignore the community aspects. And a PR about rewriting in another language is a bit of a straw-man; it’s an exaggerated hypothetical scenario that isn’t the real problem that arises.
Consider it from the perspective of copyright instead. My contributions to another project are under my copyright. It’s standard now to force contributors to assign their legal rights away (via CLAs), but the copyright still remains mine. Without CLAs, every project would be forced to treat their contributors as full participants. CLAs distort that.
Regardless, a contribution of code and assignation of legal rights is a gift, and warrants social consideration, if not legal consideration. It can be mostly, but not solely, your project.
Yes, I’m aware that that was an extreme example, I wrote so. I’m just saying that it’s very clear that there is some boundary where it is okay for me to have my rules for my project, and regardless of the quality, size, value of your contribution, I do not have to accept that contribution. Now, if we can agree to that - that some things are under my control, I just think that most people will have different opinions on what things are mine alone.
I think it’s acceptable for maintainers to decide on the stale-bot rule. I may think that in some cases it’s wrong, in some others it’s the correct way, but in no case do I think that I have any say in their decision. I may provide input, or express my wishes or preferences. I may try to persuade them, or pay them or whatever, to take that decision one or another way.
But whatever they decide, I don’t think it should be considered rude, anti-social, not-in-spirit-of-open-source or any of the things this entire comment section is mentioning - it’s just a simple project management decision, in my eyes, and it is theirs to make.
Taking the time to write up and submit a good bug report (potentially including investigation of relevant code, surrounding behaviours etc) is not treating a project the same as a product you’re paying money for. Having such bug reports closed by a bot is pretty annoying. I don’t want to waste my time submitting bug reports if the maintainers aren’t interested in actually fixing bugs, but this has happened on any number of ocassions (not always with stale bots involved, sometimes the bug just sits in the bugtracker forever) with various projects.
Sure, there are lousy users with excessive expectations and demands as well. That doesn’t justify ignoring quality bug reports. If you don’t want bug reports, don’t have a public bug tracker, or at least make it clear exactly what kind of bug reports you do and don’t want and what sort of expectations the submitter should have. As a maintainer you don’t have the right to waste people’s time either.
Let’s say that in this situation, the project doesn’t use a stale bot, but everything else remains the same. Your finely crafted high-quality issue goes unacknowledged and un-actioned indefinitely. The end result is the same: you feel rejected and disrespected.
Not using a stale bot is not going to make a maintainer action your issue faster.
Ah, but having a huge list of unanswered issues is a red flag! You would not contribute time and effort to such a project. And that’s true. So what you need to do now, before submitting an issue, is to check the list of Closed issues, and eyeball if they’re closed by a stale bot or not. This is a tiny bit of extra work but less than submitting a good bug report and then nothing happening.
No, if my bug goes perpetually un-answered, I assume many things (maybe the developer is overworked. Maybe, like me, they have ADHD. etc.) but I don’t feel actively rejected and disrespected.
If they use a stale-bot, it feels actively user-hostile. It says “this person doesn’t even have the decency to leave my report to languish”.
This is pushing the responsibility on to the wrong person. It’s easy enough not to think to check through issues to see if they’re being dealt with appropriately; especially so if there’s a detailed issue template (for example) that makes it look the project takes bug reports seriously and there are no obvious “website is only held together with sticky-tape” signs that hint a project isn’t really maintained. I don’t think to check for auto-closed bugs before opening a bug report (but thanks for the suggestion, it’s something I might try to do in future); the tendency for projects - even large, supposedly maintained projects - to simply ignore bug reports (or auto-close them) isn’t something I expected until bad experience taught me otherwise, with however much time wasted in the meantime.
The result: I tend to put less effort into bug reports now, if there’s any indication at all that there might not be any interest from maintainers. If the maintainer responds at all, I’m always happy to do more legwork, but speaking as a maintainer myself, this still isn’t optimal.
On the other hand it’s trivial for a maintainer to simply shut the issue tracker down, make it private, or at least stick a note in the issue template (or even the project README) that the issue tracker is for maintainer use only (or whatever), without risk of wasting anyone’s time at all and without generally bringing down the open-source experience. I would do this; I’m not asking anyone to do anything I wouldn’t do myself, and I think it’s a better outcome than either abandoning the issue tracker or auto-closing bugs in it. But if it has to be one of those, at least just abandoning the tracker makes the state of the project clear.
It’s later addressed in the post. Sure it’s “basic etiquette” once you know it. But you may not even be aware of it. The use of stale bots is not necessarily evil. These are just some unspoken rules we’ve come to agree on. And I think maintainers should be educated rather than shat on here.
Also lol @ the flags on this post. I searched for it before and didn’t see it already posted. And I have no idea how “no stalebots” could be on-topic but “yes stalebots” off-topic…
Users can flag stories and comments when there’s a serious problem that needs moderator attention; two flags are needed to add the story or comment to the moderation queue. Users must reach 50 karma to flag. To guide usage and head off distracting meta conversations (“Why was this flagged!?”, etc), flagging requires selecting from a preset list of reasons.
For stories, these are: “Off-topic” for stories that are not about computing; “Already Posted” for duplicate submissions and links that elaborate on or responses to a thread that’s less than a week old (see merging);
Adjustment layers been the longest WIP. At least the prerequisite GEGL is here now. I adjusted my photography workflow so that I can do everything with darktable (and Hugin) to get around the non-destructive situation with GIMP—luckily you’ve been able to retouch skin via wavelet decompose inside a darktable module.
While for many users, a specification would just be “nice to have”, there are also Rust users for whom such a specification is absolutely necessary to be able to use Rust for the field they work in. For example, safety critical Rust software for automotive or aerospace applications usually needs to pass certification, a process designed to gain confidence in the exact behavior of software through, among other things, specification and testing.
This is a great example of why I’d really like a “flag: blatantly incorrect”.
On Mercurial, as many others have pointed out, the author didn’t actually read the page they wrote on. Contemporary Mercurial runs great on Python 3, thank you very much, and is well on the way to porting to Rust.
I’m no Fossil fan, but even I know that the error they’re highlighting with Fossil is because the Git repository isn’t valid. [edit: see note below; I’m wrong on the issue on that repo, but the rest of this paragraph is vald.] I hit this type of issue all the time while working on Kiln’s Harmony code. If you’re bored, try setting fsckObjects to true in your .gitconfig. You won’t be able to clone roughly a third of major repos on GitHub. (The ratio improves dramatically for more recent projects until it hits 100% success for stuff that was kicked off in the last couple of years, but anything five or more years old, you’re gonna hit this type of issue.)
Darcs is evicted over its website being HTTP, which has nothing to do with Darcs. Pijul over the author having no clue how to write code in Windows.
The author is trolling. Poorly. And somehow this is highly ranked on the front page. Let’s do better.
Edit: correction the Fossil bit: After two seconds of poking with Fossil and Git fast-export on Windows, the actual issue with their Windows repository is that they’re in a command shell that’s piping UTF-16 and/or sending \r\n. This is also something any Windows dev should recognize and know how to deal with. If you’ve set the default shell encoding to UTF-8 or use a shell like yori that does something sane, you won’t hit this issue, but I’d sure hope that anyone using Windows full-time who refuses to set a UTF-8 default is habitually slamming | Out-File -encoding utf8 after commands like that.
For Pijul it’s even worse, it’s over (1) the author relying on contributors to test and fix on platforms other than Linux and (2) WSL not implementing POSIX correctly, but blaming Pijul’s author is easier than blaming Microsoft.
Also, she knows it, has contributed to Pijul after that post, and has never updated it.
I wouldn’t go as far as saying “the author is trolling”. To me it’s an opinion piece where, sure, the author could have put some more effort, but that’s their particular style and how they chose to write it. To be fair I did not expect it to be this controversial. It does mention some points on what a “better git” would need to do, even if it’s a bit snarky. Particularly the suggestions at the end. At the very least this thread has brought a bunch of good alternatives and points 🤷♀️.
They’re switching to opaque pointers surprisingly quick — this version enables them, and the next version will only support opaque pointers. I assumed it’d be years-long deprecation process rather than 6 weeks.
I believe it’s also most correct to say that * works with any iterable and ** works with any mapping — that’s a much broader scope of things than just list and dict.
There’s a similar sharp edge in Rust in that it enforces UTF-8 clean strings, but cheerfully lets you create slices like &mystring[0..64] while actually using byte indices. It works perfectly until one day the entire application crashes because someone had a multibyte character wrapped around index 64. It’s possible to code it correctly of course, but geez it can be sneaky sometimes.
Indexing through [...] is panicking when out of bounds (this is true for slices past their length, and your example). .get(...) on the other hand will return None for those out of valid-bounds cases. I presume it’s a matter of interiorizing this behaviour of the square braces (or, depending on the use-case, explicitly using .as_bytes()).
This requires all fields to be public, and when all fields are public, then addition of a new field is a semver-break (you can’t expect all users to always add ..default()). I had such whack-a-mole with comrak config.
Unfortunately, this also forbids construction of the struct outside of the defining crate. Same if the struct has any private field. The ..default syntax has no extra privileges, and can’t do anything that couldn’t be done with a struct literal.
A new attribute #[non_exhaustive(pub)] or a trailing pub .. field, which indicates that only public fields will be added (i.e. adding private fields will be source breaking).
Allowing a move keyword in the functional update syntax{ x: 42, .. move foo } that sidesteps the issue by desugaring differently (first taking foo, and then assigning the given fields).
The second is more powerful since it allows private fields. Changing the functional update syntax to always desugar that way would could break existing code, hence the move keyword. Either of these combined with default_free_fn or making .. shorthand for ..default(), would be pretty nice.
This is one of those things where I’d personally be in favor of Default getting special treatment to enable some pattern of “construction with certain things set to custom values, but otherwise default” that doesn’t require the crate defining the type to explicitly provide such a constructor.
You could find similar content in other places, but the interactive graph ⇄ matrix view at the end is interesting.
Apart from that, the link to the Spanish version is 404.
I would also propose to have the link text be in Spanish, since in principle, if you can’t read English you would not figure out that a Spanish version is available. I realize that pretty much everyone interested in the subject is going to know at least enough English to get that, it’s just a general principle which becomes more important when the languages have different alphabets/ideograms.
So, instead of “Don’t know English? Read the Spanish version instead.” I would have “Don’t know English? Lea la versión en Español.”: the first part tells English speakers why there is a segment in another language, the Spanish version speaks to those that don’t speak English.
Looking around your blog, there are other 404 links, like the Spanish version of “Sentences”, and the English version of “Writing our own Cheat Engine: Multilevel pointers”: the previous part, “Code injection”, is fine.
I would suggest setting up some 404 detection mechanism, either as part of your build pipeline if you use one, or a web crawler like wget. There were command line tools specialized for this, but it has been many years since I looked into that and I forgot their names.
Thanks for your feedback! The Multilevel Pointers was a draft not meant to be published yet but I pushed it in a rush trying to fix a different thing and could only partially delete the page. The blog used to be hand-written HTML, but I moved to Zola recently-ish because that was a pain, so I’m not surprised I missed a few links.
In addition to being a good blogpost, I have an ulterior motive here. @lonami’s asked a while back if submitting his own stuff was okay, and we said it was fine, but he hasn’t taken the leap yet. So I’m taking it for him :)
<3 – This post in particular was made back when my blogging skills were pretty “young”, and I posted it because I found it really fascinating when we got the lecture at university. Too bad we glossed over it because we ran out of time. There’s quite a few fun things I learned there, calculus was also really cool (for someone who didn’t dig up too much into math on their own before).
Fix the broken Eq/PartialEq, Ord/PartialOrd design.
Throw out the useless semicolon rules.
Replace -> in function declarations with :.
Remove ! syntax for macros (creates the wrong incentives).
Runner ups:
Fix/remove the horribly broken Path::join. (Or rather replace Path/PathBuf with an abstraction where you don’t have to decide how to implement the method, because it simply won’t compile.)
I seem to remember you and I have debated this before, but I don’t think it makes any sense to call the semicolon rules useless. Semicolons convert expressions into statements, and quite apart from the fact that there needs to be some syntax to do that, because Rust is an expression-based language, the visual distinction that you get from a line ending in a semicolon or not allows you to tell at a glance whether something is an expression or a statement.
What do you think you’re accomplishing here? Toddlerized argument via repetition pollutes conversations, demonstrates bad faith, and literally makes this site less valuable to others. I’d suggest that you follow the moderators’ advice: step away from the keyboard for a while until you can engage in mutually respectful discussions.
The issues are not made-up. Please accept that people may disagree with your opinions for other reasons than losing grip on reality.
Other languages have just chosen different trade offs in complexity of parsing, flexibility of the syntax, and risk of semantic changes caused by line wrapping.
I don’t have 5 complaints about Brainfuck. I have one: Lack of semantic richness.
It’s syntax is actually pretty good, considering what its semantics are. Other languages with the same semantics and different syntax exist, and they also suck.
In Verona, we’re doing the same thing as Pony: [] is for generics, () is call syntax, array access uses call syntax on array objects. It’s a slightly odd decision in C-family languages to have separate syntax for them because C doesn’t have anything that is both indexable and callable (you can’t use array indexing on function pointers), but it’s a necessary hack if you want to write a single-pass compiler that runs on a system with 128 KiB of RAM. A lot of earlier languages used the same syntax because an array is, at the abstract level, just a map from integers to some other value. C doesn’t think of the abstraction like this and thinks of an array as syntactic sugar for pointer arithmetic. C++ keeps this distinction for standard library collection types, but I don’t think I’ve ever seen a C++ class that overloaded both operator() and operator[].
The big issue with <> for generics (or anything else) is that < and > are both allowed in your program as stand-alone identifiers. This means that you can’t spot a missing angle bracket until you’ve done type checking, whereas you can spot a missing other kind of bracket / brace after tokenisation, before you even parse.
it’s not overloading array indexing, because [] for generics is in types, and [] for indexing is in expressions. As far as I can tell, rust grammar is sufficiently well designed that these are never ambiguous.
edit: that was snarky. It’s not worse than <>, we’d just have the turbo hammershark or something like that instead of turbofish, but you do have a point. D uses foo!(bar)(baaz) to separate template and regular arguments, for example.
I might be wrong, but I think the main motivation behind using [ rather than < is exactly to get rid of the need to disambiguate expressions vs types via ::
If we are fine with replacing turbo-fish with turbo-snail, than yes, just switching the sigils works.
Ok, foo isn’t an array, but indexing works for all sorts of types in rust not just arrays. It’s calling the Xth element of the collection foo, where foo happens to be a generic-function collection type.
Yeah, using the same grammar for type references and expressions and disambiguating on semantic level might work. But that’s a way bigger change than just using [].
I wonder if optionality of type arguments would prevent this? Like, foo[()][()] where the first indexing with type() seems like it can be ambiguous. As it, is foo[()] a type argument, or a value argument with an inferred type argument?
My gut feeling is that this might not be a huge problem. It seems like “syntax unambiguously classifies the role of expression” property is already lost in Rust in minor way (the prime example would be constant ambiguity in patterns). So perhaps treating the language as a homogeneous tree of things, and classifying then according to semantics later would actually be a clearer model?
The issue is that < and > are already used for less than and greater than signs, so Foo(baz) can either be (Foo less than bar) greater than baz or Foo instantiated with bar applied to baz.
Overloading indexing is fine, because it really is a kind of indexing. Indexing is a function (Container, Index) -> Value, and this is a function (GenericType, ConcreteType) -> ConcreteType. I.e. Container = Type and Index, Value = ConcreteType. As a result it doesn’t lead to the same kind of ambiguities.
Wouldn’t that make AST construction dependent on types, and thus a chicken-egg problem similar to what C has with typedefs?
Forbidding uses of types in expression contexts world be limiting, e.g. you couldn’t “simply” use static methods or associated constants, because they’re expressions, but start with a type name.
It would [1] if you need to represent Type[Type] and Expr[Expr] as different types of ast nodes. I don’t believe that you actually need to though.
[1] You could probably hack around this by checking what symbols are in scope too, but that’s ugly and would probably lead to poor handling of special cases and poor error messages.
The argument I’ve heard is that it makes the grammar more complicated, and leads to some ambiguity issues, which results in things like Rust’s turbofish syntax (::<> iirc) or C++’s .template syntax.
A different approach, Ada uses neither <>, nor [], and instead requires associating a new name to a function-call like explicit instantiation of a type or generic function. It seems like it leads to a proliferation of types, but is an approach I haven’t heard much about.
No, that’s my job. Take a break from this thread and come back way kinder in the future. Feeling like you’re right doesn’t make it OK to heap scorn on people.
What makes using [] for array/map syntax an “abuse”? What distinguishes it from literally any other syntax choice? I could claim that using () to surround function arguments is an abuse of those symbols, but I have absolutely nothing to back that up.
On the flip side, though, if macros aren’t distinguished with a !, then if the author of a macro does do something that isn’t “well-behaved”, the user has even less warning that it’s going to do that.
Which comment? I’ve read all of your replies in this thread and I haven’t seen anything that refutes the assertion that removing ! would just make the developer experience worse if a macro does choose to do crazy things.
Instead, macros should be so well-behaved that users shouldn’t even need to know whether something is a macro or not.
Imagine that Rust users would keep filing bugs about stupid macros until the issue is resolved, just like they successfully did with unnecessary unsafe blocks.
So your solution to this problem is to make Rust developers waste a bunch of extra time filing issues? Instead of the current state of play, which is that every user of these hypothetical macros has at least a measure of pre-warning that the thing they’re calling is a macro and therefore might perform some crazy AST transformation on its input? I haven’t run a survey, but I would hazard a guess that this “macros do arbitrary stuff” problem is not actually a real problem that Rust developers have, partly because the intention of macros is to allow you to do arbitrary stuff.
Rust macro syntax is informed by experience from C where macros have a function-like syntax, and still do surprising arbitrary stuff.
In C this syntax hasn’t stopped people from doing weird stuff with macros, but is stressing users who can’t be sure that everything that looks like a function call is just a function call.
It’s also worth noting that in C it’s considered a good practice to use all-caps for macro names, because even though macros could look just like functions, users don’t want that.
Do you think it’s reasonable to get mad at me just because I changed the software such that you can’t use it anymore?
Of course it isn’t, but I think it is reasonable for people who can’t use the software anymore to discuss what to do, and fork the software so that they can continue to use it, and even advertise to users of your software to switch to the fork in case they want to.
I think this discussion was slightly flawed because it only had author and consumer as the two roles and that relationship was static. When you release something as open source, one of the parts of the social contract is that there’s an expectation that some of the people who find it valuable will contribute. They may contribute money, code, documentation, bug reports, logos, or in other ways. A good bug report with root-cause analysis is a valuable contribution.
Successful open source projects tend to be the ones that have a good pipeline for turning users into contributors. The other side of this social contract is that an open source project is that a project is willing for people to make this transition, from consumer to casual contributor to active contributor, and will welcome them.
Absolutely, but that’s very different from treating the author in a, well, unethical way. The issue is some people both take things way too personally (authors too!) and believe they have certain rights when they actually don’t. As described, the sooner people realize their rights, the better (and discussions should remain civil).
I can relate to this to some degree. But this is a very good lesson to learn: you don’t owe anything to any of those people. You shouldn’t really feel guilty. If they don’t put the effort to create a proper bug report, why should you put the effort to fix it? More mitigations include: issue templates, labels “can’t reproduce”, “question” or “help wanted”, a more strict policy clearly laid down in the README, or even just… disable the issues section. Just make it clear that it is your project and won’t generally work on other people issues, but may accept pull requests.
I still think it’s worth it to publish the code, even if it only “works for you”. Others, who care, may find it valuable. I don’t know what project’s author talks about, how popular they are, or what community uses them (e.g. the entry barrier for Python is a lot lower than it is for other languages, so expect more poorly written complaints here), but I haven’t encountered this situation to the same degree. The compliments are really nice, even if rare (they wouldn’t feel special otherwise).
Aww, that’s cute they use my library. I also attempted a similar tool (backups, but with generic exporters, including HTML so you would get the similar “static website” feel) with a friend. Alas, Telegram changes stuff pretty often, and both the lack of time and interest (on my part) led to the tool being archived. Regarding OP, the output seems really clean from the screenshots. It’s nice to see people build cool things upon my work.
Basic etiquette.
I think, with time, people will start to recognize that stale-botting is just putting a robotic coat of paint on the same boorish disrespect for others that is on full display in places like Twitter/X and YouTube comments.
If you don’t want to follow the implicit norms of the greater community, state so up-front. You don’t need to write a fancy legal document… just have the backbone and common decency to tell people what to expect of you, rather than ghosting them.
All of the perspectives raised carry an undercurrent of “I’m so special that I don’t have to engage in common decency”. Heck, now that I think about it, I think part of the reason stale-botting irks me so much is that, on some level, it feels like the decision to use a stale bot is passive-aggressive behaviour.
I dunno, I believe users who treat open source projects like they’re a product they’re paying money for, and who demand to be treated as paying customers, are the ones who are boorish and disrespectful.
Better to tell them that than to have a bot close their issue
Not everyone has the mental energy to do that, though.
Which is exactly the passive aggressive behavior the thread starter is referring to. I would say if you don’t have the mental energy, maybe let the issues sit open until you do.
Why is it passive aggressive? They have have a project, they are happy to let others use it, but they aren’t (yet) expecting to follow everyone else’s needs. Let them deal with their project how they wish, without having to apologize to everyone for everything in advance.
Because human communication has norms. If I spit in your face. It doesn’t matter if I think it’s not a grave insult. What matters is what the cultural norms we exist in consider it to be.
Yes, that’s my point exactly. Why did the commenter above think that this behavior is passive-aggressive? Because I don’t, and they apparently do.
So yes, human communication has norms, but as far as I know, one of them is “my house, my rules”. Why should users expect that some project runs issues just the way they, the users like it? Why can’t they just abide by the rules of the house? The maintainers could very well be passive-aggressive, but maybe they’re not, maybe they just don’t have a lot of time or interest in chasing bugs.
That’s what I’m referring to - we cannot assume someone has a certain state of mind (passive aggression) based only on the fact that they employ a stalebot. We would need other source of data. Stalebot is most certainly a norm that some projects use - but not all - so why can we say it’s wrong to have them?
I’m the person who said it originally and I said it feels like passive-aggressive behaviour and that’s why it bothers me so much.
Because you’re publishing your project into a public space with defined expectations. Psychologically, it’s closer to renting a space in a shopping mall than a private home, and people are upset at “how rude the staff are to window-shoppers”.
If you don’t want people wandering into your rented commercial space with expectations of your behaviour, then post proper signage. Just because the “mall” has effectively no size limits and offers space for free doesn’t change that.
Again, this is very situation-specific. I personally had had office space rented, when I was freelancing a lot. It was a small space next to a cafe. I didn’t mind people smoking on the caffee’s terrace, but I did mind if they did on mine. (I really didn’t. But it works for the example).
Now, I can expect that people will come in my commercial space because it’s next to that cafe. And I can also expect that some of them will be smoking a cigarette. Which is also fine. But despite all that, if I ask them to put the cigarette out, or if I stale-bot their stale issue, I don’t think I’m aggressive. I just think I have my rules, and in my (rented, commecial-space) back yard, I should not have to feel pressured to explain the reasoning behind those rules.
Once more: the bottom line is that the passive-agressive feeling is very personalized. I may really like some behavior where you might not, and we’ll feel different kinds of pressure when witnessing said behavior. That’s why I think that the passive-agressive comment can’t really stand as it is overly generic.
The comment about it feeling passive-aggressive was secondary anyway. The primary point was that it was an active violation of the etiquette of the public space they set up shop in.
The funny thing about my mall example is that you’re responding to draft #2, where I now think draft #1 addressed your point better. Originally, I couched it in terms of setting up a library in a mall unit and then sending out a “shush bot” to patrol the segment of hallway in front of it rather than setting up proper sound insulation.
It’d just make people want to kick the bot and resent its owner.
Yeah, the passive-agressive stuff is not really relevant. I still disagree your point though. Why is my issue tracker, for my project, public space? Why do passers-by get to dictate my rules?
I don’t think we’ll agree on this. You seem to think that issues should not be automatically cleaned up by stale-bots. I disagree - not in that that I think that they should be automatically cleaned up, but in that that the choice is on maintainers and maintainers alone, not on the users of the project.
But let’s agree to disagree here and move on.
Do you mind if I ask a question or two to try to get a sense of your position on that before we part ways?
I’d like to get a sense for what you believe is reasonable to allow the project maintainers to decide. For example, I doubt you’d argue that GitHub should be prohibited from kicking users off their platform for gross abuses (eg. using a bug tracker to coordinate treasonous or genocidal activities), so there has to be a line you draw and the question is where you draw it.
(eg. Which side of the line is it on for you if maintainers choose to set a “norm” where they verbally abuse people who report bugs?)
Oh, but those two aren’t exactly the same, deciding whether to use a stale bot vs. being abusive, it’s pretty much different things we’re talking about.
To be upfront, I believe it’s absolutely reasonable for the platforms to deal with abuse. I also think it should be required, but it’s hard to set the limits of “what is enough”. But that topic is moderation, we’re talking stalebots here.
If you’re asking me if I would use a stale-bot, probably yes. I frequently have some inner-source or closed source projects, so it’s a bit different, but I would still use a stale-bot if I didn’t have someone who’s already triaging the backlog. That is not applicable here, though, since I don’t think I ever had a project with 300 open issues. Or if I did, they would be neatly “organized” into epics and stories and stuff, and out of my “current sprint” or whatever, and I would actually be paid and reserve the time to triage them.
For open source, I probably would like some automatiuon if I didn’t have the manpower.
Do you think, what’s my position in general? After a small consideration, I believe on most of these things I am quite liberal.
Each person gets to decide for themselves, as long as they don’t impinge on other people’s freedoms or break public rules. It may be sucky, and we have to work on that, but as long as it’s “allowed” by the general rules, we can’t and should not force anyone to do anything a particular way.
But even more, I don’t like “having a position” at all, mostly. I like having observations on how things work. You know how it is in software: for most questions, an experienced developer will answer majority of questions with “it depends”.
It is very often a question of a trade-off, not of “should we or should we not”.
In this case (stalebot), I think it is absolutely okay for maintainers to decide to use a stale bot. 100% their choice. Even if it was something that is as widely used as linux kernel - they are the maintainers, and they have to maintain the thing, so they get to pick what they want to do about stale issues.
People picking stalebots are probably not doing so much triage. I’m thinking e.g. Angular, where I frequently found open issues on my topic that are untouched for a long time. Sucks, I have no clue what’s with the issue, why is it still open, is it being worked on or what. (To be honest, I haven’t visited Angular GitHub repo in a while now).
People leaving open tickets probably do a bit more triage, but the already mentioned Angular example shows it’s not always the case.
As an end user in such a project, I am stuck either way. Either the issue is stale-closed, or it’s open but untouched, and I have no clue what to expect. Well, with a stale-closed issue I can probably expect nothing, with the open-but-untouched issue, I probably have nothing to look forward to as well, but there’s some false hope that it may be tackled sometime.
So, for me as a user it is usually irrelevant about what the maintainers decided.
Is it okay for Microsoft/GitHub to say, “no stalebots allowed”? Absolutely. Their company, their rules. We do have a choice (and I mostly do choose to go elsewhere). So now if maintainers want a stale bot, they have to go to GitLab or something.
Again, all perfectly within the bounds.
I don’t think my thoughts on any of that matter, though, they are just observations. Again, this is more a trade-off, then a final position - what is more valuable to me, at this time, vs. maintainer, vs Microsoft.
I don’t know if I answered your somewhat-open-ended question well enough, feel free to ask more.
I think you answered it fairly well and I’m not opposed to stale bots in general. In fact, I think it’s probably a good idea to have bots that tag things as “stale” for easier filtering for or against. It’s just the closing of issues that is the problem.
Likewise, I’m much less opposed to stale-botting with closure if the maintainers post clear notice so people know what they’re getting into before they invest their time, but I’ve said that before, so let’s not start that up again.
Thanks for the reply.
“my house, my rules”
A house is a poor framing for open source…it lacks the collaborative element.
Or… maybe it’s apt after all, but only if we think of it like a community barn-raising. You need a barn, so all your neighbors help you raise it. In turn, you’re expected to help them out when their time comes.
And if one of your neighbors barn gets struck by lightning and burns down, you’d have to be a terrible person not to offer to let them store some of their stuff in your barn until a new one is built.
No, I didn’t mean for the house to be the analogy, I meant, it’s their project, not a community project.
I get that a random third-party can get interested and involved and challenge the rules, but it’s still those project’s rules.
Look at the extremes. If someone came, and raised a pull-request on your latest zig hobby project that rewrites everything in Rust, or PHP, or whatever else, you would probably reject it. You made the technology choice for your own reasons. Perhaps to learn zig, perhaps for the fancy comptime. Rejecting that PR is pretty straight-forward, right? They can offer reasons (“it’s better”, “it’s faster”, “it’s slower” or similar). They can open a discussion. But with or without the discussion or reasons, if you simply reject the pull request with just a note “We decided to do this in Zig”, it would not be a problem, right? It was your technological choice.
I see it the same with the stale-bot choice. It was your project-management methodology choice. You could accept discussions, or be willing to change your potentially-inefficient project management ways, but if you don’t it’s your choice, since it is your project.
I know the two decisions are not in the same area (tech choice vs project management methodology choice). But those are the chosen ones for that particular project anyway.
That is what I meant by “my house, my rules”.
Does my reasoning make sense to you? I mean, I get that you still may not agree, but can you at least accept my point of view on why we shouldn’t expect people to stop using stale-bots, even if it’s inferior?
I understand your framing, yes. I just don’t think it’s correct to ignore the community aspects. And a PR about rewriting in another language is a bit of a straw-man; it’s an exaggerated hypothetical scenario that isn’t the real problem that arises.
Consider it from the perspective of copyright instead. My contributions to another project are under my copyright. It’s standard now to force contributors to assign their legal rights away (via CLAs), but the copyright still remains mine. Without CLAs, every project would be forced to treat their contributors as full participants. CLAs distort that.
Regardless, a contribution of code and assignation of legal rights is a gift, and warrants social consideration, if not legal consideration. It can be mostly, but not solely, your project.
Yes, I’m aware that that was an extreme example, I wrote so. I’m just saying that it’s very clear that there is some boundary where it is okay for me to have my rules for my project, and regardless of the quality, size, value of your contribution, I do not have to accept that contribution. Now, if we can agree to that - that some things are under my control, I just think that most people will have different opinions on what things are mine alone.
I think it’s acceptable for maintainers to decide on the stale-bot rule. I may think that in some cases it’s wrong, in some others it’s the correct way, but in no case do I think that I have any say in their decision. I may provide input, or express my wishes or preferences. I may try to persuade them, or pay them or whatever, to take that decision one or another way.
But whatever they decide, I don’t think it should be considered rude, anti-social, not-in-spirit-of-open-source or any of the things this entire comment section is mentioning - it’s just a simple project management decision, in my eyes, and it is theirs to make.
Taking the time to write up and submit a good bug report (potentially including investigation of relevant code, surrounding behaviours etc) is not treating a project the same as a product you’re paying money for. Having such bug reports closed by a bot is pretty annoying. I don’t want to waste my time submitting bug reports if the maintainers aren’t interested in actually fixing bugs, but this has happened on any number of ocassions (not always with stale bots involved, sometimes the bug just sits in the bugtracker forever) with various projects.
Sure, there are lousy users with excessive expectations and demands as well. That doesn’t justify ignoring quality bug reports. If you don’t want bug reports, don’t have a public bug tracker, or at least make it clear exactly what kind of bug reports you do and don’t want and what sort of expectations the submitter should have. As a maintainer you don’t have the right to waste people’s time either.
Let’s say that in this situation, the project doesn’t use a stale bot, but everything else remains the same. Your finely crafted high-quality issue goes unacknowledged and un-actioned indefinitely. The end result is the same: you feel rejected and disrespected.
Not using a stale bot is not going to make a maintainer action your issue faster.
Ah, but having a huge list of unanswered issues is a red flag! You would not contribute time and effort to such a project. And that’s true. So what you need to do now, before submitting an issue, is to check the list of Closed issues, and eyeball if they’re closed by a stale bot or not. This is a tiny bit of extra work but less than submitting a good bug report and then nothing happening.
No, if my bug goes perpetually un-answered, I assume many things (maybe the developer is overworked. Maybe, like me, they have ADHD. etc.) but I don’t feel actively rejected and disrespected.
If they use a stale-bot, it feels actively user-hostile. It says “this person doesn’t even have the decency to leave my report to languish”.
This is pushing the responsibility on to the wrong person. It’s easy enough not to think to check through issues to see if they’re being dealt with appropriately; especially so if there’s a detailed issue template (for example) that makes it look the project takes bug reports seriously and there are no obvious “website is only held together with sticky-tape” signs that hint a project isn’t really maintained. I don’t think to check for auto-closed bugs before opening a bug report (but thanks for the suggestion, it’s something I might try to do in future); the tendency for projects - even large, supposedly maintained projects - to simply ignore bug reports (or auto-close them) isn’t something I expected until bad experience taught me otherwise, with however much time wasted in the meantime.
The result: I tend to put less effort into bug reports now, if there’s any indication at all that there might not be any interest from maintainers. If the maintainer responds at all, I’m always happy to do more legwork, but speaking as a maintainer myself, this still isn’t optimal.
On the other hand it’s trivial for a maintainer to simply shut the issue tracker down, make it private, or at least stick a note in the issue template (or even the project README) that the issue tracker is for maintainer use only (or whatever), without risk of wasting anyone’s time at all and without generally bringing down the open-source experience. I would do this; I’m not asking anyone to do anything I wouldn’t do myself, and I think it’s a better outcome than either abandoning the issue tracker or auto-closing bugs in it. But if it has to be one of those, at least just abandoning the tracker makes the state of the project clear.
It’s later addressed in the post. Sure it’s “basic etiquette” once you know it. But you may not even be aware of it. The use of stale bots is not necessarily evil. These are just some unspoken rules we’ve come to agree on. And I think maintainers should be educated rather than shat on here.
Also lol @ the flags on this post. I searched for it before and didn’t see it already posted. And I have no idea how “no stalebots” could be on-topic but “yes stalebots” off-topic…
https://lobste.rs/about says
Obligatory mention of Trio’s Notes on structured concurrency, or: Go statement considered harmful.
You might be interested in following https://graphite.rs/ development. I’m definitely looking forward to it.
Adjustment layers been the longest WIP. At least the prerequisite GEGL is here now. I adjusted my photography workflow so that I can do everything with darktable (and Hugin) to get around the non-destructive situation with GIMP—luckily you’ve been able to retouch skin via wavelet decompose inside a darktable module.
This is addressed in the post:
This is a great example of why I’d really like a “flag: blatantly incorrect”.
On Mercurial, as many others have pointed out, the author didn’t actually read the page they wrote on. Contemporary Mercurial runs great on Python 3, thank you very much, and is well on the way to porting to Rust.
I’m no Fossil fan, but even I know that the error they’re highlighting with Fossil is because the Git repository isn’t valid. [edit: see note below; I’m wrong on the issue on that repo, but the rest of this paragraph is vald.] I hit this type of issue all the time while working on Kiln’s Harmony code. If you’re bored, try setting
fsckObjectstotruein your.gitconfig. You won’t be able to clone roughly a third of major repos on GitHub. (The ratio improves dramatically for more recent projects until it hits 100% success for stuff that was kicked off in the last couple of years, but anything five or more years old, you’re gonna hit this type of issue.)Darcs is evicted over its website being HTTP, which has nothing to do with Darcs. Pijul over the author having no clue how to write code in Windows.
The author is trolling. Poorly. And somehow this is highly ranked on the front page. Let’s do better.
Edit: correction the Fossil bit: After two seconds of poking with Fossil and Git
fast-exporton Windows, the actual issue with their Windows repository is that they’re in a command shell that’s piping UTF-16 and/or sending\r\n. This is also something any Windows dev should recognize and know how to deal with. If you’ve set the default shell encoding to UTF-8 or use a shell like yori that does something sane, you won’t hit this issue, but I’d sure hope that anyone using Windows full-time who refuses to set a UTF-8 default is habitually slamming| Out-File -encoding utf8after commands like that.For Pijul it’s even worse, it’s over (1) the author relying on contributors to test and fix on platforms other than Linux and (2) WSL not implementing POSIX correctly, but blaming Pijul’s author is easier than blaming Microsoft.
Also, she knows it, has contributed to Pijul after that post, and has never updated it.
I wouldn’t go as far as saying “the author is trolling”. To me it’s an opinion piece where, sure, the author could have put some more effort, but that’s their particular style and how they chose to write it. To be fair I did not expect it to be this controversial. It does mention some points on what a “better git” would need to do, even if it’s a bit snarky. Particularly the suggestions at the end. At the very least this thread has brought a bunch of good alternatives and points 🤷♀️.
They’re switching to opaque pointers surprisingly quick — this version enables them, and the next version will only support opaque pointers. I assumed it’d be years-long deprecation process rather than 6 weeks.
The LLVM page on Opaque Pointers (linked from LLVM relnotes) goes into more detail on why they are desirable, for anyone interested.
Sounds like just a development issue, but performance difference is not discussed at all. I wonder what the speed diff is.
Just a little nit, but
argsindef fn(*args):will actually be atupleand not alist(so you can’tpushorpopfrom it).Good catch, thank you. I’ll update it!
I believe it’s also most correct to say that
*works with any iterable and**works with any mapping — that’s a much broader scope of things than justlistanddict.It has also been brought up in Rust’s internal forums (although it’s probably offtopic there).
There’s a similar sharp edge in Rust in that it enforces UTF-8 clean strings, but cheerfully lets you create slices like
&mystring[0..64]while actually using byte indices. It works perfectly until one day the entire application crashes because someone had a multibyte character wrapped around index 64. It’s possible to code it correctly of course, but geez it can be sneaky sometimes.Indexing through
[...]is panicking when out of bounds (this is true for slices past their length, and your example)..get(...)on the other hand will returnNonefor those out of valid-bounds cases. I presume it’s a matter of interiorizing this behaviour of the square braces (or, depending on the use-case, explicitly using.as_bytes()).Ah, yes, just like how everybody using c++ vectors indexes with ‘.at()’ instead of ‘[]’…
There’s an easily enabled clippy lint that warns about uses of
[].Not really comparable footguns in terms of potential costs. A guaranteed crash (with a sane error message) is a lot better than UB.
This website breaks the back button on Firefox mobile. It’s very annoying.
Also, am I correct in thinking he is suggesting Ordering::Relaxed require unsafe? That would be quite the breaking change.
If you hold the back button, a list of previous pages should be shown, allowing you to skip the faulty one.
There is also
std::default::Defaulttrait one can use, and then have the structure populated withNo need to go for the Builder pattern if not necessary.
I’m not claiming this is more idiomatic or readable, just trying to offer another implementation with less code.
This requires all fields to be public, and when all fields are public, then addition of a new field is a semver-break (you can’t expect all users to always add
..default()). I had such whack-a-mole with comrak config.You can use
#[non_exhaustive]or keep a private field to force the use of default!Unfortunately, this also forbids construction of the struct outside of the defining crate. Same if the struct has any private field. The
..defaultsyntax has no extra privileges, and can’t do anything that couldn’t be done with a struct literal.This is discussed on Pre-RFC: Relaxed #[non_exhaustive] structs, among other places. There are two ideas that would work:
#[non_exhaustive(pub)]or a trailingpub ..field, which indicates that only public fields will be added (i.e. adding private fields will be source breaking).movekeyword in the functional update syntax{ x: 42, .. move foo }that sidesteps the issue by desugaring differently (first takingfoo, and then assigning the given fields).The second is more powerful since it allows private fields. Changing the functional update syntax to always desugar that way would could break existing code, hence the
movekeyword. Either of these combined with default_free_fn or making..shorthand for..default(), would be pretty nice.In the FIDL Rust bindings, we use this workaround for now:
This is one of those things where I’d personally be in favor of
Defaultgetting special treatment to enable some pattern of “construction with certain things set to custom values, but otherwise default” that doesn’t require the crate defining the type to explicitly provide such a constructor.I expected to see The Game of Life there as well. Now I am on a mission to disturb that space.
In the comments the author delivered! https://www.bryanbraun.com/checkboxland/docs/demos/game-of-life/
He ripped that first-mover advantage right from my hands.
Unfortunately, you can’t modify the simulation by checking boxes…
Facebook does, or at least used to, apparently allow for quite “extreme” password and email changes while still allowing you to enter (two years ago, Why can I log in to my Facebook account with a misspelled email/password?).
Weird - I get “Application error: a client-side exception has occurred (developer guidance).” when attempting to access this page.
My entire phone is rebooting when it’s halfway through the page load (rooted LineageOS 16.0 tulip, Firefox Nightly 92.0a1)!
Hmm, that’s strange! Perhaps you hit it during a deploy. If it’s still not loading, do you mind telling me which browser/OS you’re on?
Still getting the error on Safari/iOS 14.6 :(
I loaded it up in Firefox Focus and hey- presto! It worked!
You could find similar content in other places, but the interactive graph ⇄ matrix view at the end is interesting.
Apart from that, the link to the Spanish version is 404.
I would also propose to have the link text be in Spanish, since in principle, if you can’t read English you would not figure out that a Spanish version is available. I realize that pretty much everyone interested in the subject is going to know at least enough English to get that, it’s just a general principle which becomes more important when the languages have different alphabets/ideograms.
So, instead of “Don’t know English? Read the Spanish version instead.” I would have “Don’t know English? Lea la versión en Español.”: the first part tells English speakers why there is a segment in another language, the Spanish version speaks to those that don’t speak English.
Looking around your blog, there are other 404 links, like the Spanish version of “Sentences”, and the English version of “Writing our own Cheat Engine: Multilevel pointers”: the previous part, “Code injection”, is fine.
I would suggest setting up some 404 detection mechanism, either as part of your build pipeline if you use one, or a web crawler like wget. There were command line tools specialized for this, but it has been many years since I looked into that and I forgot their names.
Thanks for your feedback! The Multilevel Pointers was a draft not meant to be published yet but I pushed it in a rush trying to fix a different thing and could only partially delete the page. The blog used to be hand-written HTML, but I moved to Zola recently-ish because that was a pain, so I’m not surprised I missed a few links.
In addition to being a good blogpost, I have an ulterior motive here. @lonami’s asked a while back if submitting his own stuff was okay, and we said it was fine, but he hasn’t taken the leap yet. So I’m taking it for him :)
<3 – This post in particular was made back when my blogging skills were pretty “young”, and I posted it because I found it really fascinating when we got the lecture at university. Too bad we glossed over it because we ran out of time. There’s quite a few fun things I learned there, calculus was also really cool (for someone who didn’t dig up too much into math on their own before).
Probably my five largest pain points:
<>is wrong and broken, use[]).Eq/PartialEq,Ord/PartialOrddesign.->in function declarations with:.!syntax for macros (creates the wrong incentives).Runner ups:
Path::join. (Or rather replacePath/PathBufwith an abstraction where you don’t have to decide how to implement the method, because it simply won’t compile.)env::home_dir.I seem to remember you and I have debated this before, but I don’t think it makes any sense to call the semicolon rules useless. Semicolons convert expressions into statements, and quite apart from the fact that there needs to be some syntax to do that, because Rust is an expression-based language, the visual distinction that you get from a line ending in a semicolon or not allows you to tell at a glance whether something is an expression or a statement.
The problem with this kind of argument is that languages exist that work without mandatory
;and have none of those made-up issues.With semicolons this works fine:
But this wouldn’t:
Because
- 3is a perfectly valid expression on its own. This is just one of the simplest examples I can imagine where “no semicolons” falls apart.JavaScript has similar issues when semicolons aren’t used and can lead to unexpected behaviour, so the problem isn’t new. Python side-steps this issue by requiring either being within
(or adding a\at EOL.The problem with this kind of argument is that languages exist that work without mandatory ; and have none of those made-up issues.
You’re an asshole. I’ve never seen you argue languages with people without acting like an asshole.
What do you think you’re accomplishing here? Toddlerized argument via repetition pollutes conversations, demonstrates bad faith, and literally makes this site less valuable to others. I’d suggest that you follow the moderators’ advice: step away from the keyboard for a while until you can engage in mutually respectful discussions.
The issues are not made-up. Please accept that people may disagree with your opinions for other reasons than losing grip on reality.
Other languages have just chosen different trade offs in complexity of parsing, flexibility of the syntax, and risk of semantic changes caused by line wrapping.
If 4 out of 5 of your top 5 complaints are just syntax, that’s pretty damn good IMHO.
That’s what they say about BF too
I don’t have 5 complaints about Brainfuck. I have one: Lack of semantic richness.
It’s syntax is actually pretty good, considering what its semantics are. Other languages with the same semantics and different syntax exist, and they also suck.
I’ve heard this been said generally, but I never found out what the issue is. Isn’t this overloading array/map indexing?
In Verona, we’re doing the same thing as Pony:
[]is for generics,()is call syntax, array access uses call syntax on array objects. It’s a slightly odd decision in C-family languages to have separate syntax for them because C doesn’t have anything that is both indexable and callable (you can’t use array indexing on function pointers), but it’s a necessary hack if you want to write a single-pass compiler that runs on a system with 128 KiB of RAM. A lot of earlier languages used the same syntax because an array is, at the abstract level, just a map from integers to some other value. C doesn’t think of the abstraction like this and thinks of an array as syntactic sugar for pointer arithmetic. C++ keeps this distinction for standard library collection types, but I don’t think I’ve ever seen a C++ class that overloaded bothoperator()andoperator[].The big issue with
<>for generics (or anything else) is that<and>are both allowed in your program as stand-alone identifiers. This means that you can’t spot a missing angle bracket until you’ve done type checking, whereas you can spot a missing other kind of bracket / brace after tokenisation, before you even parse.it’s not overloading array indexing, because
[]for generics is in types, and[]for indexing is in expressions. As far as I can tell, rust grammar is sufficiently well designed that these are never ambiguous.Counterexample:
foo[X](). Is this calling a generic function foo with X as a type argument, or is this calling the Xth element of the foo array?surely you mean
foo::[X]()? :-)edit: that was snarky. It’s not worse than
<>, we’d just have the turbo hammershark or something like that instead of turbofish, but you do have a point. D usesfoo!(bar)(baaz)to separate template and regular arguments, for example.I might be wrong, but I think the main motivation behind using [ rather than < is exactly to get rid of the need to disambiguate expressions vs types via ::
If we are fine with replacing turbo-fish with turbo-snail, than yes, just switching the sigils works.
Both!
Ok, foo isn’t an array, but indexing works for all sorts of types in rust not just arrays. It’s calling the Xth element of the collection foo, where foo happens to be a generic-function collection type.
Yeah, using the same grammar for type references and expressions and disambiguating on semantic level might work. But that’s a way bigger change than just using [].
I wonder if optionality of type arguments would prevent this? Like,
foo[()][()]where the first indexing with type()seems like it can be ambiguous. As it, isfoo[()]a type argument, or a value argument with an inferred type argument?My gut feeling is that this might not be a huge problem. It seems like “syntax unambiguously classifies the role of expression” property is already lost in Rust in minor way (the prime example would be constant ambiguity in patterns). So perhaps treating the language as a homogeneous tree of things, and classifying then according to semantics later would actually be a clearer model?
The issue is that
<and>are already used for less than and greater than signs, so Foo(baz) can either be(Foo less than bar) greater than bazorFoo instantiated with bar applied to baz.Overloading indexing is fine, because it really is a kind of indexing. Indexing is a function (Container, Index) -> Value, and this is a function (GenericType, ConcreteType) -> ConcreteType. I.e. Container = Type and Index, Value = ConcreteType. As a result it doesn’t lead to the same kind of ambiguities.
Wouldn’t that make AST construction dependent on types, and thus a chicken-egg problem similar to what C has with typedefs?
Forbidding uses of types in expression contexts world be limiting, e.g. you couldn’t “simply” use static methods or associated constants, because they’re expressions, but start with a type name.
It would [1] if you need to represent
Type[Type]andExpr[Expr]as different types of ast nodes. I don’t believe that you actually need to though.[1] You could probably hack around this by checking what symbols are in scope too, but that’s ugly and would probably lead to poor handling of special cases and poor error messages.
The argument I’ve heard is that it makes the grammar more complicated, and leads to some ambiguity issues, which results in things like Rust’s turbofish syntax (
::<>iirc) or C++’s.templatesyntax.A different approach, Ada uses neither <>, nor [], and instead requires associating a new name to a function-call like explicit instantiation of a type or generic function. It seems like it leads to a proliferation of types, but is an approach I haven’t heard much about.
No. A side benefit of using
[]for types is that it makes it unlikely that[]will be abused for array/map syntax.Why do you frame everything in such an antagonistic hyperbole?
You may not like
[]for array indexing, but calling it “abuse” just brings down the discussion to shit-slinging level.Do you have an actual argument? (Because tone policing isn’t one.)
No, that’s my job. Take a break from this thread and come back way kinder in the future. Feeling like you’re right doesn’t make it OK to heap scorn on people.
What makes using
[]for array/map syntax an “abuse”? What distinguishes it from literally any other syntax choice? I could claim that using()to surround function arguments is an abuse of those symbols, but I have absolutely nothing to back that up.What are the right incentives?
!gives macro authors a card blanche to do arbitrary stuff because “the user sees it’s a macro, right?”.Instead, macros should be so well-behaved that users shouldn’t even need to know whether something is a macro or not.
On the flip side, though, if macros aren’t distinguished with a
!, then if the author of a macro does do something that isn’t “well-behaved”, the user has even less warning that it’s going to do that.See comment above.
Which comment? I’ve read all of your replies in this thread and I haven’t seen anything that refutes the assertion that removing
!would just make the developer experience worse if a macro does choose to do crazy things.Imagine that Rust users would keep filing bugs about stupid macros until the issue is resolved, just like they successfully did with unnecessary
unsafeblocks.So your solution to this problem is to make Rust developers waste a bunch of extra time filing issues? Instead of the current state of play, which is that every user of these hypothetical macros has at least a measure of pre-warning that the thing they’re calling is a macro and therefore might perform some crazy AST transformation on its input? I haven’t run a survey, but I would hazard a guess that this “macros do arbitrary stuff” problem is not actually a real problem that Rust developers have, partly because the intention of macros is to allow you to do arbitrary stuff.
Rust macro syntax is informed by experience from C where macros have a function-like syntax, and still do surprising arbitrary stuff.
In C this syntax hasn’t stopped people from doing weird stuff with macros, but is stressing users who can’t be sure that everything that looks like a function call is just a function call.
It’s also worth noting that in C it’s considered a good practice to use all-caps for macro names, because even though macros could look just like functions, users don’t want that.
Yes, except macros do things that functions literally cannot, such as ye olde
try!().Worked out great, didn’t it?
You’re advocating for
try()syntax, not removal of macros.Of course it isn’t, but I think it is reasonable for people who can’t use the software anymore to discuss what to do, and fork the software so that they can continue to use it, and even advertise to users of your software to switch to the fork in case they want to.
I think this discussion was slightly flawed because it only had author and consumer as the two roles and that relationship was static. When you release something as open source, one of the parts of the social contract is that there’s an expectation that some of the people who find it valuable will contribute. They may contribute money, code, documentation, bug reports, logos, or in other ways. A good bug report with root-cause analysis is a valuable contribution.
Successful open source projects tend to be the ones that have a good pipeline for turning users into contributors. The other side of this social contract is that an open source project is that a project is willing for people to make this transition, from consumer to casual contributor to active contributor, and will welcome them.
Absolutely, but that’s very different from treating the author in a, well, unethical way. The issue is some people both take things way too personally (authors too!) and believe they have certain rights when they actually don’t. As described, the sooner people realize their rights, the better (and discussions should remain civil).
I can relate to this to some degree. But this is a very good lesson to learn: you don’t owe anything to any of those people. You shouldn’t really feel guilty. If they don’t put the effort to create a proper bug report, why should you put the effort to fix it? More mitigations include: issue templates, labels “can’t reproduce”, “question” or “help wanted”, a more strict policy clearly laid down in the README, or even just… disable the issues section. Just make it clear that it is your project and won’t generally work on other people issues, but may accept pull requests.
I still think it’s worth it to publish the code, even if it only “works for you”. Others, who care, may find it valuable. I don’t know what project’s author talks about, how popular they are, or what community uses them (e.g. the entry barrier for Python is a lot lower than it is for other languages, so expect more poorly written complaints here), but I haven’t encountered this situation to the same degree. The compliments are really nice, even if rare (they wouldn’t feel special otherwise).
I still just do though. This is a personal issue, but I can’t help feeling that way.
I’ll probably just start disabling issues on my GH projects.
Aww, that’s cute they use my library. I also attempted a similar tool (backups, but with generic exporters, including HTML so you would get the similar “static website” feel) with a friend. Alas, Telegram changes stuff pretty often, and both the lack of time and interest (on my part) led to the tool being archived. Regarding OP, the output seems really clean from the screenshots. It’s nice to see people build cool things upon my work.