New week, new Rust! What are you folks up to?
I'm getting back to work on typed-ident this week (excited to be done with last week's webdev stuff, I suck at webdev)!
Also, I wasn't sure if I should post my technical article here on the Rust user forums or not. It's an introduction to declarative macros, which maybe feels a tad basic for such an audience?
But I might give it a shot anyways when I publish it in a few minutes here. Maybe some Rust newcomers would find it helpful.
EDIT: If anyone is curious to see what I added to my website. I added the ability to add projects, and announce updates on them (example). I also added auto-generated table of contents for articles, which I hope will help make them easier to explore.
I am working on a project that I started in 2021, at a time when artificial intelligence was not yet democratized.
It's called Octopux, at the time it was called Actix-restful.
The library relies on the features of procedural macros in the background to generate Json REST/GraphQL input point code.
The goal was to get closer to RESTFul api services that exist in languages such as Java, Scala, F# or others that I forget, but in Rust.
In today's era where artificial intelligence is democratized, where tools such as claude code or codex write code better and faster than developers, the question arises as to whether this library has a place in the Rust ecosystem.
I wanted a light, easy-to-use library.
Hi syprex,
this indeed is a good question.
What I often hear is that good developers are still needed - on one hand to state precisely how a software shall work and on the other hand to review the generated code.
My personal feeling is that AI generated code is not a solution to overcome complexity (which then stops your project development and maintenance, complexity eats up your development capacity) it is rather the contrary: It is accelerating the speed by which you run into the complexity situation where then also an AI cannot help you out. (maybe...)
To not run into complexity hell, one may consider
- SOLID principle
- Simplicity principle
- Loose Coupling principle
- Information Hiding principle
- Least Astonishment principle
- Strong Cohesion principle
- automated Tests concept
- Declare all interfaces principle
- Domain Driven Design principle
and maybe we are back at good modularization and well-defined APIs which will still be needed in the future. I understood that your project is about well-defined APIs?
cu
Andi
Yes, in a way.
This does not prevent you from writing server methods to transform/arrange the data that makes the life of a web service.
From my point of view, the reasons that led me to create this project are that it can serve as a basis for an API.
I'm working on falconf, a "simple distro-agnostic personal configuration and setup manager" (Dotfiles syncer meets Ansible? Nix for lazy people? Coming up with a good non-vague description/tagline is hard)
I recently added gsettings/dconf support (to manage the settings you would usually change in the GUI) and started seriously using it myself for the first time, setting up a fresh Linux installation as automated as possible. Of course starting to actually use it immediately showed me a bunch of shortcomings, which I'm now working on fixing.
I made a newtype!
#[derive(Clone, Debug, PartialOrd, PartialEq)]
pub struct TextUid(String);
impl TryFrom<&Path> for TextUid {
type Error = Error;
fn try_from(path: &Path) -> Result<TextUid, Error> {
let stem_str = path
.file_stem()
.context("Bad file stem")?
.to_str()
.context("Bad string")?
.to_string();
let uid = stem_str
.split('_')
.next()
.context("Failed to extract text UID from filename.")?;
Ok(TextUid(uid.to_string()))
}
}
impl AsRef<str> for TextUid {
fn as_ref(&self) -> &str {
&self.0
}
}
No big deal, but another small step in my Rust learnings.