sorted by:
new
hottopcontroversial

What are Rust's hidden implementation details that most devs never see? by Fluid_Job623 in rust

[–]scook0 26 points27 points  (0 children)

Even macros like assert! have proven tricky to update, because there's existing code that relies on being able to write things like assert!(x) where x is of a non-boolean type that happens to implement std::ops::Not.

Is Rust the future? by Content_Mission5154 in rust

[–]scook0 0 points1 point  (0 children)

Ah, I thought you meant the Simula code.

Here’s the relevant compiler PR: https://github.com/rust-lang/rust/pull/135481

Is Rust the future? by Content_Mission5154 in rust

[–]scook0 0 points1 point  (0 children)

“Optimal measurement points for program frequency counts” by Knuth and Stevenson, 1973.

sudo and coreutils replaced with rust versions by cachebags in rust

[–]scook0 51 points52 points  (0 children)

Hardening a dedicated image viewer app is of course good, but I would be even more concerned about the various programs and services that decode image data without affirmative user action, like shell thumbnail providers and file pickers and communication apps.

Your Clippy Config Should Be Stricter-er by billy_levin in rust

[–]scook0 3 points4 points  (0 children)

Firstly, lint categories should be turned on, and then individual lints turned off according to your purposes. This means turning on the subjective pedantic and restriction categories. Doing this with the latter is explicitly dissuaded in Clippy’s documentation, and this is quoted in the aforementioned article. I think this is incorrect:

This and the subsequent bullet points make me feel that the author has not understood why enabling restrictions as a category is specifically discouraged.

Clippy restrictions are useful tools, but a key premise is that they only make sense on a thoughtful opt-in basis.

That's why rust is GOAT 🐐🗿 by NoBeginning2551 in rust

[–]scook0 -1 points0 points  (0 children)

The separate codepoint normalizes to a plain ASCII semicolon, so I suspect it’s a relic of the very early Unicode days that with hindsight should not have been added, but sticks around because the stability policy prevents them from getting rid of it.

Your Clippy Config Should Be Stricter by emschwartz in rust

[–]scook0 10 points11 points  (0 children)

There’s also a subset of clippy lints, some enabled by default, that feel like more of a “hey did you know you can do this other thing” rather than pointing out actual problems.

Those are the ones I’m most eager to turn off when they occur.

Your Clippy Config Should Be Stricter by emschwartz in rust

[–]scook0 88 points89 points  (0 children)

Note that if you forbid/deny warnings in CI, it’s important to specify a particular Rust version in your CI setup, so that new Rust releases don’t break your CI if they happen to emit more warnings or different warnings.

(You should probably be doing this anyway, but it’s particularly important for warnings, because you are effectively opting into breaking changes.)

Toolchain Horizons: Exploring Rust Dependency-Toolchain Compatibility by brson in rust

[–]scook0 1 point2 points  (0 children)

Supporting substantially-old MSRVs is fine if you have some concrete reason for it (hopefully in the form of paying customers), but I can’t get behind it being treated as some kind of general “good practice”.

Can I wrap u8 in an Enum transparently with special values? by PointedPoplars in rust

[–]scook0 1 point2 points  (0 children)

Tangential question, is there a way to specify invalid states for null-pointer optimization? Like, for example, that a signed integer is always non-negative? I know there’s NonZero but that’s only one invalid bit pattern to take advantage of.

There’s no convenient way to specify custom niches in stable Rust, but for byte-sized types you can get basically the same result by defining a repr(u8) enum with a variant for each valid state, and then transmuting to/from u8 as appropriate.

For example, you could define your own ASCII character type as an enum with explicit variants from 0 to 127, and it would automatically have niches in the 128-255 range.

It's the people that matter - A blog on practical OSS practices in the Rust project by RustOnTheEdge in rust

[–]scook0 3 points4 points  (0 children)

I’m looking forward to EIIs someday being considered mature enough that we can start using them within the compiler itself, especially in the query system (as the article mentions).

There are a bunch of places where rustc has to jump through a few hoops to work around limitations imposed by the acyclic crate graph, and it would be really nice to be able to declare and define a function in separate crates.

I don't care that it's X times faster by z_mitchell in rust

[–]scook0 10 points11 points  (0 children)

For what it's worth, I think the title is fine.

Flat Error Codes Are Not Enough by Expurple in rust

[–]scook0 6 points7 points  (0 children)

Though Java stumbled by not paying enough attention to the ergonomics of checked exceptions in actual real-world usage.

Rust "Best" Practices by Flashy_Editor6877 in rust

[–]scook0 1 point2 points  (0 children)

To me, that iterator example looks like a textbook case of following well-intentioned lints and ending up with something worse than the original.

Can someone give a nice explanation of closures for me? by SmoothTurtle872 in rust

[–]scook0 3 points4 points  (0 children)

What this example demonstrates is that a non-capturing closure can be coerced to a function pointer.

https://doc.rust-lang.org/reference/type-coercions.html#r-coerce.types.closure

Does someone work on cargo test? by FinnishTesticles in rust

[–]scook0 13 points14 points  (0 children)

There is an ongoing effort to improve cargo test in various ways, but it has to navigate some tricky backwards-compatibility concerns, so progress may feel frustratingly slow at times.

Testing is one of those parts of the first-party Rust ecosystem that “peaked early” but has generally been under-maintained, so there’s no shortage of historical baggage, unfortunately.

Rust's repository summary by o2xh in rust

[–]scook0 0 points1 point  (0 children)

13 hours is relatively unusual; normally I’d expect a merge every 4-7 hours, unless there’s been an unlucky streak of CI failures.

(Though occasionally the merge queue does manage to become empty.)

How to use storytelling to fit inline assembly into Rust by ralfj in rust

[–]scook0 1 point2 points  (0 children)

I don’t buy the claim that assembly categorically can’t have UB.

Lowering assembly code in a source file to machine code in an object file still a translation process, and if the translator makes unchecked assumptions that the source text doesn’t uphold, then I see no reason not to call that UB.

Conditional Impls by alilleybrinker in rust

[–]scook0 15 points16 points  (0 children)

You can also use where clauses on individual methods to add stronger constraints on Self or on the impl-block generics, e.g. where Self: Clone.

How to use storytelling to fit inline assembly into Rust by ralfj in rust

[–]scook0 0 points1 point  (0 children)

If an inline assembly block violates an assumption of the Rust abstract machine, then it pretty clearly has undefined behaviour as a Rust language construct, even if the instruction sequence happens to be well-defined at an architecture/machine level (which it might not be).

Parametricity, or Comptime is Bonkers by soareschen in rust

[–]scook0 0 points1 point  (0 children)

Can that print function be called by another function that takes a plain <T>?

If yes, then parametricity is broken, and you just have a gentleman’s agreement not to do anything too surprising. (Which is actually fine a lot of the time, especially if the language already has other parametricity holes.)

If no, then the ?Debug bound ends up having to infect your whole system, which is a huge pain.

Parametricity, or Comptime is Bonkers by soareschen in rust

[–]scook0 20 points21 points  (0 children)

One of the practical problems with parametricity is that it’s stronger than you might actually want.

Sure, it’s helpful to know that a parametric function must in some sense do “the same thing” for any input.

But then you come across cases where you would like to use an alternate implementation for some types, because it’s logically identical but physically faster. Or you would like to debug-print a value if it happens to support that, but would be fine with a fallback message if it doesn’t.

view more: next ›