this post was submitted on 24 Mar 2024
26 points (96.4% liked)

Rust

5930 readers
35 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

[email protected]

Credits

  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago
MODERATORS
 

Hi rustaceans! What are you working on this week? Did you discover something new, you want to share?

top 5 comments
sorted by: hot top controversial new old
[–] [email protected] 18 points 7 months ago* (last edited 7 months ago)

Trying to build Lemmy entirely from a flake for my rolling fork. I’m a big Nix fanboi so I figured the first project in my fork would be to get it running like I did with my Haskell/Purescript projects that use nix and flakes for EVERYTHING.

edit: anyone out there have any pointers?

[–] [email protected] 9 points 7 months ago* (last edited 7 months ago) (1 children)

I've started building a wordle-analyzer. I got nerdsniped, and now I'm implementing the game (already did a game and a cli implementation using the abstracted interface) and a solver.

The idea is to provide:

  • game - a wordle game that can be used to implement the game in many frontends, a cli version and exists already
  • solver - something that can solve the game
  • wordlist - any wordlist people might want.
  • bench - if you want to know how good your solver is

I'm providing built-in versions, but anyone could implement the traits.

I currently have two solver implementations;

  • stupid - literally tries words at random
  • naive - checks which letters matched and reuse them, require letters that are included but not matched in other words, then use the most common word that matches

The naive solver can actually solve the game in less then 10 steps most of the time. Mathematically, the optimum is about 3,4 steps. There are two amazing 3blue1brown videos going into details, and my eventual goal is implementing solvers making use of that math.

I've been using generics and traits like never before for that project. Solver? It's a trait. Game? It's a trait. Word lists? It's a trait.

And all my structs have generics <'wl, WL> so that I only need to have the word list once to save resources. You get a little crazy from the lifetime errors but it's fun.

Besides that, my homeserver got janky this month, and today I started migrating it to proxmox. It's hard, because I need to do a lot more thinking than just docker go brr now.

In case you want to check my wordle-analyzer out: https://git.cscherr.de/PlexSheep/wordle-analyzer I need to update the readme before publishing.

[–] tinkralge 2 points 7 months ago (1 children)

That sounds like fun! Wow. How stable is it at the moment?

[–] [email protected] 3 points 7 months ago

Not very stable at all, but the cli game (wordlec) is playable with the responses of whether you hit a letter or not, the naive solver and the stupid solver work too.

However, I expect that the API will change a lot before v0.1. I will release it when I deem it somewhat stable. Happy to hear you like it.

[–] tinkralge 3 points 7 months ago

Working on some form of inheritance in rust. It's my first foray into procedural macros and so far it's fun. The idea is quite simple: generate structs with common attributes (and eventually functions) instead writing them yourself.

use inheriters::specialisations;

specialisations!(
    struct Parent {
        attr1: u8,
    }
    #[inherit(Child)]
    struct Child {
        attr2: u8,
    }
);

becomes

struct Parent {
    attr1: u8,
}
struct Child {
    attr1: u8,
    attr2: u8,
}

not

struct Parent {
    attr1: u8,
}
struct Child {
    attr1: u8,
    parent: Parent,
}

The latter leads to indirection which I'm not a fan of.

Last week I squashed one bug on the order of attributes according to inheritance. In the example above attr2 was coming before attr1. A feature is nearly done to exclude the Parent from the output and only output the child. That's useful for parents that just serve as holders for shared attributes.

The goal for v1 was to also support basic inheritance of implementations: Parent has an impl block, then that block is copied for the Child. Not sure yet if I'll implement overrides in v1 or v2. Overrides being if Parent implements do_something() and Child does too, then the implementation of Parent is not copied into the impl block.
That's what I'll try to tackle in the coming weeks.