It’s also an old devops trick to put some GB files on the FS of critical systems (databases, ..) when there are no way to dynamically add more space/volumes and monitoring is not trusted.
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.
I did have a look at bevy ECS approach and find it very verbose and really foreign, it’s in « not rust anymore» territory. Macros are a dangerous tool in terms of long term maintainability and are hurting compilation times.
But it’s still really fresh, they are conscious of the issues and I hope bevy maintainers came up with an elegant design
I almost never use inheritance beside using some kind of interfaces/traits to declare a contract.
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?
Feature flags are often ridiculously over engineered.
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.
Well, maybe for simple web apps, but for complex applications there is a noticeable slowdown, I am not even talking about monsters such as jira, but well optimized apps such as vs code, there is a performance ceiling which is lower than for native apps.
On complex problems with lengthy proofs, the first step that I would have done is to ask 5.5 pro in a new, unrelated, session, to be very critical, to try to find flaws in the arguments.
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.
> 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.
That’s because React started as a small, focused library and evolved as even more than a framework, a whole ecosystem, complete with its own best practices
Bit hard to explain though.