YuukiRey

I suggest taking a closer look at section 5 ("V. Shifting Priorities and Social Influences"), which starts on page 24 for alternative explanations.

The preceding section does mention studies that show a cause and effect relationship between e.g., income and fertility, but the effect is surprisingly small. The authors conclude the section with:

> “Pro-natal incentives do work: more money does yield more babies… But it takes a lot of money. Truth be told, trying to boost birth rates to replacement rate purely through cash incentives is prohibitively costly.”

I don't think that's the implication.

So far I've only skimmed the paper, but here's an interesting quote:

> Among respondents of a 2018 survey conducted for the New York Times, the desire to “have more leisure time” is offered as the leading reason for not having children among adults who...

If your assumption is that economic reasons cause the decline in fertility rates, it's tempting (and natural!) to view every alternative explanation in the context of economics. In other words: all alternative explanations are symptoms of economic problems, so the root cause remains money.

But quotes like this can also be interpreted as people changing their priorities regardless of income and worries about housing. Maybe, freed of traditional role models, people would rather watch Netflix all day long in their single person household.

Fascinating topic. I personally suspect that it has more to do with attitude and life style priorities rather than economics. But I remember reading a very recent article in the Economist that argued that birth rates declined mostly in low income families, which would contradict that.

> Underpinning these policies is an assumption that poorer women are more likely to respond to incentives to have more children. Indeed, their fertility rates do seem more elastic than those of professional women. Whereas the fertility rates of older, college-educated women have remained fairly steady over the past six decades, most of the collapse in fertility in America and Britain since 1980 stems from younger and poorer women having fewer children, particularly from unplanned pregnancies.

https://www.economist.com/leaders/2025/06/19/why-magas-pro-n...

Just like with many of these topics, most sources seem to contradict each other.

Adding fuel to the fire. I'm extremely disappointed to see such an inflammatory article on fly.io. I wouldn't want this on my personal blog, let alone on my employers, but I guess they're fine with it.

I've been using Zed and Claude Sonnet 4 (and sometimes trying Opus) heavily over the past weeks. For small edits where I have lots of unit tests, the results were great. So great that they worry me with regards to job security. For exploring a new programming domain it was also somewhat useful. I work a lot with the Typescript compiler API right now, and it has almost no documentation. Since the AI can see into every GitHub repository out there, it's much better, and more efficient, at learning APIs based on code from other folks. On the other hand it means I don't do that job, and I am forced to rely 100% on how the AI presents the Typescript compiler API to me. Are there better methods I could use? Who knows.

Where it's abysmal is code architecture. Sometimes it's almost comical: it adds an if statement to handle one highly specific edge case in a program that only makes sense if it solves the general case. This didn't happen often thought.

The hardest part was to force it to reuse existing code from the same file. My use case is transforming a Typescript AST into a GraphQL AST. The code is one big switch statement with lots of recursive calls. The AI would often add 300 lines of code that duplicate some logic which already exists somewhere else.

In the end I rewrote the whole thing from scratch. At around 900 lines of code the AI was starting to really struggle. When I wanted to take over, I realized that I didn't have the in-depth knowledge to do so. And trying to understand the code the AI had written proved futile.

Ultimately that's on me, I should have been more diligent reviewing the dozens of 300 line of code changes the AI throws at me over the course of a day. But I wasn't, because reviewing is really, really hard. For many reasons. And AI makes it even harder.

Am I therefore nuts? I find this whole article extremely one sided. Surely, based on the sheer amount of both positive and negative press, the answer is somewhere in the middle.

I don’t see the similarity. Since hooks aren’t actually passed to, or injected into components, there’s no way to evaluate the same hooks in different ways.

I can’t have a hook that talks to a real API in one environment but to a fake one in another. I’d have to use Jest style mocking, which is more like monkey patching.

From the point of view of a React end user, there’s also no list of effects that I can access. I can’t see which effects or hooks a component carries around, which ones weren’t yet evaluated, and so on.

Neither yarn nor pnpm are bundlers. The buy in for bundlers is a lot higher than for package managers

We use the dataloader pattern (albeit an in-house Golang implementation) and it has solved all our N+1 problems.

