p.s. I’m also curious if you have any actual evidence that these two are more reliable than gtk. It’s reasonable to think they might be, but I’d like something more than “they’re written in Rust and have fewer features.”
p.p.s. How many Firefox Linux users even use the Mozilla crash reporter? I know on Fedora, if I crash Firefox, I get the Fedora crash reporter, not Mozilla’s. (edit: apparently they stopped doing that years ago; “Another good example comes from Fedora: they had been using their own crash reporting system (ABRT) to catch Firefox crashes in their Firefox builds, but given the improvements on our side they started sending Firefox crashes our way instead.”)
I based my suggestion based on the logical requirement stated (first quote) which was later ignored (second quote).
I know they call it a requirement, but it has the phrase “as little as possible.” If that were taken as broadly as it could be, it would not be written in Rust or C++, since, after all, there might be a standard library problem that takes Firefox and the crash reporter both down.
The stated requirement is “don’t use Firefox’s code.” GTK is not Firefox’s code, and the code paths exercised by Firefox are going to be different than the ones exercised by this crash reporter. Besides, a lot of people use GNOME, XFCE, or LXDE: if GTK as a whole is borked, then you wouldn’t even be able to start Firefox under these environments, much less crash it.
Also, they list other requirements, not just that one (it’s not a requirement if it uses words like “minimal,” because there’s no definite test to see if you’ve met the requirement or not; these are all desirables).
We want to minimize the use of external code: to improve crash reporter reliability (which is paramount), we want it to be as simple and auditable as possible.
Firefox vendors all dependencies in-tree, so we are hesitant to bring in large dependencies (GUI libraries are likely pretty sizable).
There are only a few third-party crates that provide a native OS look and feel (or actually use native GUI APIs): it’s desirable for the crash reporter to have a native feel to be familiar to users and take advantage of accessibility features.
They downplay it in this list, but I’m pretty sure a11y is the biggest non-negotiable requirement, so Iced is out of the picture.
Slint, on the other hand, is not a small library at all, and it only has full functionality if it pulls in Qt. There might not be a clear-cut, definite criteria for “minimize the use of external code,” but pulling in Qt definitely doesn’t count.
I have a fun one, where the compiler says I have an unused lifetime parameter, except it’s clearly used. It feels almost like a compiler error, though I’m probably overlooking something? Who can see the mistake?...
The actual problem is on line 5, where you have a type alias that doesn’t use the lifetime parameter. The warning ought to be there, but rustc expands type aliases in place, so it doesn’t check there.
An interesting point on the TOML configuration file format. You don’t have to abandon the nested structure to get the readable, repeated style. There two TOML sections are the same thing:
As much as I understand why Rustaceans don’t like classical inheritance, that’s only a minor factor in Rust not having support for it.
Before 1.0, there was a project to solve Servo’s needs for inheritance. An important point about this is how it made the question of whether inheritance is good or not moot — Servo implements the DOM, and the DOM needs inheritance, end of story.
Servo uses a bunch of procedural macros to implement OOP, and so do other projects in similar positions (GNOME, PyO3, Windows…). Anything worth adding to Rust needs to be better than that.
Solving inheritance for Servo means it needs to be as fast as C++ (the Internals thread linked above is mostly about this requirement). It’s hard, because C++ doesn’t prevent things like object slicing, and a safe implementation of subclassing for Rust would need to (while still providing control over an object’s allocation like C++ does).
About object slicing: TFA describes inheritance as having a “hidden member variable” within a child class that’s an instance of the parent class. This is mostly how it works, but it’s important in trad OOP that the child class encapsulates the parent completely. For example, if you’re implementing the DOM and an HTMLTemplateElement wants to implement its own clone and adopt steps, there should not be any way to bypass them. Also, it should not be possible to get a reference &mut Node and use mem::replace with a non-template, since that would still be a way to violate the invariants those methods seek to enforce.
JS, Python, and WinRT are all substantially different. Covering all of them means the language features look less like a complete object system and more like a framework for building an object system.
Note: it’s been a long time since I last made any meaningful contributions to Servo, and I never worked on the JS bridge code much. I’m reflecting the story as best I can. Please read the original Internals thread to get a deeper understanding of this, without creating a bad game of telephone.
It’s nice to see how this blog post not only lists features, but also lists what the limitations of the approach are, and how to turn it off if it’s not suitable for your program. No magic bullet, after all, but good enough for most use cases.
I followed the link in echelon’s HN profile to their GitHub profile. It’s the same name, like you’d expect, but I had to check.
If they were a member of the Rust project, they’d have an entry in the rust-lang/team repository, and they don’t. The fact that they’ve written some code in the Rust language doesn’t automatically make them trustworthy, or give them information about what happens in closed council meetings.
What do you think #[doc(hidden)] is for, other than declaring something “private” that the language unfortunately doesn’t let you declare as truly private right now?
I’ve mostly seen it used as a way to expose tools to macro APIs. For example, these internal parts of the quote! macro, or these internal parts of the vec! macro. Changing these things shouldn’t be considered a semver violation, because they’re not really part of the API, even though the quote! macro can’t enforce it.
The only other cases I can think of where I’ve seen #[doc(hidden)] used are even bigger kludges, and the hidden items definitely aren’t part of the platonic API, like pre-#[non_exhaustive] crates that wanted to reserve the right to add new variants to their enums.
cargo-semver-check should definitely provide a way to mark syntactically-public items as “de-facto private,” because some projects just need to do bad things and leaving them out in the cold is not helpful. But you’ve convinced me that doc(hidden) is a poor way to do it.
Rust to .NET compiler - Progress update (fractalfir.github.io)
Porting a cross-platform GUI application to Rust - Mozilla Hacks - the Web developer blog (hacks.mozilla.org)
Unused lifetime parameter -- except it isn't
I have a fun one, where the compiler says I have an unused lifetime parameter, except it’s clearly used. It feels almost like a compiler error, though I’m probably overlooking something? Who can see the mistake?...
Release-plz: releasing crates like it's 2023 - Marco Ieni (www.youtube.com)
Microsoft seeks Rust developers to rewrite core C# code (www.theregister.com)
Rust Is Beyond Object-Oriented, Part 3: Inheritance (www.thecodedmessage.com)
[Blog] Eyra does the impossible (blog.sunfishcode.online)
Could rust do with a crates.io alternative?
To me, the two major problems are:...
Write-up on rustdoc's main (HTML) user roles (gist.github.com)
Semver violations are common, better tooling is the answer (predr.ag)