3 ms·

I've been writing Rust for some time and I think that people overuse closures. I've been looking at a lot of GUI framework implementations and a lot of them use

I've been writing Rust for some time and I think that people overuse closures. I've been looking at a lot of GUI framework implementations and a lot of them use closures for event handling. I think that the ECS (https://en.wikipedia.org/wiki/Entity_component_system https://en.wikipedia.org/wiki/Entity_component_system) paradigm is a much better match. I've been working on an GPU-first, ECS based GUI framework for my app (http://ngrid.io http://ngrid.io) and couldn't be happier. I might open source parts of it. The code ends up being really short and and uses little memory. A browser might have multiple representations of a DOM node in memory (the pipeline from DOM to GPU is really long). I have like one. I realize this is only tangentially related.

kvark 6y ago
Also seeing closures as a universal instrument to many cases, often overused. Problem with them is disrupted control flow and implicit capturing of the context. However, in cases where you have to guarantee something to happen after user code, the RAII guards can't replace the closures, because drop() isn't guaranteed to be called even in safe code... The ECS GUI integration is an interesting direction. I think Rust ecosystem looked at it, and it was hard.
- adamnemecek 6y ago
  Yeah capturing context is bad. I think that we need more time to explore this. It took the OOP GUI frameworks a long time to mature.
- ChrisSD 6y ago
  See also: Document when we do guarantee that drop runs[0] [0]: https://github.com/rust-lang/nomicon/issues/135 https://github.com/rust-lang/nomicon/issues/135
ComputerGuru 6y ago
The Orb rust GUI library developed for RedoxOS is based on ECS.
- adamnemecek 6y ago
  I looked at it and I really dislike some decisions they made. I had a hard time understanding how to write it and IIRC they don't have GPU integration. Also I find code like this to be anti-ECS https://docs.rs/orbtk-api/0.3.1-alpha2/src/orbtk_api/macros.rs.html#41 https://docs.rs/orbtk-api/0.3.1-alpha2/src/orbtk_api/macros..... They use macros as a workaround for lack of inheritance in Rust. I would not call that ECS.
amelius 6y ago
I just followed your link to the ECS Wikipedia page, and it seems to me that ECS is a very dynamic way of creating objects and defining their behavior, almost like how you can assign functions to objects in JavaScript without defining them in a class. Doesn't this conflict with the more formal approach of using a strong type system?
- arc-in-space 6y ago
  This feels hard to answer, and I feel like you're making some fundamental category error. Having a type system doesn't mean "don't do suspiciously-dynamic-sounding things", it means "don't accidentally mix up data with incompatible structure". Rust, C++, Haskell, etc. are all perfectly happy with polymorphism, and a typical ECS certainly is well-typed. It's just another way of doing mixins.
  - twic 6y ago
    It arguably conflicts a bit, because in an ECS, you can have notions of, say, Movable and Damageable, but there's no way to write a function applies to things which are both Movable and Damageable, right? The closest you could get would be a function which takes both a Movable and a Damageable, and has to trust that they correspond to the same entity.
    - adamnemecek 6y ago
      No actually, you query both and as you iterate through the results, the current element is one that has both. Look at some examples of the Rust ECS framework specs.
- orthoxerox 6y ago
  The primary goal of ECS is arranging data in a more CPU-friendly way. The secondary goal is avoiding hardcoding the behavior of your model into a type hierarchy. As a comparison, imagine your bank's lending products. You probably don't want to hardcode them into a type hierarchy with a virtual method AccrueInterest(Date), but rather have flags that indicate which loans accrue daily, which loans accrue monthly, which loans have some secondary interest etc.
mamcx 6y ago
Now the question is how use ECS for build a query/stream?

kvark 6y ago

Also seeing closures as a universal instrument to many cases, often overused. Problem with them is disrupted control flow and implicit capturing of the context. However, in cases where you have to guarantee something to happen after user code, the RAII guards can't replace the closures, because drop() isn't guaranteed to be called even in safe code... The ECS GUI integration is an interesting direction. I think Rust ecosystem looked at it, and it was hard.

adamnemecek 6y ago
Yeah capturing context is bad. I think that we need more time to explore this. It took the OOP GUI frameworks a long time to mature.
ChrisSD 6y ago
See also: Document when we do guarantee that drop runs[0] [0]: https://github.com/rust-lang/nomicon/issues/135 https://github.com/rust-lang/nomicon/issues/135

ComputerGuru 6y ago

The Orb rust GUI library developed for RedoxOS is based on ECS.

adamnemecek 6y ago
I looked at it and I really dislike some decisions they made. I had a hard time understanding how to write it and IIRC they don't have GPU integration. Also I find code like this to be anti-ECS https://docs.rs/orbtk-api/0.3.1-alpha2/src/orbtk_api/macros.rs.html#41 https://docs.rs/orbtk-api/0.3.1-alpha2/src/orbtk_api/macros..... They use macros as a workaround for lack of inheritance in Rust. I would not call that ECS.

amelius 6y ago

I just followed your link to the ECS Wikipedia page, and it seems to me that ECS is a very dynamic way of creating objects and defining their behavior, almost like how you can assign functions to objects in JavaScript without defining them in a class. Doesn't this conflict with the more formal approach of using a strong type system?

arc-in-space 6y ago
This feels hard to answer, and I feel like you're making some fundamental category error. Having a type system doesn't mean "don't do suspiciously-dynamic-sounding things", it means "don't accidentally mix up data with incompatible structure". Rust, C++, Haskell, etc. are all perfectly happy with polymorphism, and a typical ECS certainly is well-typed. It's just another way of doing mixins.
- twic 6y ago
  It arguably conflicts a bit, because in an ECS, you can have notions of, say, Movable and Damageable, but there's no way to write a function applies to things which are both Movable and Damageable, right? The closest you could get would be a function which takes both a Movable and a Damageable, and has to trust that they correspond to the same entity.
  - adamnemecek 6y ago
    No actually, you query both and as you iterate through the results, the current element is one that has both. Look at some examples of the Rust ECS framework specs.
orthoxerox 6y ago
The primary goal of ECS is arranging data in a more CPU-friendly way. The secondary goal is avoiding hardcoding the behavior of your model into a type hierarchy. As a comparison, imagine your bank's lending products. You probably don't want to hardcode them into a type hierarchy with a virtual method AccrueInterest(Date), but rather have flags that indicate which loans accrue daily, which loans accrue monthly, which loans have some secondary interest etc.

mamcx 6y ago

Now the question is how use ECS for build a query/stream?