E2E type safety in our case is handled by Typescript code generation. It works very well. I also happen to have to work in a NextJS codebase, which is the worst piece of technology I have ever had the displeasure of working with, and I don't really see any meaningful difference on a day to day basis between the type sharing in the NextJS codebase (where server/client is a very fuzzy boundary) and the other code base that just uses code generation and is a client only SPA.

For stitching we use Nautilus and I've never observed any issues with it. We had one outage because of some description that was updated in some dependency and that sucked but for the most part it just works. Our usage is probably relatively simple though.

You’re digging your own hole by using “brrrrrrr speeds” as a marketing term. It doesn’t help your overall argument.

I suspect people downvote you because the tone of your reply makes it seem like you are personally offended and are now firing back with equally unfounded attacks like a straight up "you are lying".

I read the article but can't find the numbers you are referencing. Maybe there's some paper linked I should be looking at? The only numbers I see are from the SimpleQA chart, which are 37.1% vs 61.8% hallucination rate. That's nice but considering the price increase, is it really that impressive? Also, an often repeated criticism is that relying on known benchmarks is "gaming the numbers" and that the real world hallucination rate could very well be higher.

Lastly, the themselves say: > We also expect it to hallucinate less.

That's a fairly neutral statement for a press release. If they were convinced that the reduced hallucination rate is the killer feature that sets this model apart from the competition, they surely would have emphasized that more?

All in all I can understand why people would react with some mocking replies to this.

Here's some better footage https://www.reddit.com/r/aviation/comments/1is1qoy/video_of_...

I don't think the "wing struck ground" is really an accurate description based on this footage.

I'm fairly certain Toronto is in Canada

It's always interesting to follow the discussions on PPRuNe https://www.pprune.org/accidents-close-calls/664303-delta-cr...

Unverified reports by another pilot are that the plane struck a wing then sort of cart wheeled

The duck typing argument is absolutely not based on minimal or missing documentation. There wouldn't be countless issues about it in the Zig repository if it were that simple. See https://github.com/ziglang/zig/issues/17198

I'm simply going to quote one of the comments from the linked GitHub issue:

> generic code is hard. Hard to implement correctly, hard to test, hard to use, hard to reason about. But, for better or worse, Zig has generics. That is something that cannot be ignored. The presence of generic capabilities means that generic code will be written; most of the std relies on generic code.

I overlooked it at first even though it’s right there on the landing page but this is ultimately still React Native with all the baggage that entails.

You're making it sound as if the difference in choice between China and western countries is negligible. Surely that's not the case? If every VC company tries to pull you into their walled garden, I can still choose from among a variety of said walled gardens.

I could be wrong of course, since I don't know how many AliPay and WeChat competitors there are.

If you can get the same features with less risk it seems like a worthwhile thing to consider.

Meaning if we can build the same antenna array but with less risk to airplanes and all at an acceptable economical cost, it feels like something we should do. Regardless of whether or not a runway overrun at other airports and in other situations poses more or less risk.

I work on a CMS using NextJS (PayloadCMS) and NextJS is hands down the worst piece of technology I have ever had to use.

This is the reason I ripped out Gatsby from every project where I could. Every six months I’d spend an entire evening fixing obscure problems that shouldn’t even exist just to get things running. And that’s not even considering actual breaking changes of which there were plenty.

We are using this at work. Generally I'm pretty happy with the configuration driven approach. You have config objects for all your collections where you define the types of the fields and everything else happens automatically.

With this comes a few gotchas. It's easy for an unassuming developer to change the name of a field (e.g., upper to lower case) and suddenly all data is gone in production since this affects the database. What you should do instead is write a migration.

