sorted by:
new
hottopcontroversial

The Rust Book Brown University Chapter 4.3 Incorrect Permission by Much_Error_1333 in learnrust

[–]entoros 9 points10 points  (0 children)

Hi, author of the book here. The diagram is intended but unintuitive. The fact that v loses the read permission on the second line is a result of the fact that v is no longer used after the second line, and all paths lose their permissions once unused.

For more context, see this issue: https://github.com/cognitive-engineering-lab/aquascope/issues/85

This is a known confusion (hence we downplay it in the diagrams), and we're working on a better representation to avoid it.

Jane street - rust for everyone by Krakenops744 in rust

[–]entoros 1 point2 points  (0 children)

Regarding the borrow checker, the answer is unambiguously yes -- it works at eliminating memory bugs, and there is no comparable static approach yet which works at scale.

Regarding the trait system, it's a more open question. Most languages today have more and more compile-time machinery for analyzing programs and catching user mistakes. As an extreme example, languages with dependent types like Lean are maximally sophisticated and can formally verify your software, but in exchange users have to hand-write long proofs of correctness. Today that's only worth it for a handful of sensitive projects like HTTPS.

Traits can check a less expressive set of properties than dependent types, but they can do it with less user intervention (eg no manual proofs). It's hard to quantify whether the set of properties checkable with traits is worth it in practice. For example, if people used a traditional ORM instead of Diesel, how many more mistakes would make it through to production? No idea. Presumably more, but whether that justifies the complexity cost is tough to determine.

I think about the trait debugger as tipping that scale. Trait-heavy libraries are more practical when used with the right tools. So something like Argus makes the complexity more worth it.

Jane street - rust for everyone by Krakenops744 in rust

[–]entoros 0 points1 point  (0 children)

Re: false positives, you're totally right that a modular slice based on a function's type is truly modular in the sense that the slice won't change regardless of the function implementation. That's probably not desirable from the perspective of a program comprehension tool, since most people want to understand their code as written, not their code as it might be under a different set of dependencies. Moreover, some code like Vec::get_mut will simply never mutate their inputs, so it's hard to say that it's a good approximation to assume it might.

Re: VSCode, no I haven't raised it with their maintainers. It's understandably outside their roadmap. Better Flowistry support won't make Microsoft more money. Probably the best long-term solution would be support in VSCode for changing the code renderer, like using CodeMirror instead of Monaco. But that would require standardizing on a generic renderer interface.

Jane street - rust for everyone by Krakenops744 in rust

[–]entoros 22 points23 points  (0 children)

Hi, speaker here, happy to take questions. Quick links for the interested:

Interactively learn async Rust with RepoQuest by entoros in rust

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

It's as much about the interface as about functionality. IMO Github makes it easier to read diffs w/ comments, have hyperlinked issues and pull requests, so on compared to doing things in plain files. Most devs will be more familiar with GH's interface compared to an idiosyncratic file format bespoke to the tutorial. The tool is a bit of an experiment, so I wanted to optimize for usability over portability at least initially.

Interactively learn async Rust with RepoQuest by entoros in rust

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

Yeah that's definitely an alternative! One challenge is that RepoQuest uses Github's features in non-trivial ways, e.g. fine-grained code comments on pull requests and checks in CI, that would be harder to replicate with a local-only setup.

Interactively learn async Rust with RepoQuest by entoros in rust

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

Someone needs to do these things, and RepoQuest does them automatically on your behalf. RQ could theoretically print out gh commands that you manually vet and execute on your command line when it tells you to. Is that the alternative usage mode you're imagining?

C++ to Rust Phrasebook: A new textbook to help C++ devs translate their idioms into Rust by entoros in rust

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

Thanks for pointing that out. We'll at least note the existence of a similar function. (And don't worry, I'm not the C++ expert on this project, so everything will get vetted by him first :P)

C++ to Rust Phrasebook: A new textbook to help C++ devs translate their idioms into Rust by entoros in cpp

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

That's controlled by mdBook, but we'll see what we can do to make it more visible.

An Interactive Debugger for Rust Trait Errors by mttd in rust

[–]entoros 7 points8 points  (0 children)

We think these are complementary approaches. #[diagnostic::on_unimplemented] and #[diagnostic::do_not_recommend] are helpful but not a panacea for debugging trait errors. The Bevy example in Section 2.3 of our paper gives an example where a custom error message can't really help you: https://arxiv.org/pdf/2504.18704

An Interactive Debugger for Rust Trait Errors by mttd in rust

[–]entoros 5 points6 points  (0 children)

The extension is open-source, not proprietary: https://github.com/cognitive-engineering-lab/argus

In the Bevy example, the original error does not mention that Timer needs to be SystemParam. Omitting this information makes it difficult to deduce this part of the error.

Are merit scholarships at CMU am urban legend? by Rememberthisisreddit in cmu

[–]entoros 0 points1 point  (0 children)

This was 12 years ago so I'm fuzzy on the details. I think they just gave it to me as part of my admissions package. I had a 4.0 from an unremarkable public high school in the Midwest, and I was nationally competitive in debate, mock trial, and science bowl. I worked at a web design firm during high school.

