ragnese

Is not accepting contributions the only/biggest issue you have with the project? I'm honestly becoming more and more okay with the "cathedral" style of open source. Depending on the project, catering to "the community" can lead a loss of focus, lack of a cohesive "vision" or scope, and just generally trying to be everything to everyone without the resources to maintain a giant beast.

With something like a browser (engine), I'm totally okay with someone saying "I'm an expert and I'm trying something with my own vision/priorities. I don't want input from random people that I have to spend time evaluating."

I hate that. It will also leave code comments explaining what it didn't do or what the code used to do and why it doesn't do that thing anymore. I don't have a huge global CLAUDE.md, but probably half of it is instructing it on how not to write irrelevant and verbose code comments.

Nah, it's just the standard enshitification playbook. It'll start out nice, open, useful, fun; then once they have enough users and the network effect kicks in, they'll lock it down and turn it into a weapon against its users. Happens every time.

So you're saying that the current management of Twitter does not favor politically-right messaging? Otherwise, your message is a non-sequitur.

The comment you replied to made no statement about the effectiveness of the project. It's like saying that George Soros is engaged in trying to elect left-wing leadership; nobody denies that.

I always cringed at that framing anyway, for two reasons. First, it was obvious to me that it was a private, centralized, closed-source, piece of software whose owner(s) could always manipulate or take away from people they didn't like. Second, it's genuinely depressing to think that the modern marketplace of ideas was supposed to take place in 180 (or whatever the hell it is now) characters or fewer. Yeah, sure- let's hash out the complexities and nuances of life and society in single-sentence messages. And we wonder why everything has become "polarized" and rage-bait-y. When all you have room to write is "This thing is bad", what the hell else are you supposed to do?

What a stupid platform. I can't believe it's still so popular.

Why wouldn't a bank sell debit data just the same as credit data? For that matter, I would expect them to be selling everything they can: credit, debit, written checks, ACH transfers, etc.

What incentive is there for them to not do that? Laws? I'm asking sincerely, not rhetorically.

The comment you replied to doesn't imply the users are immoral, but the creators. They're saying that we shouldn't build such systems. I, personally, also believe we should resist using them as much as possible, instead of rewarding them by using them. But, obviously, that may be easier or harder for any given individual situation. So be it; just avoid as much as you can tolerate if you agree that these things shouldn't exist the way they are.

Good explanation. Just one correction: John Thune is the Senate majority leader (so, the "head" of the Senate). Steve Scalise is in the House and he's the head of the Republican party in the House, whereas Mike Johnson (who is also a Republican) is the House majority leader (so the head of the whole House, not just his party).

So, it's Mike Johnson for the House and John Thune for the Senate.

Unfortunately, yes. It's a backward looking metric, like how economists can only call a recession/depression after it's been X months of bad metrics, even if everyone living in the first month of one feels the economy going poorly. We'll only know if these tools are "boring but work" at some point in the future.

The hope is always that "this time will be different". Maybe these tools are so awesome that they'll become a de facto standard and, therefore, "boring". It's JavaScript, so I'm not holding my breath, though.

That's not a charitable reading of their comment. Granted, I also don't think articulated their point very well with that example. I can't speak for the commenter, and I'm genuinely not sure about the point they were attempting to make. But, I think the point was more so that things are moving so fast in the field that it's basically impossible to become the level of expert that has a truly deep understanding of all the parts and layers.

If you're an expert as a particular programming language, for example, you may have a good mental model for what optimizations the compiler and/or runtime are able to do, and the way you write code in that language may be influenced by that deep knowledge. You may have written so much code in that language that you know all of the corner cases and foot-guns, and how to deal with them--or better yet, how to avoid them in the first place. You may even develop new/uncommon patterns or idioms that other people end up adopting.

But, if that programming language totally changes its own semantics and compiler toolchain every few months, nobody would have time to build deep intuition and expertise like that.

I think that was the point.

When I read it, I assumed it meant like network communication in your program. File and network I/O having/being a "tax" makes sense to me.

Yep. I've learned that lesson more than once. Maybe one of these days it'll stick... :p

