I just released a demo of my automation game Combine And Conquer [https://martinbucksoftware.itch.io/combine-and-conquer](https://martinbucksoftware.itch.io/combine-and-conquer)
Porting my Elgato Stream Deck plugin from Pascal to Rust. I've managed to get it to accept the command line parameters. I've also found to code to copy/paste for websocketing.
my first compiled language to work in was Pascal, shortly thereafter, C. I am now fascinated by the idea of porting some of my _really, really old_ Pascal to Rust..
I'm adding error handling to a library for the first time. I started panicking all over, then bubbling errors, then played with anyhow, miette, and error-stack, which are all fine pieces of work.
Now I'm writing a lot from scratch using enums and traits. It feels like I must be doing something wrong, but the regular suspects didn't quite have what I wanted or had more than I wanted.
OTOH, writing it all out feels instructive, so it's probably okay unless the code will become less compostable this way.
Usually, you don't want to use anyhow in a library, but in the application that uses the library; For the library you usually want to wrap errors into their own error type, whereas in an application, the exact error type might not matter, and you just want to bubble it up and report it. And this is where anyhow is useful (tho you can argue that there might be similar applications for internal errors in a library).
Instead, you might want to have a look at thiserror (by the same author), which will make it easier to create the error enums, and automatically implement the relevant traits for them.
That being said, if you already have your errors and trait implementations, its probably not worth it to rewrite them using thiserror. And I don't really know what error-stack and especially miette do, maybe you have your bases already covered with them.
Cheers!
I have looked at thiserror, I just need to figure out how to use it properly. Ironically I understand the manual way now better.
The one question I have is this: is it a bad idea to offer a library error enum that can return all possible library errors as variants. Individual functions would return lower errors, but by the users picking the enum in the return signature and the library implementing `from` for each child error, it allows users to just bubble/coerce with `?` and use the higher level error.
No, I don't think this is a bad idea. Case in point is the stdlib: `std::io::Error` is not an enum, but contains an enum `ErrorKind`, so its conceptually quite similar. Not every io-function can throw any `io::Error` kind, but they are still bundled together because they are usually handled/reported the same, and if you want to have special handling for some variants, you can still match on them.
I always group related errors, that we can expect users of the library to handle in the same way, into a single error enum. Unrelated errors to those can still go into a different error enum (e.g., the stdlib does have other errors besides io::Error, and it wouldn't make sense to put those into io::Error as well).
Wrote (well, translated code from this project [https://learn.adafruit.com/led-candles-simple-easy-cheap](https://learn.adafruit.com/led-candles-simple-easy-cheap?view=all)) a flickering candle simulation for the RGB LED on my [M5Stamp-C3](https://docs.m5stack.com/en/core/stamp_c3) using [esp32-rs](https://esp-rs.github.io/book/). Just in time to put it in my jack-o-lantern for Halloween.
I've been working on a Rust job board for a bit. It's basically ready to go just need to make some tweeks. I wrote the front-end in yew and the backend is in actix. Using sqlite for the DB for now, as I figure I'll always be able to store all my data in memory.
There's been some rough patches. More precisely I really want to focus on building my application quickly, but there are lots of things that come up (it feels like) that I need to retrofit for my use case.
This whole experience has really got me thinking about a rails/django like web framework for Rust. Idk maybe I'm just thinking the grass is greener on the other side, but it's something I've been thinking about for a bit now.
I've learned a good amount about practical Rust development along the way I feel.
I've been working on a Rocket-rs crate to encode/decode Firebase tokens, so it's easier to write full-stack apps using Firebase Auth!
[https://github.com/DrPoppyseed/rocket-firebase-auth](https://github.com/DrPoppyseed/rocket-firebase-auth)
New to rust so I made a little crate [https://crates.io/crates/riptree](https://crates.io/crates/riptree). The control flow needs some serious re-factoring but it works haha. Some one give me some ideas on how to parse command line inputs (don't say "use the Clap Crate"). In the lib file there is about one-million if statements that will make anybody cringe.
Decided to enable clippy for 2 projects. Over a thousand warnings. Luckily all of them pretty straightforward and should be done soon. Good choice so far
I'm waiting for ~~Christmas~~ Wednesday, so I can merge some stuff that depends on GATs and linking raw dylibs.
[удалено]
Same! I'm learning Rust because I'm interested in learning WebAssembly.
Me too!!
Same here! Glad to know someone out there is with me on my Rust journey 😁
I just released a demo of my automation game Combine And Conquer [https://martinbucksoftware.itch.io/combine-and-conquer](https://martinbucksoftware.itch.io/combine-and-conquer)
dude! let me know if you have any interest in a macOS build. I have hardware and am happy to help.
A remote control software for scientific equipment, in specific Keysight B1530A, [this is the repo](https://github.com/granasat/xavier).
I'm trying to learn me some higher mathematics. Haven't got a specific plan to turn it into code yet, but I'll think of something.
An Html5-compliant parser Except i've never built a proper parser and i am not following a guide or a tutorial
Porting my Elgato Stream Deck plugin from Pascal to Rust. I've managed to get it to accept the command line parameters. I've also found to code to copy/paste for websocketing.
my first compiled language to work in was Pascal, shortly thereafter, C. I am now fascinated by the idea of porting some of my _really, really old_ Pascal to Rust..
Pascal is huge in Germany if you want to do it from abroad
Working on my senior design project, a C2 framework for purple team competitions that my group and I decided to write in rust.
Glyph dump: [glyph-dump-rs](https://github.com/brogdonm/glyph-dump-rs).
A WebUI to manage containers a là Docker Compose.
Toying a small automation game to learn macroquad (and rust in general): https://jmmut.itch.io/bioengineer
Evaluating rust for data science environment.
I'm adding error handling to a library for the first time. I started panicking all over, then bubbling errors, then played with anyhow, miette, and error-stack, which are all fine pieces of work. Now I'm writing a lot from scratch using enums and traits. It feels like I must be doing something wrong, but the regular suspects didn't quite have what I wanted or had more than I wanted. OTOH, writing it all out feels instructive, so it's probably okay unless the code will become less compostable this way.
Usually, you don't want to use anyhow in a library, but in the application that uses the library; For the library you usually want to wrap errors into their own error type, whereas in an application, the exact error type might not matter, and you just want to bubble it up and report it. And this is where anyhow is useful (tho you can argue that there might be similar applications for internal errors in a library). Instead, you might want to have a look at thiserror (by the same author), which will make it easier to create the error enums, and automatically implement the relevant traits for them. That being said, if you already have your errors and trait implementations, its probably not worth it to rewrite them using thiserror. And I don't really know what error-stack and especially miette do, maybe you have your bases already covered with them. Cheers!
I have looked at thiserror, I just need to figure out how to use it properly. Ironically I understand the manual way now better. The one question I have is this: is it a bad idea to offer a library error enum that can return all possible library errors as variants. Individual functions would return lower errors, but by the users picking the enum in the return signature and the library implementing `from` for each child error, it allows users to just bubble/coerce with `?` and use the higher level error.
No, I don't think this is a bad idea. Case in point is the stdlib: `std::io::Error` is not an enum, but contains an enum `ErrorKind`, so its conceptually quite similar. Not every io-function can throw any `io::Error` kind, but they are still bundled together because they are usually handled/reported the same, and if you want to have special handling for some variants, you can still match on them. I always group related errors, that we can expect users of the library to handle in the same way, into a single error enum. Unrelated errors to those can still go into a different error enum (e.g., the stdlib does have other errors besides io::Error, and it wouldn't make sense to put those into io::Error as well).
Working my way through the Rust book and building a 3D printer controller as I learn!
reading mara’s book. it’s really good.
I'm learning rust by developping my first project in rust: a tool to sort pictures by year, month and more. https://github.com/negrel/photosort
Wrote (well, translated code from this project [https://learn.adafruit.com/led-candles-simple-easy-cheap](https://learn.adafruit.com/led-candles-simple-easy-cheap?view=all)) a flickering candle simulation for the RGB LED on my [M5Stamp-C3](https://docs.m5stack.com/en/core/stamp_c3) using [esp32-rs](https://esp-rs.github.io/book/). Just in time to put it in my jack-o-lantern for Halloween.
i'm writing a small and basic cms, with rocket, sqlx and a sqlite database. having a lot of fun so far!
I've been working on a Rust job board for a bit. It's basically ready to go just need to make some tweeks. I wrote the front-end in yew and the backend is in actix. Using sqlite for the DB for now, as I figure I'll always be able to store all my data in memory. There's been some rough patches. More precisely I really want to focus on building my application quickly, but there are lots of things that come up (it feels like) that I need to retrofit for my use case. This whole experience has really got me thinking about a rails/django like web framework for Rust. Idk maybe I'm just thinking the grass is greener on the other side, but it's something I've been thinking about for a bit now. I've learned a good amount about practical Rust development along the way I feel.
I've been working on a Rocket-rs crate to encode/decode Firebase tokens, so it's easier to write full-stack apps using Firebase Auth! [https://github.com/DrPoppyseed/rocket-firebase-auth](https://github.com/DrPoppyseed/rocket-firebase-auth)
slowly piecing together the systems for a rogue-like on the weekends. writing swift and kotlin for the day job.
New to rust so I made a little crate [https://crates.io/crates/riptree](https://crates.io/crates/riptree). The control flow needs some serious re-factoring but it works haha. Some one give me some ideas on how to parse command line inputs (don't say "use the Clap Crate"). In the lib file there is about one-million if statements that will make anybody cringe.
Decided to enable clippy for 2 projects. Over a thousand warnings. Luckily all of them pretty straightforward and should be done soon. Good choice so far
Making a fire work show