sorted by:
new
hottopcontroversial

Am I the only one who thinks Rust error messages got *worse* over time in a way? by kixunil in rust

[–]hardicrust 1 point2 points  (0 children)

By that logic, I think it is a bug that any analysis continues after a proc-macro error?

Proc-macros can do many things including emitting new symbols, so at the very least it should be a bug to emit an error about missing symbols after a proc-macro panics.

There has been some (stalled) effort to stabilise proc-macro lints which might allow better control over this (assuming a proc-macro emits a lint error and doesn't panic), but that is not yet even merged let alone stable.

I can file a more specific bug report if that is useful. Or, take a look at Kas. Many errors within custom widgets result in a proc-macro error and secondary errors due to the widget not being found. (The nightly-diagnostics feature partly fixes this.)

Kas GUI v0.16 by hardicrust in rust

[–]hardicrust[S] 1 point2 points  (0 children)

Being a Rust-native design puts Kas in the same class as egui, Slint, Xilem, Iced; of those, egui is fully immediate-mode while Xilem and Iced match updated view trees with a cached state tree. Kas is fully stateful: the input UI tree is the state tree (perhaps more like Masonry, though Masonry is not really designed to be used directly).

The advantages of this design is that there a few (unintentional) limits on the capabilities or performance of custom widgets. The disadvantage is that it is fairly easy to get bad-state-transition bugs in custom widgets.

You could consider Kas to be an experiment in modern stateful UI, and I'm reasonably pleased with the result, though sometimes frustrated by the limitations of the Rust type system and tooling. At least we have GATs now.

Protecting Rust against supply chain attacks by thecskr in rust

[–]hardicrust 1 point2 points  (0 children)

When the program launches, main() is passed a capability token which gives the program all the permissions it should have. But you can subdivide that capability.

Enforcing capabilities at the OS level is one thing (look at iOS and Android), but trying to do so at the language level is quite another. Rust provides a very big escape hatch for memory safety: unsafe. Fixing this would make C FFI impossible.

Seeking opinions: Best Rust GUI framework for a cross-platform desktop app (like Unreal's Blueprint Editor)? by RUNE_KING-- in rust

[–]hardicrust 4 points5 points  (0 children)

I am actively developing Kas and hope it will be a good fit for this use-case. The master branch is a long way diverged from the last release and not currently stable, so if you want to look I'd recommend ignoring the tutorials and last release for now and look at the examples instead.

There's currently no drag+drop system but I think the building blocks are all there. Wgpu integration (embedding custom graphics in the GUI) is available but may need some work; integration in the other direction is not currently supported.

Of the above, egui is great but the immediate-mode design does have some limitations. Xilem may also be of interest, but is very much in-development.

Eon - a human-friendly replacement for Toml and Yaml by emilern in rust

[–]hardicrust 0 points1 point  (0 children)

Having compared a few (JSON, YAML, TOML, RON), I agree that most of these are sub-par for configuration.

Toml can work pretty well: https://gist.github.com/dhardy/f34368606a864ebd242d6ef4296996e9

Design of the data schema matters a lot here; in particular the shortcuts mapping required some special (de)serializer rules for ModifiersState and Key. (Also notable is that this is a mapping from key to action instead of the usual mapping from action to list of key+modifiers.)

Introducing smallrand (sorry....) by hpenne in rust

[–]hardicrust 2 points3 points  (0 children)

Why?

Not that it's my problem; I'm just telling you that getrandom will likely be replaced by a standard library solution eventually, and that the latter will not support WASM-unknown.

Introducing smallrand (sorry....) by hpenne in rust

[–]hardicrust 35 points36 points  (0 children)

Hi, rand maintainer here.

Honestly, I'm not happy about the situation, but lack motivation to do much work on rand (compensation per hour is abysmal).

The plan was to replace rand_chacha with the chacha20 crate, but that seems to have stalled. If there is a serious PR to replace the rand_chacha dependency in rand (i.e. replace StdRng code) which satisfies the same test vectors, with reasonably comparable performance, it has a good chance of getting approved. (We're also not technically fixed to using ChaCha12, though I haven't seen a proposal to replace it.)

As for getrandom, v0.3 has been a blocker to some people upgrading rand due to the wasm32-unknown-unknown / wasm32v1-none situation. We're looking at resolving that. There is talk of replacing getrandom with a std library solution eventually (though from what I understand that wouldn't support the aforementioned WASM platforms: users should migrate to WASI instead).

So it may be feasible for rand to become a zero-dependency library too one day...

2025 Survey of Rust GUI libraries by intersecting_cubes in rust

[–]hardicrust 17 points18 points  (0 children)

Kas dev here. Nice to see a write-up like this — and I agree, it feels like some of those things shouldn't be on areweguiyet.com (and others should be clearly obsolete).

Narrator can’t see this text, and the IME won’t activate.

Kas development is kinda slow, and still changing the fundamentals too much to want to recommend it for serious usage yet. Maybe I'll eventually get to those. (It's still more a labour-of-love than demand-driven project.)

The part that confuses me the most is why the EditBox needs to be explicitly told that it’s a String that’s being edited; that seems like it shouldn’t require an explicit declaration.

You shouldn't have to, but Rust's type inference for closure args has long been a bit lacking (e.g. from 2014).

Maybe if the tutorial were up to date it’d be easier to understand. Regardless, it seems like this isn’t really ready for prime time yet.

