livingcoder

joined 2 years ago
[–] livingcoder 28 points 2 weeks ago (1 children)

This was a great blog post. I love Rust and Bevy, but I can definitely see why you made the switch.

The primary issue with your decision to use Rust/Bevy, for me, was that you were taking on the task of getting others to work in a difficult language for novice developers. I would never suggest Rust as someone's first language, coupling that with a regularly-changing library like Bevy.

I would love to know what the pros and cons were between Unity and Godot. If you were going to switch to C# anyway, Godot seems like the next logic choice to me, so I'm curious about what your team's evaluation was for that engine.

[–] livingcoder 4 points 1 month ago

I leave mine in the trunk and have only walked into the store without them twice. Not forgetting them before walking into the store and putting them back into the trunk after unloading them is the hardest part.

[–] livingcoder 3 points 1 month ago

Exactly. The functions of the super trait are also required when implementing the child trait's functions, as you would expect from inheritance.

[–] livingcoder 3 points 1 month ago* (last edited 1 month ago) (2 children)

Basically, you can generalize your trait types into their parent (super) traits for situations when functionality is specific to those supertrait objects.

As an example, if you have a trait CanBark and it is a super trait for the trait IsDog, you can coerce your references of &dyn IsDog into a &dyn CanBark. You can then work with other trait types that share a super trait.

trait CanBark {
    fn bark(&self);
}
trait IsSeal: CanBark { }
trait IsDog: CanBark { }

fn bark_as_group(barkers: &Vec<&dyn CanBark>) {
    for barker in barkers {
        barker.bark();
    }
}

let spot: &dyn IsDog = get_spot();
let seal: &dyn IsSeal = get_seal();
let barkers: Vec<&dyn CanBark> = Vec::new();
barkers.push(spot);  // coerced
barkers.push(seal);  // coerced
bark_as_group(&barkers);

At least, I hope this is possible now. If it's purely "you can return a coerced type from a function", that is less useful.

[–] livingcoder 4 points 1 month ago

I think this prediction will age extremely well if we last that long. That's a very big "if".

[–] livingcoder 15 points 1 month ago* (last edited 1 month ago) (4 children)

Wow, that trait feature is great. I've been eagerly waiting for that one for a long time. Thank you to everyone who made that possible.

[–] livingcoder 31 points 1 month ago

When I learned Python I thought that not having a statically typed language was the way to go, but then it just became an issue when I was trying to ensure that everything was at least something like what I was expecting. Going back to statically typed languages even harder with Rust has been a dream. I love it.

[–] livingcoder 1 points 1 month ago* (last edited 1 month ago)

I kept most of my bindings the same as the normal QWERTY keyboard, so I don't have much of an issue swapping between them. I had debated a lot about changing to other keyboard layouts and I'm really glad that I didn't.

[–] livingcoder 6 points 1 month ago (2 children)

I love my Moonlander. I'll never go back.

[–] livingcoder 2 points 1 month ago

I've found that one of the best things to do when making a library for something that is going to have a web interface is to first have it work in the terminal. You can much more quickly play around with the design and fix issues there instead of having to work with a more complex web interface.

You just create a simple menu system, like input("1: Feature A\n2: Feature B\n>") and just start trying out all of the different scenarios and workflows.

[–] livingcoder 4 points 1 month ago* (last edited 1 month ago)

I had a coworker who would sometimes not create a method as being static to the class and would therefore need to create a default instance to call said method. "It's domain-driven design."

[–] livingcoder 6 points 1 month ago

The price and quality are so hard to beat.

view more: next ›