I grew up on some where you got flamed very quickly if you didn’t clean that up (e.g Espernet).

The largest of the airlines in America make more profit from this than the airline aspect itself.

There is far more that could be said on this but, ironically, I am on a flight and about to land.

A well optimized domestic USA airline makes money from credit cards, points, trip insurance, upsells, and segments the consumer into a dozen bins based on what they’re willing to spend for a couple more inches of leg room.

Not as lucrative for me the holder as you’d get it the US, but I can’t really imagine being without one.

US issuers are much less regulated. In the US there are cheap cards that offer no perks and take a small (0.2-1%) cut from the merchant, and the perks cards that have lots of perks and take a bigger (3.5%) cut from the merchant. The CC companies, naturally, want more people to use perks cards so they get more of a cut, so to encourage consumers to use these cards they give some of it back to the users in the form of these rewards.

This model recently came under attack when a whole bunch of merchants brought an anti-trust lawsuit against Visa and MC for their requirement that if you wanted to accept the cheap cards you had to accept the expensive cards as well, merchants want to be able to accept the cheap cards and reject the higher tier cards. The negotiations about that settlement continue, so we'll have to see how it all shakes out, but it could result in a major limiting of American reward cards. Or maybe not, always in motion the future is.

The EU parliament passed a law capping interchange fees at 0.3% (for local personal cards, business has some other limit that I don't remember) so there is just no money to offer rewards to customers of European banks. Much better for merchants, lower prices overall mean probably better for poorer folks, worse deal for wealthy people with good credit who pay attention and pay their bills in full every month. Speaking as an American one of those people who benefit from rewards cards, I think that it is better for society to go with the European choices than the American.

As well as ITA and American Express, at least everywhere in Milan airport.

You should just use a browser extension to do it since those don’t rely on an auth state anyway.

In fact it looks like a generic comment I'd write and come back to later.

I'm a big proponent of "everything public should have a doc comment," even if it's a short sentence. Doesn't hurt to have it. I never understood people who are allergic to comments.

The fact LLMs add comments is one of the few non-sloppy things they do, IMO

That wouldn’t solve anything.

I remember being so skeptical and annoyed when first using it but over the years I became sold on it. It’s the only system I’ve used where I could come back years down the road and figuring out the layout was still straightforward enough debugging wise.

The master branch approach isn’t always ideal and people prefer having actual releases to base their work on. Not having a set release cadence and it more or less being on the whims of the one maintainer doesn’t exactly inspire the same level of trust you get from Dioxus/etc.

You'll have to explain why the master branch approach isn't ideal. The only argument I've seen hold up is that the community can pin their own crates around a specific release, so if you rely on a lot of third party crates, you benefit from more frequent releases. Given iced is still pre-1.0, I do not encourage people to rely on a lot of third party crates. Most of them also have permissive MIT licenses so you can always bring any one-off bit of code into your own crate and maintain attribution. I did that with the split widget from iced_aw, which was available in 0.12 and dropped by those maintainers when 0.13 came around. I've since made several tweaks to it to fit my specific use cases, so all in all I'm just better off vendoring it myself.

In fact, you also have no guarantee that third-party crates will (1) continue to update for future releases and (2) evolve their own APIs in the manner that you prefer. So if you're worried about being up-to-date and/or stability, again bringing the code into your crates is again the better choice—at the obvious cost of having to maintain it yourself, but such is the nature of software.

I do not know what you mean by "inspire the same level of trust". Or I think I do, but I do not think it's helpful language or an accurate framing. Are you a part of the iced community? I can't speak for everyone, but ISTM that most everyone trusts hecrj implicitly—and we all understand iced is a labor of love, not commercial and the fact that it is subject to his whims actually helps guide a specific vision forward, however long that may take. The ride has been great so far. The Pop!_OS team seems to agree.

Finally, about Dioxus specifically, I'll leave this informative video here https://www.youtube.com/watch?v=dKvFFf04clU

The choice of framework should not be dependent on who else is building on that framework. Ideally the factors that matter: 1) Why are you building a GUI app on rust? 2) Target platform/OS support? 3) Are you ok with custom styling methods? Would you prefer to use CSS? 4) Need for multi threading? 5) Publishing / bundling / signing app

I think the reason Dioxus cadence release is slow is that they realised so many things are missing with the rust gui ecosystem that they decided they needed to fix these while building the main product. Guess what, this basically slows down your main product cadence. Does rust need a sub second hot reloader? Yes. Does rust need a native html/CSS renderer? Also probably yes. Did the Dioxus team have to take it on given their size and all the things pending in building rust with html + css? Armchair observer me thinks not.

*Note that I am currently building an app with Dioxus, so I'm putting out my honest opinion, and not saying that you shouldn't use it.*

I think this is me. My view is basically like this - if you use a tech you know works, you're only wrangling with your bugs. If you use a tech that is still being worked on, you are wrangling your bugs and the bugs of the tech you're using.

To be fair, I've tried this master branch thing with both Iced and PopOS's Iced fork. One year ago, PopOs's Iced fork was so slow I realised it basically wasn't going to be production ready for non Pop distros anytime soon.

IMO, both suffer from having very slow release cadence but at least dioxus has CSS

Of course, if I am being honest, the real reason is that there is so much CSS code out there, I can really find anything I need. And so can the LLMs.