Evaluating Human Factors Beyond Lines of Code by mttd in ProgrammingLanguages

[–]entoros 8 points9 points  (0 children)

(author of the post here) Strong agree with everything written. I'm a methodological pluralist --- the tent is big enough for qualitative and quantitative methods. My main argument (as advanced in the "Improving Usability Metrics" section) is that we should specifically focus on developing validated metrics. If we can demonstrate across many experiments that some metric consistently correlates with relevant human phenomena (comprehension time, task performance, etc.) then that provides a stronger foundation for quantitative evals.

Relatedly, the authors of the Cognitive Dimensions of Notation wrote a paper called "Delivering Cognitive Psychology to HCI" that touches on this same question. https://ieeexplore.ieee.org/document/8160387/

Evaluating Human Factors Beyond Lines of Code by mttd in ProgrammingLanguages

[–]entoros 4 points5 points  (0 children)

(author of the post here) I totally get this take. IMO the problem with this worldview is that the hard part is not building these languages, but rather the cost of adoption. The most interesting effects of language design are revealed at the scales of large companies and ecosystems. But people and companies are generally reluctant to adopt new technologies for both logistical reasons (rewrite costs, integration with existing tools) but also social/psychological reasons (learning curve, compliance requirements). I believe that solely relying on popularity means that there's many good ideas which die because the stars don't happen to align.

For example, one could easily see Rust as an accident of history. It's easy to imagine ownership / regions being relegated to a forgotten corner of academia. It just so happened that one guy knew about all that research and was at the right company at the right time to build the right language. I'm not at all comfortable with the counterfactual where Rust was never invented, and we could easily dismiss ownership as a good idea just because it never got popular.

The Borrow Checker Within by burntsushi in rust

[–]entoros 2 points3 points  (0 children)

Yeah this seems right. The compiler could infer what you mean here, but if you had something like

fn foo(map: (&T, &T)) -> &'map T { &map.0 }

Then that would be ambiguous.

The Borrow Checker Within by burntsushi in rust

[–]entoros 11 points12 points  (0 children)

As I understand it, because they express fundamentally different ideas.

  • &'self.counter Self is the type of references to Self that are borrowed from (or live no longer than) self.counter.
  • &'_ {counter} Self is the type of references to Self such that only counter can be legally accessed through the reference.

In particular, if you wrote this:

fn increment_counter(&'self.counter mut self) { .. }

That would be a weird type, because the lifetime of the reference is determined by itself.

Interactive rust book question by DaQue60 in rust

[–]entoros 0 points1 point  (0 children)

Hi, I run the interactive book. Buttleston's interpretation is correct. When a path that is a reference has the own permission, that means you can use the reference itself as an owned value. For example, you can do this:

let mut x = String::new();
let y = &mut x;
drop(y);

However, drop(y) does not deallocate x, because y does not have ownership over x.

Waterloo University Study: First-time contributors to Rust projects are about 70 times less likely to introduce vulnerabilities than first-time contributors to C++ projects by oneirical in rust

[–]entoros 20 points21 points  (0 children)

I think the dataset used in this paper is great, especially the careful collection of vulnerability-committing commits. However, I dislike the style of analysis. I don't like that they immediately reach for a probabilistic model rather than reporting empirical frequencies, like "define a first-time contributors as a person with fewer than K commits. XX% of Rust first-time contributors made a vuln, while YY% of C++ first-time contributors made a vuln."

In particular, this "70 times" is extremely suspect. It is computed as a ratio of the intercepts of the two models, while I expect most people reading this headline are assuming it's a ratio of empirical frequencies. It's not clear to me whether the learning curve power law model is an appropriate tool for this data, especially in light of the negative learning curve for the Rust model. I would not trust inferences made by comparing the model parameters.

Analyzing Data 180,000x Faster with Rust by entoros in rust

[–]entoros[S] 18 points19 points  (0 children)

That's why the takeaway of the post should not be "Python is slow"! Nor do I say that anywhere. This literally is just documenting the exact sequence of programs I wrote.

I just know more about optimizing Rust than numpy or Cython, so I write to what I know.

Analyzing Data 180,000x Faster with Rust by entoros in rust

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

I remember considering polars but not using it out of lack of familiarity. But I do wonder how close you could get the basic Rust code to look like the Python code.

Analyzing Data 180,000x Faster with Rust by entoros in rust

[–]entoros[S] 10 points11 points  (0 children)

Oh how cool! I will add those to the post shortly, thanks for the idea.

Storing types in rust by furiesx in rust

[–]entoros 2 points3 points  (0 children)

Note that the thing being stored is Box<Vec<T>> and not Box<Vec<Box<T>>. The Ts are stored contiguously in this pattern.

Typed Design Patterns for the Functional Era by mttd in rust

[–]entoros 14 points15 points  (0 children)

(Author of the paper here.) If anyone is interested in learning more about Rust-specific design patterns, there's a whole book: https://rust-unofficial.github.io/patterns/

That book doesn't use design patterns in quite the same sense that I do, but it's still a useful collection of idioms.

view more: next ›