Usually when people say to prefer composition over inheritance, that does not apply to the inheritance found in GUI, but as an alternative way to share behaviors as a property, « has a » instead of « is a », like has a role instead of being a user, admin..

That do not work well with GUI, where hundreds of of components are reusing common containers, widget behavior, it would be very verbose and painful to always declare common behaviors, data.

I think, React is cheating because it’s based on the web which already provide DOM node components and JavaScript, a GC language where most rust issues do not apply, there is already an underlying composition framework, the problem is that it is not easy to reproduce in rust.

But it’s still really fresh, they are conscious of the issues and I hope bevy maintainers came up with an elegant design

However, the only time where I’m missing code/data reuse through inheritance is with GUI. Some mostly flat hierarchies of widgets are really powerful ways to declare and compose UI components with shared behaviors.

In rust, the DX for GUI components is always lacking compared to web, C#. With maybe the exception of Slint which is really not Rust anymore.

Is there a way to have good DX for GUI components in Rust?

And there are plenty of ways to manipulate the price, such as issuing a low float to a hyper hyped stock..

Check a config, bdd value, env var to dynamically go one path or the other.

That’s all, you must either have a small feature or refactor the code to easily switch at a high level.

If you are not able to do so easily, then yes, complex feature flags implementations might help you, to coordinate feature activation between micro services.

Or if you have many features then a dashboard might be useful.

But I would argue that both are serious indicators that you should avoid feature flags, they are better for local and temporary changes, otherwise the complexity compounds and it become hard to manage and maintain.

And certainly not to send it to a fellow colleague to ask its opinion first.

LLMs are certainly becoming capable to code, find vulnerabilities, solve mathematical problems, but we need to avoid putting their works in production, or in front of other humans, without assessing it by any possible mean.

Otherwise tech leads, maintainers, experts get overwhelmed and this is how the « AI slop » fatigue begins.

To be clear I’m talking about this step:

> That preprint would have been hard for me to read, as that would have meant carefully reading Rajagopal’s paper first, but I sent it to Nathanson, who forwarded it to Rajagopal, who said he thought it looked correct.

https://www.openwall.com/lists/oss-security/2026/05/01/3

> Nope, sorry, we are NOT allowed to notify anyone about anything "ahead of time" otherwise we will have to tell everyone about everything. That's the only policy by which all the legal/governmental agencies have agreed to allow us to operate in, so we are stuck with it.

greg k-h

> there are newer GPU-accelerated font rendering systems that use the vectors. I have not yet explored these.

> he used python and xelatex

> https://github.com/ttmc/hello-world-ways

> a highly autonomous system that outperforms humans at most economically valuable work

They are many different workarounds but it’s a known pain point.

So yes there are mitigations but it still is a major cause of concern I think

You can use this to improve the efficiency of a regular solar panel and as a way to still produce electricity when there is less direct light but enough temperature difference.

Some parts get very hot, and any electricity produced without engine or fuel add to range / efficiency.

But to be fair, you have to consider your « aside », because nuclear has the tremendous advantage of working when it’s cloudy, dark and you need the energy the most in the winter.

I do not think that we can just compare the prices, or maybe we should also add the cost of storage (that is going down too) for solar.

But currently a mix is probably the pragmatic approach.

The ergonomics for this use case are better than in any language I ever used.