<p>In my <a href="https://langdev.stackexchange.com/a/2120/1270">answer</a> to the question <em>What are the advantages and disadvantages of making types as a first class value?</em>, I point out that for the language I'm working on, I wanted to have the ability to do runtime checks on the type, because from my experience it is quite limiting/restrictive/cumbersome to only allow compile-time checks on the type, and it is really easy to understand and use type reflection and that sort of stuff (accessing type metadata at runtime, basically).</p>
<p>But as I point out there, for my case I am compiling my lang to JavaScript. If I include the 5000+ built-in types that exist for native JS classes/etc., that is roughly 1.5 megabytes of type metadata that would extremely bloat the output JS build file. So how can I reconcile this problem?</p>
<ol>
<li>I could not allow type reflection or metadata access at all.</li>
<li>I could omit some type metadata in some cases (like props/fields), where they are never accessed at runtime (would cut out a lot). This would be hard to implement but possible.</li>
<li>Any other solutions you can think of?</li>
</ol>
<p>The fundamental underlying question is, <strong>do you really <em>need</em> type reflection?</strong> Can you build programming languages without it, and be able to do all your type checks and implement things in a nice and easy way (with no mentally burdening workarounds, like you often have in Rust as far as I've seen)? The surface level question though is, given I would like some sort of type reflection, <em>or something that accomplishes a similar set of functionality possibilities</em>, what are my options?</p>
<p>I added runtime type checks and the ability to do <code>obj.type.fields.forEach</code> because I want to build validations (like checking if a string matches the <code>email</code> type regex, etc.), and other things like documentation. But for docs (printing the type fields, for example), I guess that would be a different use case where I deal with the compiler-level AST instead of the &quot;runtime AST&quot;? But even then I can imagine a case where you are debugging runtime code, and want to inspect the type metadata/fields, so perhaps there is a &quot;dev build&quot;, that would solve that. But maybe there are other cases where you still really need reflection (can't think of any off the top of my head)? Such as building an app which runs code and shows you a log of the objects that pass through it or something (the types, which it would have to access at runtime in order to log)?</p>
<p>Anyway, wondering how I can accomplish the <em>functionality</em> goal of having type reflection, without adding the bloat? I'm not sure if I need to cut out type reflection altogether, in which case I'd like to know how you can handle the cases/needs of dynamic type checking.</p>

<types><dynamic-typing><runtime>
How to avoid output build bloat when wanting to access type metadata information at runtime?
CC BY-SA 4.0
2023-07-06T19:33:01.940Z
Swift just doesn't bother, so a statically-linked Hello World is six megabytes.
Bbrk24
CC BY-SA 4.0
2023-07-06T19:47:38.733Z
@Bbrk24 Interesting, that's a good insight to keep in mind! Could Swift accomplish what it wants to accomplish without dynamic typechecking then (it sounds like Swift has dynamic type checking, I'm not familiar though), and ultimately cut out all the types from the build?
Lance Pollard
CC BY-SA 4.0
2023-07-06T19:53:32.297Z
Swift is mostly statically typed, but it has `Any`. You can query whether an instance of `Any` adopts a certain protocol, and grab its vtable if it does (or get `nil` if not). Even without reflection -- which does exist, to a limited extent -- you need type metadata to be able to do that.
Bbrk24
<p>In the <a href="https://github.com/tunebond/base.link" rel="nofollow noreferrer">language</a> I'm working on, you can define a &quot;class&quot; or &quot;type&quot; like this:</p>
<pre><code>form user
  link email, like text
  link name, like text
</code></pre>
<p>Say I wanted to make it &quot;insertable&quot; into a SQL database. Then I can do like Rust's <a href="https://diesel.rs/guides/getting-started.html" rel="nofollow noreferrer">diesel</a> crate, where they have:</p>
<pre><code>#[derive(Insertable)]
#[diesel(table_name = posts)]
pub struct NewPost&lt;'a&gt; {
    pub title: &amp;'a str,
    pub body: &amp;'a str,
}
</code></pre>
<p>Well I just learned <a href="https://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/share/doc/rust/html/book/first-edition/procedural-macros.html" rel="nofollow noreferrer">what Rust's <code>derive</code> does</a>, you essentially get the AST for the struct in this case, and handle that (to implement a custom <code>Insertable</code> for the <code>derive</code> procedural macro)! (Diesel's <code>derive(Insertable)</code> starts being implemented <a href="https://github.com/diesel-rs/diesel/blob/0f64912293756f8959e1c86d2b1e4c91da64e8ba/diesel_derives/src/lib.rs#L409" rel="nofollow noreferrer">here</a>, which goes to <a href="https://github.com/diesel-rs/diesel/blob/0f64912293756f8959e1c86d2b1e4c91da64e8ba/diesel_derives/src/insertable.rs#L11" rel="nofollow noreferrer"><code>insertable#derive</code></a>, to <a href="https://github.com/diesel-rs/diesel/blob/0f64912293756f8959e1c86d2b1e4c91da64e8ba/diesel_derives/src/model.rs#L35" rel="nofollow noreferrer"><code>Model#from_item</code></a>, FWIW, it's all about parsing that AST for the struct it looks like).</p>
<p>So in a similar fashion, I need basically a way to say &quot;include the AST&quot; in whatever I'm implementing. But you can take it further and say &quot;include the AST in the runtime&quot;. So I think I may end up going that route.</p>
<p>The compiler is called &quot;loom&quot;, since it weaves things together. So I am adding a special <code>loom</code> term to the definition of key things like the <code>form</code> (type/class), and the function object, or even to a module. By saying <code>loom true</code> you will get the final resultant AST for the object you need. This gives a way to access the AST!</p>
<p>With the AST in hand, we can easily iterate through the fields/props of a type, to do our insertion into the SQL database. It simply iterates through the fields, and creates a SQL insertion string or whatever. So I am thinking defining this might look like this for our <code>form user</code>:</p>
<pre><code>form user
  link email, like text
  link name, like text

  task insert
    # `self` is the `user` instance
    take self, loom true # this adds the AST of `self` to `self`!

    walk self/form/links
      take link

      # for now, just print the prop/field &quot;name&quot; to the terminal
      show &lt;{link/name}&gt;
