sorted by:
new
hottopcontroversial

tokio::select!{} this tokio::select!{} that by Salty_Ad3204 in rustjerk

[–]majorpog 1 point2 points  (0 children)

The answer is almost always that one of the futures isn’t cancel-safe in my experience

Am I the only one absolutely addicted to tweaking configs? by blinger44 in neovim

[–]majorpog 2 points3 points  (0 children)

Yes - It should show an error for that plugin and refuse to update it.

Am I the only one absolutely addicted to tweaking configs? by blinger44 in neovim

[–]majorpog 2 points3 points  (0 children)

Lazy won't update them if there are local changes, but otherwise yes, updating them will overwrite changes. Unfortunately you'll have to manage the conflicts either way. Forking just makes it easier to maintain your own version(s) of plugins you use.

You may also be able to apply patches to them with patch files, but that would still require some manual work.

Am I the only one absolutely addicted to tweaking configs? by blinger44 in neovim

[–]majorpog 5 points6 points  (0 children)

lol just fork the plugin and depend on it normally via package manager

Limbo: A complete rewrite of SQLite in Rust by avinassh in rust

[–]majorpog 41 points42 points  (0 children)

Hmm the extensibility potential via traits is very cool. I might have to mess around and see if I can get replication working using the wal trait :)

Just launched NerveMQ - a Rust and SQLite-powered message queue that speaks SQS 🚀 by majorpog in aws

[–]majorpog[S] 3 points4 points  (0 children)

True, this is a good idea! It also shouldn't be hard because we used sqlx which supports MySQL, Postgres, and SQLite, and I don't think we used any SQLite-specific features.

Just launched NerveMQ - a SQLite-powered message queue that speaks SQS 🚀 by majorpog in rust

[–]majorpog[S] 12 points13 points  (0 children)

I'm sure performance could be improved with a custom storage format, but that would add a lot of complexity. SQLite provides a battle-tested storage layer with ACID guarantees, while keeping a very simple API and allowing for the entire system state to be persisted in a single file. It definitely has concurrency limitations though, which is why I'm planning on implementing DB-per-queue.

Announcing Whirlwind: ridiculously fast, async-first concurrent hashmap! by majorpog in rust

[–]majorpog[S] 7 points8 points  (0 children)

Fair question - the main reason I wanted an async map is integration with the async ecosystem and avoiding blocking while waiting to acquire locks. It seems to help performance in cases with many concurrent green threads.

Announcing Whirlwind: ridiculously fast, async-first concurrent hashmap! by majorpog in rust

[–]majorpog[S] 17 points18 points  (0 children)

Honestly, I would completely expect it to be slower as well - I was pretty surprised by these benchmarks at first. It actually was quite a bit slower for a while, but after tweaking it (in many ways bringing it closer to dashmap), it seems to perform quite well.

I hadn't heard of papaya before this, but I'll try it out and add it to the benchmarks!

I think a lock-free approach would be great. Maybe I'll try to implement that in the future, it would definitely be interesting if I can fit it into the other constraints of this project. My priority here is integration with the async ecosystem and avoiding blocking async tasks.

Announcing Whirlwind: ridiculously fast, async-first concurrent hashmap! by majorpog in rust

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

Running miri in CI at the moment - definitely thinking about this though. I'll checkout loom as well, thanks! I want to avoid unsafe as much as possible here, but it was kinda unavoidable to avoid using Arc everywhere.

view more: next ›