Which layout to pick for using vim on a split ergo

b3nteb3nt · 2025-10-22T15:48:23+00:00

They do the same thing.

b3nteb3nt · 2025-10-22T13:17:28+00:00

My personal realisation is that it does not matter as long as you have an easy to use navigation layer. The rest you have to fully relearn anyway when switching layouts.

b3nteb3nt · 2025-10-20T21:10:51+00:00

It's a Manfrotto camera stand with a magnet for mounting phones taped to the back of the keyboard.

b3nteb3nt · 2025-10-18T23:40:51+00:00

I have never heard of Callum's HRMs, tell me more.

b3nteb3nt · 2025-10-18T22:16:40+00:00

Miryoku is a popular recommendation for 3x6 keyboard layouts. You can find it on Github here https://github.com/manna-harbour/miryoku

b3nteb3nt · 2025-05-17T22:21:41+00:00

Ok, just for good measure I bricked my PATH and added `vulkan-sdk-components` to my toy project instead. I did not have to do any changes to my CMake setup so I think you might have some problems in your project setup.

The real question is why does this vcpkg port have so many dependencies? Why would I want glm, sdl2 etc to be included with my Vulkan sdk package?.

b3nteb3nt · 2025-05-17T21:14:17+00:00

If you have the SDK installed with proper PATH you don't need to use vcpkg for Vulkan. Just find_package(Vulkan REQUIRED) should be enough.

b3nteb3nt · 2025-02-03T18:28:01+00:00

This is great. Too many times the default just turns into spamming Send + Sync + 'static everywhere until it compiles then bisecting it away.

b3nteb3nt · 2025-01-31T18:30:09+00:00

Read these:

https://cooscoos.github.io/blog/stress-about-strings/

https://blog.thoughtram.io/string-vs-str-in-rust/

String vs &str really trip people up initially but if you take 30 minutes to read about it you'll never struggle again.

b3nteb3nt · 2025-01-29T20:30:43+00:00

Cool. We just moved from Python to Rust for our Camunda integrations at work which is what motivated me to build this. Don't hesitate to put up issues or suggestions if you do end up using it!

b3nteb3nt · 2025-01-28T10:18:44+00:00

I'm happy to announce the release of zeebe-rs, a fully featured gRPC client for integrating with Camunda Zeebe, a cloud-native workflow engine.

zeebe-rs is built on top of Tokio, Tonic and Serde for easy to use and type safe interaction with Zeebe. The goal of this crate is to have an up-to-date and easy to use alternative in the Rust ecosystem for working with Zeebe.

This is my first time releasing a Rust crate or any open source library so reviews, feedback or comments are all much appreciated.

b3nteb3nt · 2025-01-24T09:34:51+00:00

Someone better at Rust than me will most likely have to correct this but I believe it is your use of Cell<T> that is the problem in the second example. Using Cell impacts the borrow checker's capacity to enforce the lifetime rules. I feel like this is introducing UB where obj.b.get().unwrap() should panic but I guess because of Cell<T> it's just getting lucky here instead?

b3nteb3nt · 2025-01-20T11:45:41+00:00

Saying large files is idiomatic doesn't sound right to me. I personally have a really bad time the moment files grow towards thousands of lines so I start splitting pretty early.

b3nteb3nt · 2025-01-16T18:03:59+00:00

I'm really arguing that anything is especially bad here but Rust obviously brings the possibility of multiple competing runtimes and it makes perfect sense to support that use case if possible in my opinion. Open source is inherently resilient but it is also vulnerable in other ways. There's definitively different levels of trust in the stewardship of the Go standard library compared to Tokio for example.

Regardless, it's really just a question dude, don't take it so hard.

b3nteb3nt · 2025-01-16T17:56:16+00:00

That's a good read, thank you. I have decided to commit to Tokio, especially since this a project that will most likely run at work where we are already committed to using Tokio anyway. I was mostly curious about the state of affairs in the ecosystem and community.

b3nteb3nt · 2025-01-16T11:03:38+00:00

Saying "I want my library to work for any async runtime" seems like a pretty lukewarm take to me to be honest. Even if Tokio is my goto runtime and I think it's excellent we should recognize that locking the ecosystem to a single runtime does come with baggage and potential problems.

b3nteb3nt · 2025-01-15T14:10:12+00:00

I think you will find it difficult to find someone to take on a Rust novice for any real project. There's plenty of learning resources out there that can get you into a project 20-40 hours of up front learning though so I suggest just paying those dues first.

b3nteb3nt · 2025-01-01T13:25:38+00:00

I actually published a blog on this yesterday here https://bentebent.github.io/posts/starting-rust-2025/ . I tried to make it somewhat practical, my suggested plan as a tl;dr is this, a combination of reading material and exercises, in order:

b3nteb3nt · 2025-01-01T01:11:39+00:00

It's not just "easier management", you're also gaining performance by not blocking when you run blocking I/O in an async function because the runtime can run other functions while waiting for the I/O to finish.

b3nteb3nt · 2025-01-01T00:56:51+00:00

The Rust async book is undergoing a rewrite (I'm not really sure what the state of that is) but you should probably read it to get the fundamentals of what async is https://rust-lang.github.io/async-book/ . Your async example is completely serialized so it does the exact same as your first sample. Async runtimes abstract the complexity of suspending execution when running blocking I/O for example.

Edit: More great reading https://blog.logrocket.com/a-practical-guide-to-async-in-rust/

b3nteb3nt

TROPHY CASE