</code></pre>
<p>This would mean, I can omit all 5000+ native JS types' metadata, and only include 1 type AST/metadata, for that of the user type. By adding <code>loom true</code>, the compiler becomes aware that it needs to add the AST of the user type to the output build. I <em>think</em> that'll solve the problem?</p>
<p>If you want the AST for a specific task (function):</p>
<pre><code>task insert
  loom true
  # ...
</code></pre>
<p>That would mean you can do <code>insert.takes.forEach</code> basically, to iterate through the inputs even, of the function. I know in JS you can do <code>func.length</code> to get the number of inputs to a function, but you can't further inspect the function. Basically you need to add the function AST to get that extra information.</p>
<p>If you want the AST for a whole module, just add it at the top level:</p>
<pre><code>loom true
</code></pre>
<p>Anyway, at first glance this seems like it might solve the problem. Maybe there is another way to solve this problem (of inserting fields dynamically into a DB, without having to be explicit about each one). I'm guessing what Diesel is doing with <code>derive</code> is a lot of code generation, which will result in explicit instructions for each property to do an insert, for example. Doing that in my case would increase the JS output build size, so I want to avoid that. I'd be open to hearing ways of solving this differently if you're open to it!</p>

CC BY-SA 4.0
2023-07-06T23:19:01.083Z
2023-07-06T23:19:01.083Z
Lance Pollard
<p>Another option, if one is designing a language, would be to define a format of memory blob that would contain configurable information about a type, and allow programmers to indicate what information about various types (e.g. struct member names) should be included within those blobs.</p>
<p>This would make it possible for a library to offer &quot;export to JSON&quot; or &quot;import from JSON&quot; functionality that could work with bare in-memory structures, if the functions accepted a pointer to the structure to be processed as well as a pointer to a type-info object describing its layout.  Only types whose layout was used for such purposes would need to have information included within the executable.</p>

CC BY-SA 4.0
2023-07-09T17:13:11.300Z
2023-07-09T17:13:11.300Z
supercat
<p>You can avoid loading big metadata module by splitting it into several small one and load them on demand.</p>
<p>It is unlikely for app to use all types in tour library.</p>

