> I also stated reasonings on why the interface_c name was a OK choice under > that the context of C, because C is a language that is mostly used for > embedded space -- rust do not have that same profile, as a result when we do > the development we need to consider it under the new context of rust along > with the need of proposed targets. > > Under the context of rust , it is helpful to clarify the intend because > rust's most common use is not only embedded language and do not come with > name spacing. Rust also come with dynamic memory management, reference > counting along with other things that makes other API style possible and > perhaps more primarily used under non-embedded settings.
C is used for a variety of use-cases and is foundational to much of the software used in larger systems (not only embedded), it includes dynamic memory management and reference counting - Python itself would not exist if C wasn't capable of this. The choices in the embedded C API make it better for environments where dynamic allocation isn't favored and with a subset of the C standard library, which is similar to `no_std` in Rust - they are targeted at the same subset. > As a result a clear naming, like interface_embedded_rust would be a clear way > to signal the intent. I also do not see any inconsistency applying such > organization might bought. > When looking at the consistency of the codebase. We consider the architecture > in a wholistic way. > Instead we say give a proper naming and organization considering so it have > clarity under the context it is in. That is overall better for the wholistic > architecture and consistency in the codebase. Naming it `interface_embedded_rust`, is clearly inconsistent with `interface_c` which serves the same audience, as documented above we're using a subset of both languages in similar ways. I'm actively encouraging you to take a holistic approach and consider that both the C and Rust APIs are both designed as resource constrained variants of the broader languages. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/96#issuecomment-1373696783 You are receiving this because you are subscribed to this thread. Message ID: <apache/tvm-rfcs/pull/96/c1373696...@github.com>