I'm also not a fan of Lexical. It's very focused on being a good rich text editor but not on being a good document format for your clients. For example the way they render lists is, in my opinion, simply wrong (see https://github.com/facebook/lexical/issues/2951). Or this https://github.com/facebook/lexical/issues/6269. You also have the added complication of using the Payload flavor of Lexical, which can add its own complexities.

I haven't had time to look into its GraphQL API yet.

Documentation wise I'd compare it to working with NixOS. For some simple tasks the documentation is useful but for anything more complicated you want to look at the Payload source code. Especially when you start customizing the UI. Which generally works pretty well.

I wish they had thought about versioning the Rich Text somehow, so a client knows which version of your documents they get.

Overall I like it.

I wanted to try this with Chat GPT

I buy 102 mandarins on Monday and then on Tuesday I buy another 48. On Wednesday I buy 98 apples. I didn't like the last 3 mandarins I bought. How many mandarins do I have?

You bought 102 mandarins on Monday and 48 more on Tuesday, which gives a total of:

102 + 48 = 150 mandarins.

Since you didn't like the last 3 mandarins, you subtract them:

150 - 3 = 147 mandarins.

So, you have 147 mandarins.

This seems like a pretty wild take.

If five apps implement an authentication flow, 4 relying on the framework and one building it from scratch because the framework doesn't provide one, then surely that should be factored into any comparisons.

If a framework comes with an opinionated templating system whereas another requires me to come up with a way to have nested templating (and whatever else I might require), then again, that should be a factor in my comparison.

The general recommendation is the keep the measure of the page fairly narrow since studies show that reading text that is very wide is harder than reading a narrower column of text. So looking at the layout from a best practices point of view the author made the right call.

You wrote

> Haskell solves the problem of the representation of computations which may fail very differently: explicitly through the type system.

In my experience this is very hit and miss. Some libraries use exceptions for lots of error states that in Go would be a returned error value. I'm therefore left to decipher the docs (which are often incomplete) to understand which exceptions I can except and why and when.

Last library I remember is https://hackage.haskell.org/package/modern-uri

From their docs: > If the argument of mkURI is not a valid URI, then an exception will be thrown. The exception will contain full context and the actual parse error.

The pit of success would be if every function that can fail because of something reasonable (such as a URI parser for user supplied input) makes it a compile time message (warning, error, whatever you prefer) if I fail to consider the error case. But there's nothing that warns me if I fail to catch an exception, so in the end, in spite of all of Haskell's fancy type machinery, in this case, I'm worse off than in Golang.

If the underlying package eco system is a mess then it’ll also be a mess in Nix. To this day Nix doesn’t really have a good answer to Python or JavaScript packaging.

If the underlying package manager is good (Rust, Go) then there’s just no need to reinvent the wheel.

I think the part that might raise eyebrows is the “programming language designed for making perfect software”. Perfect is, after all, highly subjective, yet at the same time a maybe unnecessarily hyperbolic term.

I don’t mind the language though. I have no doubt that you’re at the top of your game and the problems you’ve outlined in the post do indeed sound challenging.

I highly doubt that was serious. I think you just missed the joke.

Or did I miss something? I really hope I didn’t :(

Aero also matters at low speeds since you spend more time on the course

I believe that it's currently best to wait until everyone has had a chance to cool down a bit and then see what state the original Nix project is in. There has certainly been a lot of drama and I don't think it's just a vocal minority that's making the news here, but I also believe that long running open source projects like Nix are pretty resilient. Some folks will leave, some will come back, constructive changes can be made and hopefully we'll all be able to reconcile as much of our differences as is necessary to resume work and collaboration.

On the one hand I am not a fan of commenting on documents without having read them in their entirety, but on the other hand it would probably take weeks to dive into the details of the discussion threads about the various PRs and initiatives linked here.

What really caught my eye was this discussion thread on the RFC98 PR (https://github.com/nixos/rfcs/pull/98#discussion_r683938993) where one of the signatories of this open letter kept arguing for why fascism should be included, in the sense of:

  Do not allow the Nix community to be a place for spreading ideas rooted in fascism or bigotry

It seems to me, based on my reading of that discussion so far, that at least some of the signatories of this letter have a very specific agenda and are just as unwilling to compromise as the accused on the other side. Instead of being slightly more pragmatic and accepting less controversial language they then decide to die on that hill and divide people over an unnecessary question.

To me this whole thing exemplifies the worst aspects of the "code of conduct" initiatives you see in various projects. Ostensibly a reasonable idea that could really improve the participation experience especially for people from, as they call it, marginalized communities, but with the end result being that it back fires and makes people come across as radical ideologists.

Maybe it would be less puzzling if he called it coaching, since it sounds like that’s what is it.