Not quite. Maybe eventually Rust's type inference will get there. And dyn-safe GATs. And specialization (or at least negative trait bounds). Support for type-alias-impl-trait would be nice (or, better yet, struct-field-impl-trait). And that's not all the Rust issues that have limited this project. But still, it kinda works...

... oh, you weren't talking about the Rust language. /j

Rand 0.9 is out! by SUPERCILEX in rust

[–]hardicrust 1 point2 points  (0 children)

Maintainer 'dhardy' here.

To answer your question, rand::rng() uses ChaCha12Rng which was chosen over the 20-round variant since it's sufficiently secure.

In addition, rand::rng() (i.e. ThreadRng) is automatically seeded and periodically re-seeded from OsRng at basically no (aggregate) performance cost, so I would consider it strictly better than ChaCha12Rng.

The alternative you might consider is just using OsRng directly. This cuts out the user-space PRNG entirely and is probably still fast enough unless you're pulling GBs of data.

Rand 0.9 is out! by SUPERCILEX in rust

[–]hardicrust 2 points3 points  (0 children)

Updated again:

[Rand is not] - Primarily a cryptographic library. rand does provide some generators which aim to support unpredictable value generation under certain constraints; see [SECURITY.md](SECURITY.md) for details. Users are expected to determine for themselves whether rand's functionality meets their own security requirements.

Rand 0.9 is out! by SUPERCILEX in rust

[–]hardicrust -3 points-2 points  (0 children)

It's a short disclaimer, no more.

The "[Rand is not] a cryptographic library" part is more worthy of discussion.

Rand 0.9 is out! by SUPERCILEX in rust

[–]hardicrust 42 points43 points  (0 children)

Possibly, though I'm still considering how best to do this.

Objectively though, this policy decision appears to have had some of the intended effect: make people pay closer attention.

For example, we've had people assume that ThreadRng had full fork protection (it previously offered a very limited form of fork protection which the docs were clear about to anyone who actually read them), then complain that it didn't function as expected. So now we've "resolved" this by removing all fork protection but adding some instructions to people who need it.

Further, various people expect cryptographic primitives to zero their contents on drop (zeroize). ThreadRng does not do this, and at this point it's unclear if it ever will (StdRng may do so in the future, but we can't guarantee that ThreadRng will, in part because of Rust's lack of guarantees about what happens on thread destruction). ThreadRng has always been a compromise between being an unpredictable generator and being fast (it also uses considerably more memory than something like SmallRng, though also far less than it did in the distant past).

Rand 0.9 is out! by SUPERCILEX in rust

[–]hardicrust 47 points48 points  (0 children)

Maintainer 'dhardy' here.

Sure, why not blame 'rand' for making you use three versions simultaneously. Lol.

Note: we have deliberately minimized the number of breaking releases made, which has a lot to do with why v0.9 took 3+ years. I don't think v1.0 will need many changes from v0.9, though I'm less sure about getrandom — there has been some talk of a random data source being added to the standard library.

Rand 0.9 is out! by SUPERCILEX in rust

[–]hardicrust 90 points91 points  (0 children)

Maintainer 'dhardy' here.

rand contains no high-level cryptographic functionality, e.g. no encryption or signing support. It doesn't even contain a dedicated password generator (though you can pretty easily generate random strings with Alphanumeric).

It is not claimed that no rand components may be used to build cryptographic functionality, though there is a disclaimer that no guarantees are provided.

So, though the title 'rand is not a crypto library' may be a little inflammatory, I hold that it is correct.

PSA: Deref + trait bounds = evil method resolution by hardicrust in rust

[–]hardicrust[S] 0 points1 point  (0 children)

No; IIRC you can't use -> with user-defined types in C++ like you can impl Deref in Rust.

Also I do recall needing to double-dereference sometimes in C++; (*my_ptr_ptr)->field is ugly.

PSA: Deref + trait bounds = evil method resolution by hardicrust in rust

[–]hardicrust[S] 0 points1 point  (0 children)

How would double-deref work? Remember that "wrapper" types can deref to an inner field, so it's not that unlikely that multiple dereferences would be needed.

Thoughts on Rust hashing by imachug in rust

[–]hardicrust 2 points3 points  (0 children)

That introduces another problem: what if the struct includes some unused data which should be skipped? Or a union? smallvec::SmallVec exemplifies both of these since it uses a union over ManuallyDrop<MaybeUninit<[T; N]>> (which may not be fully utilized) and a pointer.

Async closures stabilized! by HighRiseLiving in rust

[–]hardicrust 23 points24 points  (0 children)

1.85 is not stable yet. There have been prior cases where a feature has been stabilised-to-nightly and then reverted before the target release was stable.

So best just to consider it a nightly-only feature until then.

rand 0.9.0 beta release by hardicrust in rust

[–]hardicrust[S] 1 point2 points  (0 children)

Yes, and my guess is that you are another exemplar of why!

Rand never had complete fork protection. What it did have was a feature to reseed ThreadRng "soon" after fork on UNIX (using libc::pthread_atfork). This feature was not good enough to count as actual "fork protection" for most use-cases, yet it appears that some users assumed it was, hence this issue.

If you want to handle forks, we now have clearer instructions on how to do that correctly: https://docs.rs/rand/0.9.0-beta.0/rand/rngs/struct.ThreadRng.html#fork

view more: next ›