Hacker News Reader

> stack and heap as with C# structs and classes

Nitpick: C# struct can be on the heap (when it's "boxed").

The fundamental difference between C# class and struct is how they treat assignment operation. The class has "reference semantics" (assignment creates a new reference to the same object) and struct has "value semantics" (assignment creates a new object).

C# uses terms "reference types" (of which "class" is one) and "value types" (of which "struct" is one) to make the difference clear.

Structs being on the stack (most of the time) is just a consequence of their value semantics, and should be treated mostly as an implementation detail.

I’m aware of the differences between structs and classes, boxing etc. (.net dev since ‘02), . My point is “class” can some times be a faceless “value” with no identity, and some times have an identity. The “records” feature is a way of addressing this difference, but like everything else it’s tacked on a bit late. A value class, like a value type (struct, enum), should/could be immutable, have structural equality etc.

I’d like my language to be extremely explicit about whether an object has identity or not. It ties into things like ownership, move vs. copy, disposal etc too.

I think you misunderstand the ECS pattern. You want:

    class DrawSystem{
        Draw(DrawComponent)
    }

With some mapping of DrawComponent to MyEntity. That mapping would most likely NOT be in the MyEntity class definition.

Or you can put the DrawComponents on the Draw system and simply track mapping back to the MyEntity instance they correspond to. New code lives in the systems.

In a game you'd have some kind of scene system that could track what entity has what components and then you don't even need a MyEntity class at all. You wouldn't track that composition in a class.

The sugar that Rust is bringing is that it feels like the implementation is being added to the instance instead of an external system outside it, but you can make that work in C# with some extension methods. It would be nicer if/when C# gets extension interfaces.

Thats exactly how I understand an EC system but my issue with it is the overly soft coupling with just ids.

I guess you want to know that every MyEntity can be drawn and can move so you don't have to try-get the component.

The disconnect I think is that part of the ECS design is that you have the freedom to break that guarantee. Entities are no longer types but collections of components. The soft coupling is the goal.

Yes exactly, I think it’s an elegant system for some contexts but I wouldn’t want every system to be forced to use it, so I wouldn’t want that ECS design to be a fundamental part of the language. Soft coupling is basically just giving up typing at some interface and relying on soft information. Which can be fine, but not always.

I wonder if you could implement this all within a linter on top of Rust or some other language? Some of your asks already exist at that level (for example, TypeScript autocomplete in VS Code knows which enums you haven’t checked in a switch, and it also knows if a property has been verified that you’ve narrowed via a type union, so perhaps you could extend this to enforce coverage of switch statements?

The Rust compiler already enforces that you match all variants of an enum. And Rust Enum is basically a C union with an integer tag.

I've only briefly looked at Rust. How would you handle your Drawable if it needs to store some extra data?

Few of the things I use inheritance or composition for can be implemented without storing some extra data.

As an example, say a buffered Stream, that takes a Stream instance and adds buffered access. This BufferedStream would need to store the buffer data somewhere.

Rust has BufWriter/BufReader and I'm not an expert but I think you'd just view it as extension through composition

That does indeed seem[1] to do regular, naive as per OP, composition.

I was just curious what OP was using these traits for, as in my non-Rust experience seldom have the need to compose stuff without storing additional data.

[1]: https://doc.rust-lang.org/src/std/io/buffered/bufwriter.rs.h...

Drawable is just a trait, a definition of methods that can be abstracted over. If you wanted to store data, you'd do it in the type that Drawable is actually being implemented for, i.e. MyEntity.

    struct MyEntity {
        cache: RenderingCache,
    }
    impl Drawable for MyEntity {
        fn draw(&self, canvas: &mut Canvas) {
            self.cache.draw_cached(canvas, |cache_canvas| {
                cache_canvas.render(ASSET);
            });
        }
    }
    const ASSET: Asset = load_asset("foo.png");

Thanks, that is very clear.

Think Rust differs enough that it's a bit hard for me to draw direct comparisons with my primary languages, but with the emphasis on interfaces like that it does seem like a nicer way to implement extension methods.

Here is some nuance with Rust's OOP relative to java/go/c++: https://stevedonovan.github.io/rust-gentle-intro/object-orie...

If you know haskell, Rust's traits are very similar to type classes, except it also has c++-like generics (templates) and is primarily expression-based like ocaml.

traits vs haskell type classes:

trait -> class struct -> data instance -> impl

If you are used to Java: It's like making a class implementing an additional interface from the outside.

    class MyEntity {
      RenderingCache cache;
    }

    now MyEntity implements Drawable {
      void draw(Canvas canvas) {
        this.cache.draw_cached(canvas ...);
      }
    }

> I love how rust does interfaces (traits) and allows implementing outside the type.

Then it might be interesting for you that Rust copied this (like a few other things) from Haskell, where they are (somewhat confusingly) called type classes.

> i'd make sure to make it almost not OO at all.

I think you mean "class oriented"

Never heard the term, but that could be what it is.