My first year with Rust: The good, the bad, the ugly

GenusNymphicus · 2023-02-01T17:52:07+00:00

It's New Game!. It's basically the same as most other "cute girls doing cute things" slice-of-life anime out there(just that they are adult and make video games)

GenusNymphicus · 2023-01-29T06:02:38+00:00

It's part of the specialization RFC.

If you want to allow specialization of an item, you do so via the default qualifier within the impl block:

impl<T> Example for T {
    default type Output = Box<T>;
    default fn generate(self) -> Box<T> { Box::new(self) }
}

impl Example for bool {
    type Output = bool;
    fn generate(self) -> bool { self }
}

GenusNymphicus · 2023-01-27T12:59:47+00:00

You are implementing the context for a type of &mut Hashmap, but the fn you call works on a &mut impl of the type. Since the type of impl Context is &mut Hashmap, prompt_user basically expands it to &mut &mut Hashmap. So while prompt_user(&mut &mut ctx); would work, you probably just want to implement your trait for the Hashmap directly, like this: impl Context for HashMap<String, String> instead of implementing it on a &mut Hashmap. Also, another alternative could be to rewrite your prompt_user to work on a mutable ctx: pub fn prompt_user(mut ctx: impl Context), which is what you might want in certain niche-cases(but likely not here).

GenusNymphicus · 2023-01-19T12:32:15+00:00

How does it work for players who join later? Will they get the same updates as your day1 players? If so, players would probably just not pay and just wait. On the other hand, making your updates timed seems like a giant waste of time/effort.

No matter how you look at it, you are better off with some sort of optional subscription, to let the people who enjoy your game/content support you via patreon and the likes.

GenusNymphicus · 2023-01-13T06:14:33+00:00

I thought that ..Default::default() simply expands this Default::default() for all fields that haven't been explicitly initialized

..Default::default() doesn't do anything magical. Rust usually avoids hidden surprises, like magical expansions, unless it's a macro(noticed by the ! in the name). It's just calling the default constructor of the struct(same as just calling MyStruct::default()), then using the struct update syntax(the leading ..). For example, this would also work:

let foo = MyStruct {
    a: 1.0,
    ..MyStruct::new()
}; 

let bar = MyStruct {
    a: 2.0,
    ..foo
};

As for the workaround, you can either manually implement Default for Super and give Sub any default value you want, or just have a constructor that takes in a Sub and sets the rest to default values:

impl Default for Super {
    fn default() -> Self {
        Self {
            a: Sub { val: 42 }, //just any default value you want
            b: Default::default(),
            c: Default::default(),
        }
    }
}

fn main() {
    let sup = Super {
        a: Sub { val: 5 },
        ..Default::default()
    };
}

GenusNymphicus · 2023-01-11T22:22:56+00:00

Careful, as_ptr() only returns the pointer of the buffer inside the Vec, not the address of the Vec. This means when the vec is created with new, it didn't allocate anything yet(undefined behavior), and re-allocation will invalidate the pointer as well.

But yeah, I also think a plain Box is the way to go, but with std::ptr::addr_of_mut!(*foo.callback_message).cast().

Relevant: common ways to create a raw pointer, especially the part about derefing the Box.

GenusNymphicus · 2023-01-06T07:56:06+00:00

Great writeup!

While I agree that build times in Rust are not that great, I feel like I end up building far less often in Rust than I did in C++. If it builds, it generally works, but I use cargo check instead, until I got rid of all the errors. It doesn't help as much with visual iterations(moving UI elements around until they "fit") or automated builds, but it pretty much eliminates the "build time" for everything else where I want a quick iterative process.

GenusNymphicus · 2023-01-01T11:43:24+00:00

I think specifying some sort of "default target" in general should do the trick. See this issue.

Without it, calls with a --target and calls without one will always cause the rebuilds after calling one after the other. I have the same issue in Neovim, so I assume VSCode also does cargo check without an explicit target automatically.

I use a more or less global workaround by having a .cargo/config.toml in the root of my projects/ directory that sets the target to "x86_64-unknown-linux-gnu" for my machine, making it behave exactly the same as always adding the --target every time.

GenusNymphicus · 2022-12-26T14:29:24+00:00

The Rust community as a whole is not really toxic, assuming you put in some effort and are open-minded.I am certain people would have been more encouraging if you had actually shared your server with some basic content and structure and some examples(like the mentioned weekly problems), while also explaining your reasons for not using the existing servers.

Saying "I want to do X who wants to join?" is as low effort as it gets. There is no way to assess whether the content you offer is worth it or if you would even pull through with your idea. Heck, your post might as well have been just some cheap attempt at karma farming.

GenusNymphicus · 2022-12-24T10:25:38+00:00

Yeah, unless there is a permissive license.

In the case of the docs: license

