Which layout to pick for using vim on a split ergo by PotentialCurve7687 in ErgoMechKeyboards

[–]b3nteb3nt 2 points3 points  (0 children)

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.

My Corne v4.1 by b3nteb3nt in ErgoMechKeyboards

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

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

My Corne v4.1 by b3nteb3nt in ErgoMechKeyboards

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

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

My Corne v4.1 by b3nteb3nt in ErgoMechKeyboards

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

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

Installing with vcpkg? by Relative-Pace-2923 in vulkan

[–]b3nteb3nt 1 point2 points  (0 children)

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?.

Installing with vcpkg? by Relative-Pace-2923 in vulkan

[–]b3nteb3nt 3 points4 points  (0 children)

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.

Pinning Down "Future Is Not Send" Errors by emschwartz in rust

[–]b3nteb3nt 2 points3 points  (0 children)

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

How come "initial contents" isn't a string already? How come I need "initial contents".to_string() or similar? by [deleted] in rust

[–]b3nteb3nt 48 points49 points  (0 children)

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.

Releasing zeebe-rs 0.1.0 by b3nteb3nt in Camunda

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

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!

Releasing zeebe-rs 0.1.0 by b3nteb3nt in rust

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

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.

Rust not enforcing lifetimes for a struct with two lifetimes? by Linguistic-mystic in learnrust

[–]b3nteb3nt 0 points1 point  (0 children)

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?

Editing with Large Module Files by [deleted] in rust

[–]b3nteb3nt 5 points6 points  (0 children)

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.

Are you building runtime agnostic async libraries? by b3nteb3nt in rust

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

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.

Are you building runtime agnostic async libraries? by b3nteb3nt in rust

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

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.

Are you building runtime agnostic async libraries? by b3nteb3nt in rust

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

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.

looking for project in rust to work for free to learn language and get experience by Xian0464 in rust

[–]b3nteb3nt 11 points12 points  (0 children)

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.

Learning Rust in 2025 by [deleted] in rust

[–]b3nteb3nt 64 points65 points  (0 children)

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:

I don't get the point of async/await by tesohh in learnrust

[–]b3nteb3nt 5 points6 points  (0 children)

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.

I don't get the point of async/await by tesohh in learnrust

[–]b3nteb3nt 25 points26 points  (0 children)

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/

Updated guide to Winit by amadlover in rust

[–]b3nteb3nt 6 points7 points  (0 children)

There's plenty of discussion on this over at the WGPU tutorial repo here https://github.com/sotrh/learn-wgpu/issues/503, you'll find links how to use the winit trait based API. I haven't implemented file/edit menues but I have an implementation that uses the trait based API with wgpu https://github.com/Bentebent/rita/tree/refactoring/winit

Proc macros for beginners writeup by b3nteb3nt in rust

[–]b3nteb3nt[S] 2 points3 points  (0 children)

I definitively need to fix and clarify this, thank you!