Specifically, I'm not a "designer", but I regularly end up making/changing UIs (mobile apps, web apps/pages, etc). When it comes to design, it really matters who the target audience is.

If you're creating a UI for "mass market", you have to design to a lowest-common-denominator that balances what your average user expects, generally, from UI/UX, and the more you ask them to "invest", the worse you're going to do. On the other hand, if you're making a tool for a B2B (business-to-business) product, you have more freedom to set baseline expectations of what the end user needs to be able to do and understand. You can also expose more powerful options, etc. You can sometimes end up going in very different directions. Even error handling and logging can sometimes be handled differently, depending on the context.

Yes! That's exactly how you should do it while working with a language that doesn't have a compiler that will aggressively analyze, and rewrite and optimize your code for you. (So, most languages with "heavy runtimes" that support a bunch of dynamic stuff and JITs)

There are basically two points to programming with immutable-first data. One, eliminate certain classes of data race concurrency bugs. Two, less mutable state in a given context makes it easier to reason about.

So, if you're inside a function scope and you aren't launching any concurrent operations from inside that function, you don't have to worry about benefit #1. If you're inside a function (and you're not reaching out for global mutable state), then the context you need to keep in your working memory is likely fairly small, so a few local mutable variables doesn't significantly harm "understandability" of the implementation (in most cases). So, you really don't have to worry about #2, either. Make your functions black boxes with solid "APIs" (type signatures), and let the inside do whatever it needs to make it work the best.

Just because premature optimization is the root of all evil, it doesn't mean we need to jump right to premature pessimization...

Since it's obviously written in a casual, conversational, tone we should not expect the language to be perfectly precise. So, given that and the fact that the author felt the need to call out "vibe coding" or AI at all, and then double down by adding the almost-redundant "classic development style", I would be willing to bet they did not use any AI for anything at all related to this project.

Hmm. Fair point. It's entirely possible that it's not obvious and that the "law" is almost a "reminder" of sorts to not assume you're getting well-formed inputs.

I'm still skeptical that this is the case with Postel's Law, but I do see that it's possible to read it that way. I guess I could always go do some research to prove it one way or the other, but... nah.

And yes, "Parse, don't validate." is one of my absolute favorite maxims (good word choice, by the way; I would've struggled on choosing a word for it here).

Yes, what Postel's Law is about. That's the whole point of contrasting it with Hyrum's Law, no?

Hyrum's Law is pointing out that sometimes the new field is a breaking change in the liberal scenario as well, because if you used to just ignore the field before and now you don't, your client that was including it before will see a change in behavior now. At least by being strict, (not accepting empty arrays, extra fields, empty strings, incorrect types that can be coerced, etc), you know that expanding the domain of valid inputs won't conflict with some unexpected-but-previously-papered-over stuff that current clients are sending.

I don't think that interpretation makes that much sense. Isn't it a bit too... obvious that you shouldn't just crash and/or corrupt data on invalid input? If the law were essentially "Don't crash or corrupt data on invalid input", it would seem to me that an even better law would be: "Don't crash or corrupt data." Surely there aren't too many situations where we'd want to avoid crashing because of bad input, but we'd be totally fine crashing or corrupting data for some other (expected) reason.

So, I think not crashing because of invalid input is probably too obvious to be a "law" bearing someone's name. IMO, it must be asserting that we should try our best to do what the user/client means so that they aren't frustrated by having to be perfect.

This is also a problem, IMO, in having this optimization in PHP. Anonymous functions are instances of a Closure class, which means that the `===` operator should return false for `foo() === foo()` just like it would for `new MyClass() === new MyClass()`.

But, since when has PHP ever prioritized correctness or consistency over trivial convenience? (I know it's anti-cool these days to hate on PHP, but I work with PHP all the time and it's still a terrible language even in 2026)

I'm especially angry that if you go to reddit.com in a mobile browser, it will sometimes fully block you from certain subreddits (not just NSFW ones) and tell you that you can only access it from the app. Meanwhile, you can easily visit the exact same subreddit by typing old.reddit.com/r/whatever. The outright lying bothers me so much. I refuse to be desensitized to lying just because everyone is lying all the time; it's still really wrong, and they really should be ashamed of themselves.

When you say "meme", it sounds like it might not be true. But, a few years ago I handed my stepson a USB flash drive with some files on it, he plugged it into his laptop and the very first thing he did was launch Google Chrome and then not have any clue what to do to access the files (it was a Windows laptop).

One of the most enraging things about life since 2005-ish is that no matter how private and careful I am, it doesn't even matter because every other inconsiderate fool I know and interact with will HAPPILY let some random company have access to THEIR contacts--which includes me--in order to play Farmville for a month until they get bored of that and offer up my private information to the next bullshit ad company that asks for their contacts.

It used to frustrate me that people didn't care about their own privacy, because I genuinely didn't want evil people to hurt them. But, it's even more angering that people don't have the common decency to consider whether their friends and family would want them sharing their phone numbers, email addresses, photos of them, etc.

Yep. If someone is trying to make you do something, or stop doing something, or buy something, your first question should always be "Why?".

Why would someone try to force me off of my browser (that has ad-blocking and tracker-blocking mitigations) and on to a locked-down app that may want permission to run in the background, display notifications, access my files or camera, etc?

Maybe it really is to "improve my experience"... yeah, right.

Talk about trivializing complexity...

The idea that making things immutable somehow fixes concurrency issues always made me chuckle.

I remember reading and watching Rich Hickey talking about Clojure's persistent objects and thinking: Okay, that's great- another thread can't change the data that my thread has because I'll just be using the old copy and they'll have a new, different copy. But now my two threads are working with different versions of reality... that's STILL a logic bug in many cases.

That's not to say it doesn't help at all, but it's EXTREMELY far from "share xor mutate" solving all concurrency issues/complexity. Sometimes data needs to be synchronized between different actors. There's no avoiding that. Sometimes devs don't notice it because they use a SQL database as the centralized synchronizer, but the complexity is still there once you start seeing the effect of your DB's transaction level (e.g., repeatable_read vs read_committed, etc).

> It's a good article but I think you need to start explaining structured concurrency from the very core of it: why it exists in the first place.

I disagree. Not every single article or essay needs to start from kindergarten and walk us up through quantum theory. It's okay to set a minimum required background and write to that.

As a seasoned dev, every time I have to dive into a new language or framework, I'll often want to read about styles and best practices that the community is coalescing around. I promise there is no shortage at all of articles about Swift concurrency aimed at junior devs for whom their iOS app is the very first real programming project they've ever done.

I'm not saying that level of article/essay shouldn't exist. I'm just saying there's more than enough. I almost NEVER find articles that are targeting the "I'm a newbie to this language/framework, but not to programming" audience.

I haven't written any Go in many years (way before generics), but I'm shocked that something so implicit and magical is now valid Go syntax.

I didn't look up this syntax or its rules, so I'm just reading the code totally naively. Am I to understand that the `user` variable in the final return statement is not really being treated as a value, but as a reference? Because the second part of the return (json.NewDecoder(resp.Body).Decode(&user)) sure looks like it's going to change the value of `user`. My brain wants to think it's "too late" to set `user` to anything by then, because the value was already read out (because I'm assuming the tuple is being constructed by evaluating its arguments left-to-right, like I thought Go's spec enforced for function arg evaluation). I would think that the returned value would be: `(nil, return-value-of-Decode-call)`.

I'm obviously wrong, of course, but whereas I always found Go code to at least be fairly simple--albeit tedious--to read, I find this to be very unintuitive and fairly "magical" for Go's typical design sensibilities.

No real point, here. Just felt so surprised that I couldn't resist saying so...

Unfortunately, the context starts getting lost as we get deeper into discussion threads like this, but originally, I brought up GTK stewardship because I felt that the top few comments in this thread started to conflate the various projects developed by the GNOME organization. The original HN post was about Mutter, and the first few comments in this reply chain were about software being customizable, etc. Those could've been about whether it's okay or not for Mutter to lose flexibility. But, the one I replied to started complaining about software "imposing limitations on the rest of the ecosystem".

That's when and why I decided to point out that there are different kinds of software projects, and they have different goals and priorities. It's like the old "library vs. application" code: libraries are generic and reusable, and should be written as such, whereas applications are specific and focused.

I brought up GTK simply as an example of a "library project", for which critique of its reusability is warranted, as a counter-example to Mutter, which is an application. Complaining about Mutter's effect on "the ecosystem" is silly. It wouldn't make any less sense to complain about XTerm's effect on the ecosystem by it not supporting Wayland. Anybody in their right mind would just say "So, use one of the other 10,000 terminal emulators in Wayland instead of XTerm"--and rightly so. But, because Mutter is a GNOME project, and GTK is also a GNOME project, I think that people lose focus on what they're talking about.

I did engage with you about GTK because it's interesting, but my point in bringing up GTK was specifically to say "Yeah, those complaints might make sense if we were talking about GTK, but since we're talking about Mutter, they do not." to the comment I replied to.

It's been a long time since I've done C/C++, but I'm not sure what you're saying with regard to provenance. I was pretty sure that you were able to cast an arbitrary integer value into a pointer, and it really didn't have to "come from" anywhere. So, all I'm saying is that, under-the-hood, a C pointer really is just an integer. Saying that a pointer means something beyond the bits that make up the value is no more relevant than saying a bool means something other than its integer value, which is also true.

> Are there any good resources on optimizing python performance while keeping idiomatic?

At the risk of sounding snarky and/or unhelpful, in my experience, the answer is that you don't try to optimize Python code beyond fixing your algorithm to have better big-O properties, followed by calling out to external code that isn't written in Python (e.g., NumPy, etc).

But, I'm a hater. I spent several years working with Python and hated almost every minute of it for various reasons. Very few languages repulse me the way Python does: I hate the syntax, the semantics, the difficulty of distribution, and the performance (memory and CPU, and is GIL disabled by default yet?!)...

Ints probably get a big boost in languages where the only built-in for-loop syntax involves incrementing an index variable, like C. And, speaking of C, specifically, even the non-int types are actually ints or isomorphic to ints: enums, bools, char, pointers, arrays (which are just pointers if you squint), etc...

But, otherwise, I'd agree that strings probably win, globally.

I read them, but I'm not sure what point you're trying to make, or why it's directed at my comment. I mean that genuinely.

This Xfce dev says that GTK4 is less capable than GTK3, and they feel that GTK5 will continue in that direction. They also acknowledge certain things in the first comment:

> [0] Full disclosure: I'm an Xfce developer, and have been disappointed with the direction GTK has been taking for some time. I don't begrudge them their prerogative to do what they need/want to achieve their own goals with the toolkit they've built and maintain. But it really is making life more difficult for me.

>

> [1] Part of the argument is that Wayland doesn't natively support things like cross-process embedding, so a cross-platform toolkit shouldn't have these types of widgets (the classic problem of only being able to support the lowest common denominator). But a) you can absolutely build something like that for Wayland (something I've been working on, though it requires tens of thousands of lines of code to do), and b) with other changes, it's incredibly difficult and possibly impossible to even implement the XEMBED protocol on GTK4, for people who do only care about X11.

If the GNOME guys took out stuff from GTK4 or 5 for bad reasons, then I don't like that, either. Which is basically exactly what I said. However, it sounds like some of these changes would be hard to do and maintain well, such as cross-process embedding. Perhaps the GNOME devs made a decision to focus their surely limited resources toward things they think will be long-lasting. And, perhaps, by their estimation, trying to support Wayland and X11 by adding (and maintaining) tens of thousands of lines of code would be a big burden--especially if they believe that X11 is not going to be super-relevant in the near future. I don't agree with that estimation, and I assume that it'll be a very long time before X11 isn't necessary anymore, but so be it.

All that said, it still has nothing to do with Mutter, which is why I replied to the comment that I did. Because GTK, and Mutter, and GNOME Shell, and GNOME apps, and non-GNOME GTK apps, are all different things, and this post was about Mutter.