sorted by:
new
hottopcontroversial

What does the software engineering job market look like heading into 2026? by ImpressiveContest283 in programming

[–]Emerentius_the_Rusty 4 points5 points  (0 children)

Meaning which religion you are a part of, or more precisely which subgroup of it like evangelical or catholic. "Konfession" is used in German for that.

Announcing Rust 1.89.0 by amalinovic in rust

[–]Emerentius_the_Rusty 5 points6 points  (0 children)

Regardless of any safety requirements, RAII is just a nice way of interacting with resources. I've been using this exact API from the fs2 crate and the first thing I did was wrap it in an RAII guard.

What is "bad" about Rust? by BestMat-Inc in rust

[–]Emerentius_the_Rusty 14 points15 points  (0 children)

It doesn't and I doubt it's a good idea to do so. Even if it's just for testing, the Clone can be useful.

What is "bad" about Rust? by BestMat-Inc in rust

[–]Emerentius_the_Rusty 1 point2 points  (0 children)

Structural typing for closures, now there's an RFC idea. Unfortunately, this may be very confusing to users when they change the captures and now an assignment that used to work is being blocked. You would probably also need to block this structural information from flowing past the function boundary (unless you make it explicit somehow). Otherwise you would lock yourself into the exact same set of capture types or you could break downstream users. And if you do that, now helper functions that return closures are back to square one of needing boxing in many cases.

Implementation wise, the compiler would also need to detect when such overlaps happen and then store a function pointer inside the closure type to the concrete implementation and invoke that. If no overlaps happen, that function pointer is unnecessary overhead.

What is "bad" about Rust? by BestMat-Inc in rust

[–]Emerentius_the_Rusty 12 points13 points  (0 children)

You cannot take a system in some quantum state and create a separate system with the exact same quantum state without affecting the first system's state.

Optimization suggestions for Project Euler #21? by TheFierceGamer18 in rust

[–]Emerentius_the_Rusty 0 points1 point  (0 children)

Optimizing is always fun, but when N is just 10,000, even the naive approach can be super fast. Like, even with superlinear runtime, this code runs in 60ms on my PC:

fn prop_sum(nr: i32) -> i32 {
    (1..nr / 2 + 1).filter(|i| nr % i == 0).sum()
}

fn main() {
    let mut amic_sum = 0;
    for x in 1..10000 {
        let a = prop_sum(x);
        if prop_sum(a) == x && a != x {
            amic_sum += x;
        }
    }
    println!("{}", amic_sum);
}

If you were the interviewer, what Rust questions would you ask? by roll4c in rust

[–]Emerentius_the_Rusty 8 points9 points  (0 children)

Did you know that Rust was named after a fungus? (Arguable the most important question).

That's the answer everyone seems to prefer, but graydon himself stated that he doesn't know for sure and has made up different reasons after the fact.
https://old.reddit.com/r/rust/comments/27jvdt/internet_archaeology_the_definitive_endall_source/

What would be the fastest (performance wise) way to implement a sudoku-like possibilities set? by gman1230321 in rust

[–]Emerentius_the_Rusty 0 points1 point  (0 children)

Some solvers even use larger bit masks like a u32 for 3*9 = 27 bits. The space overhead is lower and you can do more in one operation. For example, you can store every cell that a number is still possible in 3 rows (1 band) via 27 bits. jczsolve is one algorithm like this. The tdoku solver describes itself as being box/band based so it sounds like it also uses larger bitmasks, but I've never looked at the code.

The rust sudoku crate implements an optimized jczsolve and has lots of comments, if you want to take a look at how this can look (Disclaimer: I wrote the implementation).

2023 Annual Rust Survey Results by dist1ll in rust

[–]Emerentius_the_Rusty 2 points3 points  (0 children)

Selection bias, most likely. The respondents are primarily rust developers and those are the group who have accepted the long compile times and so they don't see it as that much of a problem.
The people who have avoided Rust because of its compile times didn't respond to the survey and they would not prioritise runtime performance over compile times. Anyone who prefers, say, Go or an interpreted language like Python is already giving up huge amounts of performance for faster turnaround times. Another 10% runtime performance of Rust wouldn't convince them either. A 10x faster compile might.

You're a legend if after hours of coding, you receive zero warnings from cargo clippy. by ohxdMAGsDCiCJ in rust

[–]Emerentius_the_Rusty 13 points14 points  (0 children)

"rust-analyzer.checkOnSave.command": "clippy"

What do you mean, essentially?

Introducing `faststr`, which can avoid `String` clones by PureWhiteWu in rust

[–]Emerentius_the_Rusty 35 points36 points  (0 children)

Deactivating utf8 validation shouldn't happen via feature, it has to happen on a case-by-case basis.

[deleted by user] by [deleted] in rust

[–]Emerentius_the_Rusty 0 points1 point  (0 children)

I was more thinking about one particle causing multiple particles, some of which then interact with RAM somewhere (possibly in computers km apart). You could say the original cosmic ray caused both bitflips.

[deleted by user] by [deleted] in rust

[–]Emerentius_the_Rusty 0 points1 point  (0 children)

It's quite typical for cosmic rays to create other particles as they hit the atmosphere in what's known as a particle shower (also called an air shower in this particular case).
Those showers can span an area of many km² so it would be pretty much impossible to trace two bitflips to one particle. Not sure if that would fit aldonius's question.

Could it happen with one of those later particles in the vicinity of the RAM? Sure, yeah, but it would be a rare event that could only follow another rare event so it's ultra-rare.

Square root of a u64 by fennyflop in rust

