arendjr

joined 4 months ago
[–] [email protected] 1 points 1 week ago* (last edited 1 week ago)

It’s limited to JS runtimes, but this discussion might be of use: https://github.com/biomejs/biome/discussions/2467 I think you may find Boa fits your criteria, except for the JIT part.

[–] [email protected] 5 points 1 week ago (1 children)

Yeah, sorting is definitely a common use case, but note it also didn’t improve every sorting use case. Anyway, even if I’m a bit skeptical I trust the Rust team that they don’t take these decisions lightly.

But the thing that lead to my original question was: if the compiler itself uses the std sorting internally, there’s also additional reason to hope that it might have transitive performance benefits. So even if compiling the Rust compiler with this PR was actually slower, compiling again with the resulting compiler could be faster since the resulting compiler benefits from faster sorting. So yeah, fingers crossed 🤞

[–] [email protected] 7 points 1 week ago (3 children)

Yeah, it was the first line of the linked PR:

This PR replaces the sort implementations with tailor-made ones that strike a balance of run-time, compile-time and binary-size, yielding run-time and compile-time improvements.

It was also repeated a few paragraphs later that the motivation for the changes was both runtime and compile time improvements. So a little bit bumped to hear the compile time impact wasn’t as good as the authors hoped apparently. I’m not even sure I fully endorse the tradeoff, because it seems the gains, while major, only affect very select use cases, while the regressions seem to affect everyone and hurt in an area that is already perceived as a pain point. But oh well, the total regression is still minor so I guess we’ll live with it.

[–] [email protected] 5 points 1 week ago (5 children)

The post mentioned that the introduction of these new algorithms brings compile-time improvements too, so how should I see this? I assumed it meant that compiling applications that use sorting would speed up, but that seems like a meaningless improvement if overall compilation times have regressed. Or do you mean compiling the compiler has become slower?

[–] [email protected] 7 points 1 week ago (7 children)

Does the Rust compiler use their std sort algorithms, or does it already use specialized ones? If the former, it would be a great side-effect if the compiler itself receives additional speed ups because of this.

[–] [email protected] 7 points 1 week ago* (last edited 1 week ago)

From what I understand as I skimmed over the stable sort analysis (https://github.com/Voultapher/sort-research-rs/blob/main/writeup/driftsort_introduction/text.md), it lost out against driftsort.

[–] [email protected] 17 points 2 weeks ago (1 children)

The System76 scheduler helps to tune for better desktop responsiveness under high load: https://github.com/pop-os/system76-scheduler I think if you use Pop!OS this may be set up out-of-the-box.

[–] [email protected] 3 points 3 weeks ago

Essentially, but it doesn’t roll off the tongue as nicely 😅

[–] [email protected] 4 points 3 weeks ago (1 children)

I made Sudoku Pi: https://apps.apple.com/nl/app/sudoku-pi/id6467504425

Sorry, still iOS only thus far!

 

This post highlights my experience working with software architecture in startup environments. I think the approach is different enough from the traditional notion of software architecture that it may warrant its own term: post-architecture.

[–] [email protected] 7 points 3 weeks ago (1 children)

Smart pointers are really really nice, I do recommend getting used to them (and all other features from c++11 forward).

You’re recommending him to give up his sanity and/or life?

[–] [email protected] 2 points 1 month ago

The other day I saw a link to Verus on here and it’s made me somewhat interested in the topic how Rust and formal verification can work together.

It’s quite insightful to see how the borrow checker both required and ended up facilitating the ability to do more extensive formal verification on Rust code.

Something like Verus (I haven’t looked into most of the other tools in this space yet, there seem to be many!) does appear poised to make verification quite approachable in low-level, self-contained Rust code already, and I’m curious to see how things evolve from there.

It would be exceedingly cool if one day there’s a subset of libraries on crates.io that are fully verified (similar to how today there’s a subset that supports no-std development) and which are then usable to build upon in your own formally verified code.

[–] [email protected] 2 points 1 month ago* (last edited 1 month ago) (1 children)

Based on the limited (but useful!) information in your profile and your age I would estimate competent mid-level fits you.

 

cross-posted from: https://programming.dev/post/12807878

This new version provides an easy path to migrate from ESLint and Prettier. It also introduces machine-readable reports for the formatter and the linter, new linter rules, and many fixes.

 

This new version provides an easy path to migrate from ESLint and Prettier. It also introduces machine-readable reports for the formatter and the linter, new linter rules, and many fixes.

 

I just had a random thought: a common pattern in Rust is to things such as:

let vec_a: Vec<String> = /* ... */;
let vec_b: Vec<String> = vec_a.into_iter().filter(some_filter).collect();

Usually, we need to be aware of the fact that Iterator::collect() allocates for the container we are collecting into. But in the snippet above, we've consumed a container of the same type. And since Rust has full ownership of the vector, in theory the memory allocated by vec_a could be reused to store the collected results of vec_b, meaning everything could be done in-place and no additional allocation is necessary.

It's a highly specific optimization though, so I wonder if such a thing has been implemented in the Rust compiler. Anybody who has an idea about this?

 

Just a progress update on a fun open-source project I'm involved with. Biome.js is a web toolchain written in Rust, and it provides a great excuse to play around with parsing technologies and other fun challenges :)

235
submitted 3 months ago* (last edited 3 months ago) by [email protected] to c/[email protected]
 

Slide with text: “Rust teams at Google are as productive as ones using Go, and more than twice as productive as teams using C++.”

In small print it says the data is collected over 2022 and 2023.

 
 

I have a fun one, where the compiler says I have an unused lifetime parameter, except it's clearly used. It feels almost like a compiler error, though I'm probably overlooking something? Who can see the mistake?

main.rs

trait Context<'a> {
    fn name(&'a self) -> &'a str;
}

type Func<'a, C: Context<'a>> = dyn Fn(C);

pub struct BuiltInFunction<'a, C: Context<'a>> {
    pub(crate) func: Box<Func<'a, C>>,
}
error[E0392]: parameter `'a` is never used
 --> src/main.rs:7:28
  |
7 | pub struct BuiltInFunction<'a, C: Context<'a>> {
  |                            ^^ unused parameter
  |
  = help: consider removing `'a`, referring to it in a field, or using a marker such as `PhantomData`

For more information about this error, try `rustc --explain E0392`.
error: could not compile `lifetime-test` (bin "lifetime-test") due to 1 previous error
 

Today I'm sharing a little trick that I like to use to make switch statements cleaner and more type-safe. Happy to hear other ideas!

 

As part of my Sudoku Pi project, I’ve been experimenting with improving the Bevy UI experience. I’ve collected most of my thoughts on this topic in this post.

 

I wrote a post about how our Operational Transfomation (OT) algorithm works at Fiberplane. OT is an algorithm that enables real-time collaboration, and I also built and designed our implementation. So if you have any questions, I'd be happy to answer them!

view more: next ›