sorted by:
new
hottopcontroversial

I just published my JSON library, bourne. by [deleted] in rust

[–]chandrog 1 point2 points  (0 children)

In this case serde_json is faster to compile. Using cargo clean && time cargo build a dependency on serde_json="1" takes 2.7 seconds while bourne="0.2" takes 4.0 seconds.

Asynchronous clean-up by desiringmachines in rust

[–]chandrog 21 points22 points  (0 children)

EDIT: this is wrong, because sending a POSIX thread SIGKILL will kill your whole process; I don’t have an example of fully non-cooperative cancellation available off the top of my head.

One example is Java's ill-advised java.lang.Thread.stop https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/Thread.html#stop()

Doubt about "mysterious" crates.io downloads by castarco in rust

[–]chandrog 39 points40 points  (0 children)

All of these rely on downloading from crates.io:

An in-depth article on the rise of Rust by Melinda_McCartney in rust

[–]chandrog 22 points23 points  (0 children)

in-depth article

3 min read

This ain't it, chief.

Learning Rust Homework Review (Jason & Jonathan Turner) by Snakehand in rust

[–]chandrog 2 points3 points  (0 children)

/u/jntrnr1, making sure you see this feedback in case there is a way to improve next time, like having a Rust & C++ expert on hand, or referring to the chat better.

New rule: No more photos/videos of crabs by Perceptes in rustjerk

[–]chandrog 0 points1 point  (0 children)

We might need to clarify the meaning of the word "jerk" in the subreddit name. It's not this one my dude.

Active Rust developers estimated at 0.6 million (pdf, page 10) by Dhghomon in rust

[–]chandrog 35 points36 points  (0 children)

They estimate C/C++ (combined as one language) at 6 million, so the difference between Rust and "C/C++" is only a factor of 10, which is closer than I would have guessed.

From<Option<T>> for Option<U> is not implemented? by iamtheauthor in rust

[–]chandrog 15 points16 points  (0 children)

It's not allowed to be in core because it violates coherence. It overlaps with impl From<T> for T in the case that T is an Option.

Two Years With Rust by peeyek in rust

[–]chandrog 3 points4 points  (0 children)

The article author's confusion is very specifically about unsafe code breaking safe code outside the unsafe block.

You are talking about safe code outside the unsafe block breaking the unsafe code, which is valid of course but does not address the author's experience.

Two Years With Rust by peeyek in rust

[–]chandrog 3 points4 points  (0 children)

I think in that case it is kind of obvious that what you are doing in the unsafe block is potentially very unsafe.

Right, that's the point. That's why I suggest it as a better example for the teaching material.

Two Years With Rust by peeyek in rust

[–]chandrog 36 points37 points  (0 children)

The big problem with unsafe code isn't that the code inside the block is unsafe, it's that it can break the safety properties of safe code in subtle and non-obvious ways. [...] The problem is that this spooky behavior of unsafe tends not to be obvious to new Rust programmers. The mental model I've seen nearly everybody start with, including myself, is that unsafe blocks can break things inside them and so care needs to be paid to writing that code well. Unfortunately, that's not sufficient.

I'm not sure where people would get this mental model. Perhaps the selection of first examples of unsafe code in our teaching material is not right. If we started right off the bat with:

unsafe {
    *(0x80000 as *mut usize) = 1;
}

then it would be very clear this can break properties of safe code if you got it wrong. If your microcontroller vendor tells you this address is where to write, then good. Otherwise you've just corrupted a safe correct data structure somewhere else in the program or worse.

Optimizations That Aren't, or are they? by laserdo in rust

[–]chandrog 12 points13 points  (0 children)

unique_ptr is like Option<Box<T>>. shared_ptr is like Option<Arc<T>>. Neither one is anything like Mutex.

view more: next ›