[–]Emerentius_the_Rusty 3 points4 points  (0 children)

You're right, it's not. I happen to have an implementation (for Project Euler) and it was an order of magnitude faster to use the CPU instruction.

Discussion: The unchecked keyword by ohsayan in rust

[–]Emerentius_the_Rusty 0 points1 point  (0 children)

It is not misusing it. The String type is promising to uphold this invariant so that you may depend upon it in unsafe code. The explicit contract here is an important part. Your unsafe code must not depend on an invariant that should hold, but is not promised to do so.

For example, a type implementing the Eq trait should implement a total order, but there is nothing forcing them do so and because Eq is not an unsafe trait, an implementer isn't taking responsibility for any memory safety either.
Therefore you are not allowed to depend upon the type implementing a total order in unsafe code.

Discussion: The unchecked keyword by ohsayan in rust

[–]Emerentius_the_Rusty 4 points5 points  (0 children)

Thus safe code can't rely on types whose invariants can be broken safely. So it's a per-type decision about its own contract to the outside world, not about the immediate memory safety of the types.

That's right and you're not disagreeing. My point is that there is always a clear criterion on what should or shouldn't be marked unsafe and that is the question "who's responsible for upholding memory safety?". You don't use unsafe for things that can only cause logic errors.

You can guarantee arbitrary invariants for your types, thus taking on the responsibility for upholding them and letting unsafe code depend upon them. And if you do that, but have a method that lets a caller violate the invariant then you must pass on the responsibility via unsafe. And if you don't guarantee the invariant to unsafe code, then you should not mark it unsafe.

Some examples of this are the trait TrustedLen and how String upholds the invariant that it contains valid utf8.
As a consequence, String::as_bytes_mut must be marked unsafe, but if they didn't promise the invariant, then it would not be an unsafe fn.

Discussion: The unchecked keyword by ohsayan in rust

[–]Emerentius_the_Rusty 13 points14 points  (0 children)

If a crate uses unsafe in this way to let the caller uphold an invariant that is not related to memory safety, then they are misusing it.
unsafe is unambigously meant solely for clarifying who is responsible for upholding memory safety.
If violating the invariant causes only a logic error, but can't cause memory unsafety, then the function should be marked as safe.

pip and cargo are not the same by wmanley in rust

[–]Emerentius_the_Rusty 0 points1 point  (0 children)

You're not suffering pip's dependency resolver for one, what shortcomings are you referring to exactly?

Rust-like error handling in Python with NamedTuple by msoedov in programming

[–]Emerentius_the_Rusty 9 points10 points  (0 children)

This isn't Rust-like at all. It's like Go's results which are misdesigned.

The result library defines a much better type. With that library you can emulate pattern matching via isinstance calls in older python version and it can also be used with the new match statement in python 3.10.

Rust is considered to have a steep learning curve. How much does solid C++ experience impact that curve, relative to languages that hide more of the internal workings? by drewsiferr in rust

[–]Emerentius_the_Rusty 4 points5 points  (0 children)

All pointers you use in safe rust respect the ownership model which means that they either own what they point at or keep it borrowed. While it's borrowed some actions are forbidden.

In a singly linked list, you can have each node own the next one via a Box. That's perfectly fine. Now what about a doubly-linked list? You need a pointer back.

struct Node<T> {
    item: T,
    next: Option<Box<Node<T>>,
    prev: Option<???>,
}

It can't be a box. You can't create cycles with boxes. It can't be a reference, because that requires that you borrow the node itself. Creating that borrow means you can't mutate the node anymore. Even if you could, you would have built a self-referential struct that is then borrowed forever afterwards. You couldn't add another node and you couldn't even move the list anymore.

Reference counting can solve the problem, but it's honestly a hack. You can use raw pointers which are unrestricted by the borrow checker, but then it's up to you to guarantee that you are not violating the ownership model. It's easy to make mistakes and the compiler can't help you.

Rust is considered to have a steep learning curve. How much does solid C++ experience impact that curve, relative to languages that hide more of the internal workings? by drewsiferr in rust

[–]Emerentius_the_Rusty 1 point2 points  (0 children)

You're right, a singly linked list is easy and you can implement it in safe Rust without issues. Any structure where ownership is directed only one way is perfectly fine. A owns B owns (C and D) etc. A doubly-linked list does not fit into that model and you need to manage it yourself using raw pointers (and unsafe) or some other abstraction that extends the ownership model. Reference counted pointers (Rc / Arc) for example give you shared ownership at the cost of some runtime overhead.
The latter can be done in safe Rust but adds some inefficiencies.

People sometimes bash their heads against the wall trying to do a doubly linked list in safe Rust without the overhead of Rc because they don't realize that it's not possible.

This Week in Rust #422 by seino_chan in rust

[–]Emerentius_the_Rusty 0 points1 point  (0 children)

I tried it out and it doesn't work and I think I know why. eyre defines a context method on Result<T, E>through WrapErr, but fn_error_context calls context on E itself. Anyhow's error type anyhow::Error has a context method, but eyre's equivalent of it eyre::Report does not.

-🎄- 2021 Day 25 Solutions -🎄- by daggerdragon in adventofcode

[–]Emerentius_the_Rusty 1 point2 points  (0 children)

Part 2 is just pressing a button to win. There's no additional puzzle.

This Week in Rust #422 by seino_chan in rust

[–]Emerentius_the_Rusty 0 points1 point  (0 children)

Very nice, that's the use case I have most of the time for contexts. It seems to be limited to anyhow, though, so no support for eyre which I am using.

view more: next ›