They explained it. It goes against the client's goals. Massive investment in customer support? It's about generating leads. I think you're seen it as a SaaS offering which the writer has mentioned multiple times, isn't the case for the client.
The problem lies in the fact that these companies are generating work for volunteers on a different time-scale and binding them to it by giving them X days before disclosing vulnerabilities. No one wants their project to have security vulnerabilities that might affect a lot of users, which creates pressure in dealing with them.
The open source model is broken in this regard, licenses need to address revenue and impose fees on these companies, which can be used as bug bounties. Game engines do this and so should projects like FFMPEG, etc. The details are complex of course, but the current status quo is abusing people's good will.
It's kind of an exploratory phase for what works sensibly with Rust's borrow checker, especially since most UI libraries/frameworks really rely on a GC.
I'm using EGUI for a all-in-one molecular viewer / CAD. It's like PyMol, Coot, GROMACS and VMD in one. If this is trivial, I would like to see what you consider to be non-trivial!
There are parts of the rust ecosystem that are only built for trivial apps (And demos, blog posts etc), but GUI is not one.
Look, your application is certainly impressive, but it's extremely basic from the perspective of a UI toolkit.
- It's not multi-window, so it doesn't have to integrate with a bunch of the OS window management affordances.
- It doesn't have any complicated typesetting or rich text editing, so you get to pretty much ignore that whole mess.
- Since it's a very visual tool that doesn't make much sense for blind folks, you haven't invested much in accessibility support.
- And so on...
This is a great use case for EGUI, and EGUI works great in this sort of UI-lite scenario. Whereas I wouldn't want to use it to implement something on the complexity of VSCode/Excel/FireFox.
And quite amazing work, so thank you for sharing. This will be fun to dive into. I'm generally liking egui but have just recently been using it, so I'm still new at it.
The most popular language by far used for writing UI is JavaScript, and the go to framework this day (React) doesn't use that though.
From the various experiments that popped up over the years, it's pretty clear that the React way works pretty well for Rust, but it's also too slow to be desirable for Rust (what's the point of using Rust for UI if you're going to have web-like performance).
And then again, making a half decent UI framework is a gigantic task, there's just not a whole lot of languages with a decent UI story at all, no matter what's the paradigm of the programming language. (And if you want a
language for cross-platform UI, I'd argue that the only one that ticks the box is JS with React in Electron and React Native, and it's not even truly a single framework).
The view part would be fine, the problem is updating the state. In a language which discourages shared mutability, most of the solutions are not terribly ergonomic.
You either end up needing to:
- handle all your state via interior mutability (i.e. Arc<RefCell<_>>)
- use a reducer (i.e. the state blob is immutable during rendering, updates are deferred via events that are delivered between frames)
- or invert the relationship between state and view (i.e. immediate-mode) which comes with it's own implementation challenges (caching immediate mode views is hard)
SEEKING WORK | Berlin, Germany | Remote or on-site | Full-stack Web Developer
Hey, I'm Ricardo, a full-stack web developer specialised in interactive experiences, with more than 10 years of experience in building creative and business applications.
reply