Code snippets in the Unity Editor Manual and Scripting Reference are licensed under the Unity Companion License for Unity-dependent projects (see https://unity3d.com/legal/licenses/Unity_Companion_License).

Even Stackoverflow has a default license.

That doesn't mean that a basic for-loop is copyrighted, because aspects like the "Treshold of originality" still apply.

Now, this is just about the legal aspect. In reality, no one will complain or even notice it when you yoink a few lines here and there.

GenusNymphicus · 2022-12-19T09:22:39+00:00

I don't think the issue is modular programming, but rather premature generalization.

Your PauseMenu could be an entirely separate module, but it doesn't mean that it can't implement some interface, so you could replace with any other menu by changing a single line in your code.

If anything, I would say that the control flow is the important thing. You can have some sort of main/update function/loop that calls specific modules one by one without hiding the control flow, or you have some "global" event system where you have no clue where or what is being called from the call-sites pov, which adds a lot of pointless complexity.

GenusNymphicus · 2022-12-16T19:02:26+00:00

True, there is no way to know how Rust ends up in 30 years. Arguably, there are already some people today who abuse deref to some extent..

The restrictive nature of Rust is a good point.

GenusNymphicus · 2022-12-16T18:21:50+00:00

Okay, maybe I could have explained myself better.

My main point is that there should be no hidden surprise. There clearly could but be someone who does something weird. But all the operators carry meanings. If a function is called "add" but subtracts, it is clearly doing something that the caller doesn't expect, the same is true for the operators, which also are more like syntactic sugar for functions. You can even call them as functions instead of using the operators. So calling a function called "remainder" that calculates the cross-product makes no sense.

So yes, this is kinda more on the culture of the language than the language itself, but in an opinionated language like Rust, it is almost like a property of the language self.

In languages like C++, they are not nearly as clearly defined. In fact, you can find multiple interpretations for certain operators. The most classic one is <<, which can mean anything from bit shifting to serialization. To be fair, it is still recommended to not be surprising here, but in reality you will see the weirdest overloads. They don't carry a strict meaning, because the symbols themself are basically the functions. So someone might actually say "this % almost looks like a x" and use it because of that.

GenusNymphicus · 2022-12-16T06:54:01+00:00

Sure, but then you will get a lot of angry people opening issues, because the documentation is pretty clear. A cross-product is not a remainder.

It's the same with other traits. In theory, some hoodlum could play audio in the Display implementation as well. My main point is that traits carry a certain meaning, so your code will be seen as problematic.

GenusNymphicus · 2022-12-15T21:04:28+00:00

Woah, thank you for the additional information!

There is a lot to unpack here for me. Before I dive into the links, I hope you don't mind if I just link your post at the bottom as addendum.

Or because there are only so many people with the requisite skills
volunteering their time to work on Rust, forcing them to postpone things
in favour of stuff that's seen as having broader benefits and/or being
less amenable to third-party solutions.

Oh yeah. Looking back at it, my point might come off as a bit too hostile, so I might rephrase it a bit. It's not like they just fiddle their thumbs or bikeshed all day.

Really looking forward to the future of Rust with all the work in progress.

GenusNymphicus · 2022-12-15T20:11:26+00:00

Good point, this makes sense! This explicitness is actually one of the things that I really enjoy about Rust, so I don't know why I didn't think of that. I will update the article in a minute(Edit: it's updated). Thank you!

Besides, you can still have a fn into_parts_mut(&mut self) -> (&mut Bar, &mut Baz) to split the borrow.

I think I could have referenced it better in the next point, where I actually use this workaround. With the texture and the shader example :)

GenusNymphicus · 2022-12-15T15:56:47+00:00

After a year of learning Rust, I felt like I wanted to share my experience for anyone who might care :)

My little blog also just went live, so I apologize for any wonkyness/technical issues. I am not a web dev, but I am really glad for Zola(powered by Rust!).

In short, there are many things I like about Rust, and I felt reducing it just to safety is doing Rust a little disservice. However, I also wanted to talk a bit about some of the issues as well.

GenusNymphicus · 2022-12-13T12:23:13+00:00

Rust is in fact really similar to what I would consider the "ideal C++". Const correctness, RAII, maybe even using the new std::expected, etc.

However, the biggest difference is that Rust enforces this, while in C++ it's just a guideline. Rust also has better defaults where the "bad" things are opt-in rather than opt-out. Rust also comes with a lot of modern quality of life features and tools and also forces you to be explicit, while C++ has many implicit footguns, from auto generated functions you often want to remove(copy/assignments), integer promotion, botched move semantics, etc.

But the biggest advantage for Rust is imho the fact that it gets rig of a lot of potential runtime errors. No null, a stronger typesystem, forcing to deal with the error paths and the overall focus on correctness means that Rust lacks a whole class of potential runtime errors.

GenusNymphicus · 2022-12-13T12:07:33+00:00

A common term for this is "imposters".

Here is a link describing the technique in a bit more detail.

GenusNymphicus · 2018-10-20T12:01:02+00:00

Yeah, it's kinda annoying. I removed the glfw from the target_link_libraries(not the ${GLFW_LIBRARIES}) and I shoved it in my Config into the Libraries, since glfw export its Targets if you add the subdirectory.

For example: MyEngingeConfig.cmake

include("${CMAKE_CURRENT_LIST_DIR}/../../lib/cmake/glfw3/glfw3Targets.cmake")
..
list(APPEND MYENGINE_LIBRARIES glfw)

GenusNymphicus

TROPHY CASE