CC BY-SA 4.0
2024-11-26T06:40:49.250Z
2024-11-26T06:40:49.250Z
talex
<h1>You are building a dynamic type system.</h1>
<p>Contrary to popular belief, even if we ignore gradually-typed languages, static typing and dynamic typing are by no means mutually exclusive. Many popular statically-typed languages also include a dynamic type system, and these two type systems are integrated at the language level.</p>
<p>In a “purely static” type system, the types are checked at compile-time and <a href="https://en.wikipedia.org/wiki/Type_erasure" rel="nofollow noreferrer"><em>erased</em></a> at runtime. Runtime values are not annotated with their types, they just store data. C is an example of a language with full runtime type erasure. Languages like Haskell and Rust are also fully type erased by default, though they have opt-in mechanisms for limited dynamic typing (<a href="https://hackage.haskell.org/package/base/docs/Data-Dynamic.html" rel="nofollow noreferrer"><code>Data.Dynamic</code> in Haskell</a>, <a href="https://doc.rust-lang.org/std/any/index.html" rel="nofollow noreferrer"><code>std::any</code> in Rust</a>).</p>
<p>Other languages use hybrid systems. C++ includes a limited dynamic type system to support <code>dynamic_cast</code> and <code>typeid</code> on all class instances (though this can be disabled using compiler-specific flags). Java includes a very rich dynamic type system, which it uses to implement all of the following features:</p>
<ul>
<li><p>Runtime type checks via the <code>instanceof</code> operator.</p>
</li>
<li><p>Safe, checked downcasting.</p>
</li>
<li><p>Runtime class loading and dynamic class compilation.</p>
</li>
<li><p>Runtime type reflection APIs.</p>
</li>
</ul>
<p>Note that many of these features are tightly integrated with Java’s static type system, so the dynamic system cannot simply be dispensed with: dynamic type checks are necessary to support downcasting while retaining type soundness. Also note that, despite the richness of Java’s dynamic type system, generics infamously remain type-erased, so they are invisible from the dynamic type system’s perspective. (This is a frequent source of confusion for people learning Java generics.)</p>
<p>If you are building a hybrid system, you have a large design space available to you, and each point in the space comes with its own tradeoffs. An exhaustive discussion would be too detailed for a single answer to cover, but we can take a look at a few examples.</p>
<h2>Checked dynamic casts</h2>
<p>If your language supports nominal subtyping, and you want to be able to safely support downcasting on <em>all</em> values in your language, some amount of pervasive dynamic information is necessary. There’s just no other way around it.</p>
<p>However, this information can be quite minimal. For each type in the program, generate a global type information table of the following shape:</p>
<pre class="lang-rust prettyprint-override"><code>struct TypeInfo {
  id: TypeId,
  supertypes: [TypeInfo],
}
</code></pre>
<p>In many cases, the separate <code>TypeId</code> field can be omitted, and the identity of the <code>TypeInfo</code> structure itself can be used as the <code>TypeId</code>. For a native-like target, this identity would be provided by the structure’s address; for a JS-like target, it could be provided by object identity. The overhead of this information should be quite small, just a few bytes per type and a single pointer per object.</p>
<h2>Datatype-generic programming</h2>
<p>Datatype-generic programming is a technique used to write functions that operate on values of <em>arbitrary</em> datatypes by somehow representing the type’s structure as a value in the programming language. This can be done at both compile time and at runtime.</p>
<p><a href="https://en.wikipedia.org/wiki/Template_metaprogramming" rel="nofollow noreferrer">C++ template metaprogramming</a>, <a href="https://lexi-lambda.github.io/blog/2021/03/25/an-introduction-to-typeclass-metaprogramming/" rel="nofollow noreferrer">Haskell typeclass metaprogramming</a>, and Rust trait metaprogramming all provide mechanisms for compile-time datatype-generic programming. A similar but distinct strategy is to use a procedural macro system, as you allude to in <a href="https://langdev.stackexchange.com/a/2126">your answer</a>. Runtime datatype-generic programming is generally accomplished via runtime type reflection mechanisms. These different approaches have the following pros and cons:</p>
<ul>
<li><p>Runtime generic programming techniques naturally need to be able to reflectively query the type information of values at runtime, which means that information must be preserved somewhere. This is not necessary with compile-time techniques.</p>
</li>
<li><p>Compile-time techniques generate specialized versions of the code for each type they’re applied to, so they can be as fast as their equivalent handwritten functions. Runtime generic programming techniques are generally much slower.</p>
</li>
<li><p>On the other hand, the specialized function copies generated by compile-time generic programming techniques can take up a lot of space, while runtime techniques only use a single copy of the function. This makes the choice between these two techniques a classic time–space tradeoff.</p>
</li>
<li><p>Runtime generic programming techniques can operate on values even if their precise types are not statically known. This is quite common in object-oriented languages, where values are often subtypes of their statically-declared types. Compile-time approaches cannot easily handle this case.</p>
</li>
</ul>
<p>As you can see, there’s no clearly better or worse approach here, just a set of potential choices.</p>
<h2>Opt-in dynamic typing</h2>
<p>As mentioned in the first section of this answer, Haskell and Rust both provide <em>opt-in</em> dynamic typing. This allows users to explicitly request that runtime typing information be generated at <em>use sites</em> rather than <em>definition sites</em>. Since this is a demand-driven approach, code that does not need dynamic type information will not need to pay for it.</p>
<p>The trick these languages use leverages Haskell’s typeclasses and Rust’s traits (which are essentially the same thing with two different names). Typeclasses/traits can be viewed as <a href="https://lexi-lambda.github.io/blog/2021/03/25/an-introduction-to-typeclass-metaprogramming/" rel="nofollow noreferrer">functions from types to terms</a>, so they provide a mechanism to obtain a runtime structure that represents an arbitrary type.</p>
<p>Crucially, this type information is always ultimately resolved statically, and this is true for <em>all</em> uses of typeclasses/traits. However, constraints in type signatures allow the point where the instance is selected to be deferred to function call sites, which allows the type to remain unknown at the point where the trait’s methods are directly used. Since the type must eventually be resolved statically, this approach is insufficient for systems that support subtyping for the same reasons noted in the previous section. However, if you don’t have subtyping, this strategy can work quite nicely.</p>
<h2>Utilizing the dynamic type system of the host language</h2>
<p>In your question, you note that you’re compiling to JavaScript. But JavaScript already has a dynamic type system! So perhaps you can get away with using its features rather than implementing your own dynamic type system on top.</p>
<p>Whether or not this is sufficient for your needs is, of course, difficult to say. Hybrid static/dynamic type systems usually need a little more structure to be able to connect the dynamic types back to the static types. However, if what you care about is code size, it may be possible to reconstitute a lot of this information at runtime rather than generating it all as code. This is another example of a time–space tradeoff.</p>

CC BY-SA 4.0
2023-07-07T21:03:44.190Z
2024-11-23T06:26:57.513Z
2024-11-23T06:26:57.513Z
Alexis King
# How to avoid output build bloat when wanting to access type metadata information at runtime?
Posted by: username_0 on 2023-07-06
In my [answer](https://langdev.stackexchange.com/a/2120/1270) to the question *What are the advantages and disadvantages of making types as a first class value?*, I point out that for the language I'm working on, I wanted to have the ability to do runtime checks on the type, because from my experience it is quite limiting/restrictive/cumbersome to only allow compile-time checks on the type, and it is really easy to understand and use type reflection and that sort of stuff (accessing type metadata at runtime, basically).

But as I point out there, for my case I am compiling my lang to JavaScript. If I include the 5000+ built-in types that exist for native JS classes/etc., that is roughly 1.5 megabytes of type metadata that would extremely bloat the output JS build file. So how can I reconcile this problem?

1. I could not allow type reflection or metadata access at all.
2. I could omit some type metadata in some cases (like props/fields), where they are never accessed at runtime (would cut out a lot). This would be hard to implement but possible.
3. Any other solutions you can think of?

The fundamental underlying question is, **do you really *need* type reflection?** Can you build programming languages without it, and be able to do all your type checks and implement things in a nice and easy way (with no mentally burdening workarounds, like you often have in Rust as far as I've seen)? The surface level question though is, given I would like some sort of type reflection, *or something that accomplishes a similar set of functionality possibilities*, what are my options?

I added runtime type checks and the ability to do `obj.type.fields.forEach` because I want to build validations (like checking if a string matches the `email` type regex, etc.), and other things like documentation. But for docs (printing the type fields, for example), I guess that would be a different use case where I deal with the compiler-level AST instead of the "runtime AST"? But even then I can imagine a case where you are debugging runtime code, and want to inspect the type metadata/fields, so perhaps there is a "dev build", that would solve that. But maybe there are other cases where you still really need reflection (can't think of any off the top of my head)? Such as building an app which runs code and shows you a log of the objects that pass through it or something (the types, which it would have to access at runtime in order to log)?

Anyway, wondering how I can accomplish the *functionality* goal of having type reflection, without adding the bloat? I'm not sure if I need to cut out type reflection altogether, in which case I'd like to know how you can handle the cases/needs of dynamic type checking.
**Tags:** types dynamic-typing runtime
> **Comments:**
> **username_1**: Swift just doesn't bother, so a statically-linked Hello World is six megabytes.  
> **username_0**: @Bbrk24 Interesting, that's a good insight to keep in mind! Could Swift accomplish what it wants to accomplish without dynamic typechecking then (it sounds like Swift has dynamic type checking, I'm not familiar though), and ultimately cut out all the types from the build?  
> **username_1**: Swift is mostly statically typed, but it has `Any`. You can query whether an instance of `Any` adopts a certain protocol, and grab its vtable if it does (or get `nil` if not). Even without reflection -- which does exist, to a limited extent -- you need type metadata to be able to do that.  
---
## 4 answers
### Answer by username_4 on 2023-07-07. Score: 6 | Accepted answer
You are building a dynamic type system.
Contrary to popular belief, even if we ignore gradually-typed languages, static typing and dynamic typing are by no means mutually exclusive. Many popular statically-typed languages also include a dynamic type system, and these two type systems are integrated at the language level.
In a “purely static” type system, the types are checked at compile-time and erased at runtime. Runtime values are not annotated with their types, they just store data. C is an example of a language with full runtime type erasure. Languages like Haskell and Rust are also fully type erased by default, though they have opt-in mechanisms for limited dynamic typing (Data.Dynamic in Haskell, std::any in Rust).
Other languages use hybrid systems. C++ includes a limited dynamic type system to support dynamic_cast and typeid on all class instances (though this can be disabled using compiler-specific flags). Java includes a very rich dynamic type system, which it uses to implement all of the following features:

Runtime type checks via the instanceof operator.

Safe, checked downcasting.

Runtime class loading and dynamic class compilation.

Runtime type reflection APIs.


Note that many of these features are tightly integrated with Java’s static type system, so the dynamic system cannot simply be dispensed with: dynamic type checks are necessary to support downcasting while retaining type soundness. Also note that, despite the richness of Java’s dynamic type system, generics infamously remain type-erased, so they are invisible from the dynamic type system’s perspective. (This is a frequent source of confusion for people learning Java generics.)
If you are building a hybrid system, you have a large design space available to you, and each point in the space comes with its own tradeoffs. An exhaustive discussion would be too detailed for a single answer to cover, but we can take a look at a few examples.
Checked dynamic casts
If your language supports nominal subtyping, and you want to be able to safely support downcasting on all values in your language, some amount of pervasive dynamic information is necessary. There’s just no other way around it.
However, this information can be quite minimal. For each type in the program, generate a global type information table of the following shape:
struct TypeInfo {
  id: TypeId,
  supertypes: [TypeInfo],
}

In many cases, the separate TypeId field can be omitted, and the identity of the TypeInfo structure itself can be used as the TypeId. For a native-like target, this identity would be provided by the structure’s address; for a JS-like target, it could be provided by object identity. The overhead of this information should be quite small, just a few bytes per type and a single pointer per object.
Datatype-generic programming
Datatype-generic programming is a technique used to write functions that operate on values of arbitrary datatypes by somehow representing the type’s structure as a value in the programming language. This can be done at both compile time and at runtime.
C++ template metaprogramming, Haskell typeclass metaprogramming, and Rust trait metaprogramming all provide mechanisms for compile-time datatype-generic programming. A similar but distinct strategy is to use a procedural macro system, as you allude to in your answer. Runtime datatype-generic programming is generally accomplished via runtime type reflection mechanisms. These different approaches have the following pros and cons:

Runtime generic programming techniques naturally need to be able to reflectively query the type information of values at runtime, which means that information must be preserved somewhere. This is not necessary with compile-time techniques.

Compile-time techniques generate specialized versions of the code for each type they’re applied to, so they can be as fast as their equivalent handwritten functions. Runtime generic programming techniques are generally much slower.

On the other hand, the specialized function copies generated by compile-time generic programming techniques can take up a lot of space, while runtime techniques only use a single copy of the function. This makes the choice between these two techniques a classic time–space tradeoff.

Runtime generic programming techniques can operate on values even if their precise types are not statically known. This is quite common in object-oriented languages, where values are often subtypes of their statically-declared types. Compile-time approaches cannot easily handle this case.


As you can see, there’s no clearly better or worse approach here, just a set of potential choices.
Opt-in dynamic typing
As mentioned in the first section of this answer, Haskell and Rust both provide opt-in dynamic typing. This allows users to explicitly request that runtime typing information be generated at use sites rather than definition sites. Since this is a demand-driven approach, code that does not need dynamic type information will not need to pay for it.
The trick these languages use leverages Haskell’s typeclasses and Rust’s traits (which are essentially the same thing with two different names). Typeclasses/traits can be viewed as functions from types to terms, so they provide a mechanism to obtain a runtime structure that represents an arbitrary type.
Crucially, this type information is always ultimately resolved statically, and this is true for all uses of typeclasses/traits. However, constraints in type signatures allow the point where the instance is selected to be deferred to function call sites, which allows the type to remain unknown at the point where the trait’s methods are directly used. Since the type must eventually be resolved statically, this approach is insufficient for systems that support subtyping for the same reasons noted in the previous section. However, if you don’t have subtyping, this strategy can work quite nicely.
Utilizing the dynamic type system of the host language
In your question, you note that you’re compiling to JavaScript. But JavaScript already has a dynamic type system! So perhaps you can get away with using its features rather than implementing your own dynamic type system on top.
Whether or not this is sufficient for your needs is, of course, difficult to say. Hybrid static/dynamic type systems usually need a little more structure to be able to connect the dynamic types back to the static types. However, if what you care about is code size, it may be possible to reconstitute a lot of this information at runtime rather than generating it all as code. This is another example of a time–space tradeoff.
---
### Answer by username_0 on 2023-07-06. Score: 1
In the language I'm working on, you can define a "class" or "type" like this:
form user
  link email, like text
  link name, like text

Say I wanted to make it "insertable" into a SQL database. Then I can do like Rust's diesel crate, where they have:
#[derive(Insertable)]
#[diesel(table_name = posts)]
pub struct NewPost<'a> {
    pub title: &'a str,
    pub body: &'a str,
}

Well I just learned what Rust's derive does, you essentially get the AST for the struct in this case, and handle that (to implement a custom Insertable for the derive procedural macro)! (Diesel's derive(Insertable) starts being implemented here, which goes to insertable#derive, to Model#from_item, FWIW, it's all about parsing that AST for the struct it looks like).
So in a similar fashion, I need basically a way to say "include the AST" in whatever I'm implementing. But you can take it further and say "include the AST in the runtime". So I think I may end up going that route.
The compiler is called "loom", since it weaves things together. So I am adding a special loom term to the definition of key things like the form (type/class), and the function object, or even to a module. By saying loom true you will get the final resultant AST for the object you need. This gives a way to access the AST!
With the AST in hand, we can easily iterate through the fields/props of a type, to do our insertion into the SQL database. It simply iterates through the fields, and creates a SQL insertion string or whatever. So I am thinking defining this might look like this for our form user:
form user
  link email, like text
  link name, like text

  task insert
    # `self` is the `user` instance
    take self, loom true # this adds the AST of `self` to `self`!

    walk self/form/links
      take link

      # for now, just print the prop/field "name" to the terminal
      show <{link/name}>

This would mean, I can omit all 5000+ native JS types' metadata, and only include 1 type AST/metadata, for that of the user type. By adding loom true, the compiler becomes aware that it needs to add the AST of the user type to the output build. I think that'll solve the problem?
If you want the AST for a specific task (function):
task insert
  loom true
  # ...

That would mean you can do insert.takes.forEach basically, to iterate through the inputs even, of the function. I know in JS you can do func.length to get the number of inputs to a function, but you can't further inspect the function. Basically you need to add the function AST to get that extra information.
If you want the AST for a whole module, just add it at the top level:
loom true

Anyway, at first glance this seems like it might solve the problem. Maybe there is another way to solve this problem (of inserting fields dynamically into a DB, without having to be explicit about each one). I'm guessing what Diesel is doing with derive is a lot of code generation, which will result in explicit instructions for each property to do an insert, for example. Doing that in my case would increase the JS output build size, so I want to avoid that. I'd be open to hearing ways of solving this differently if you're open to it!
---
### Answer by username_2 on 2023-07-09. Score: 1
Another option, if one is designing a language, would be to define a format of memory blob that would contain configurable information about a type, and allow programmers to indicate what information about various types (e.g. struct member names) should be included within those blobs.

This would make it possible for a library to offer "export to JSON" or "import from JSON" functionality that could work with bare in-memory structures, if the functions accepted a pointer to the structure to be processed as well as a pointer to a type-info object describing its layout. Only types whose layout was used for such purposes would need to have information included within the executable.
---
### Answer by username_3 on 2024-11-26. Score: 0
You can avoid loading big metadata module by splitting it into several small one and load them on demand.

It is unlikely for app to use all types in tour library.
---
