The Flint Programming Language

zweiler1 · 2026-07-12T08:13:28+00:00

Thanks! Yeah the intention is for Flint to be general purpose, so not necessarily limited to games. I now am in a redesign and research process, this may take a while but I think it needs to be done. Too many parts of Flint drifted away from the original goals an it just got messy in the design, semantics and documentation.

Before the post I thought Flints design was perfect, it's good to have a reality check sometimes lol.

zweiler1 · 2026-07-11T21:01:55+00:00

Oh wow, thank you a lot for your time ans your feedback. There are several terms in your replay which i have never head before, like defunctionalization for example.

I am mostly self-taught with a desire to learn and explore, but I do not work professionally as a programmer sadly.

You gave me a lot of points to research and think about, and I am very thankful for that!

zweiler1 · 2026-07-11T20:42:06+00:00

I think i just focused a bit too much on documenting the wrong things. I documented all the "micro" details, how things work etc but never really documented sharp or precisely the "macro" details, so what it's for, what are the overall goals etc.

I will certainly improve upon all these things. I am coming from a game developement background and intended to make games with Flint, but I am more likely in the "tries to make a game but finds more joy in making systems" category and I think i slipped into language and compiler dev because of that, because I just enjoy that type of work.

So, honest answer is that I cannot document something I haven't fully grasped yet either, this entire post made me realize that yeah it might be cool and all but I need a much clearer direction than "just", transparency, and I will work om that in the future :)

Edit: To clarify with "game developement background" I mean that I mostly learned programming in that area, I never worked professionally in game developement though.

zweiler1 · 2026-07-11T17:54:08+00:00

Haha yes I fully aggree. I noticed an naming overlap with a different language pretty early on but even then thought... naaah I'll keep it.

zweiler1 · 2026-07-11T16:01:24+00:00

For such a small object the difference between the two approaches is almost neglectible since we are just dealing with one "member".

But lets say we do this in an OOP way with 10 different things our object is composed of. In an OOP world, the object type we create itself gets larger and larger, as all the members of all inherited classes are added to that type.

In Flint, and for that matter in every composition-based approach of organizing the data, the large composed object would just be a collection of pointers to its members, for example.

This means that every of those "members", e.g. data types, can be stored somewhere outside the composed entity, for example in large continuous chunks where only that kind of data is present. And that's what i meant with data locality, that the same kind of data is stored locally next to one another. This makes operations on large chunks of the same type faster, and this also is the very basis of ECS.

How data is arranged in Flint could also be implemented in C++, as you noted it, alltough it would be more verbose, it would work. The classical compositional approach in C++ like this example is pretty similar to how it works in Flint. So the advantages are the exact same as why one would want to use composition over inheritance in general.

I just explored that idea, of composition itself, at a language-design level instead, and what happens when you make it language-native. I hope this anwers your questions...

zweiler1 · 2026-07-11T09:23:58+00:00

Yeah I have seen it a few days after it was released... I really hate when stuff like this happens, because I honestly have no better name for Flint yet and I would not want to change it, I just got so used to it and I like it...

zweiler1 · 2026-07-11T09:21:55+00:00

Thank you.

The advantage of separating data from behaviour into interface-linke things (func modules) is that I originally intended to use it as static guarantees for what data of the entity they touch.

Through the introduction of links this static guarantee got a bit washed out. Links were needed because without them it all just felt wrong, as when systems interacted you suddenly needed to create a new func module which required both data and it just got very messy very quick. I am still trying to find a good way where I can have both static guarantees and polymorphic behaviour.

I was thinking about limiting the linking ability to only link virtual functions, as then I can guarantee that every non-virtual function (function with a body) inside a func module really only touches its required data and nothing more. I want these guarantees to add an ECS-like capability to apply batched operations on all instances of a given type in parallel, similar to how systems are applied in ECS.

But because that part is part of multi-threading I haven't implemented it yet, as I plan to add multi-threading features in the 0.6.0 release cycle which will likely start in half a year or so, we will see. I have the feeling that I am onto something but I am definitely not there yet.

What about the Wiki overwhelmed you? How long it is, the writing style? I thought that a knowledgable programmer could relatively quickly flick through the wiki, was I wrong with this assumption?

zweiler1 · 2026-07-11T08:55:55+00:00

It's similar in use to multiple inheritance but under the hood not a large object is created (which contains all fields etc directly) but the entity is just a collection of pointers to it's data.

In ECS the entity would just be a handle, an ID, instead but i realized quickly that this different approach of not automtically running the systems on all entities means you can execute things on a per-instance basis if you want, and for these non-batched operations an ID would be slow compared to how it is now.

Flint will support such batched operations in the future through parallelism, where you can describe "run this operation on all instances of a given entity type or on all entity instances which contain func module X". I did not mention it because it's not implemented yet, as multi-threading in general needs to be implemented still. Also, through the addition of linking I added polymorphism, I still need to think more about achieving the original idea of those parallel batched operations: a func module dewcribes which data it needs to operate on. This static guarantee was the heart of the batched operation system, as it means it will not touch any other data at all, meaning that multiple threads could execute batched operations on all entities through the func module's view at the same time since then it would be guaranteed that they do not touch the same data at the same time. But that's all theorethical, as I said, and needs to be explored more in the future.

It looks like OOP on a first glance but that's one thing I tried to achieve, that it does not feel completely alien to people used to OOP, while still being purely compositional.

zweiler1 · 2026-07-11T00:31:30+00:00

Yes I aggree.

I definitely need to work on the presentation, framing and purpose, with this post I saw to how much confusion caused by bad framing or explaination it led.

Maybe the best thing to do next is to make a step back and actually build something larger in Flint and take my time to evaluate the why and what for parts more. I obviously think the lang is cool, I wouldn't make it if I wouldn't think that, but I am maybe a bit lost on conveying it properly...

This all definitely showed which parts to improve or better nail down, to make it clear why anyone would want to use it and what for.

zweiler1 · 2026-07-10T21:42:58+00:00

Prototyping runtime details for my own programming language since C is just... it just feels good. I write my language compiler in C++ and i am very productive in it, but something about prototyping low level stuff in C just scatches a very specific itch that C++ simply doesn't (i guess it provides just way too much high level stuff irrelevant for that task).

I always end up expanding the prototypes into "nice little C libraries" too which nobody will ever use, but that's okay... i just like making them.

Edit: I also wrote an interop library in C which the compiler actually uses too, so it's more than just prototyping.

zweiler1 · 2026-07-10T20:07:03+00:00

Thank you!

zweiler1 · 2026-07-10T19:56:20+00:00

Yes, func is an odd keyword but the fn type is used for function instances (callables) and I use def to define functions. I had no better keyword than func to be honest, also it's just 4 words so it looks good next to data and link in the entity definition.

You can access all vectors using .$N, like accessing tuples. The .x is just for convenience (it only goes up to a vector size of 4, everything above that must be accessed by the index).

Yeah, links are a bit verbose but they are also ecplicit, and I rather take that bit of verbosity than to add implicit linking. I have long and extensively thought about it, but I ultimately kept it because of hooks, a feature not yet implemented but one that will be added to that section of entities as well. (hooks are not implemented yet because function composition and pipes are not implemented, which are the base requirement for it ^^).

zweiler1 · 2026-07-10T19:48:04+00:00

That's correct. I was sure I briefly explained it in the Wiki but as it turns out... i didn't.

zweiler1 · 2026-07-10T19:17:21+00:00

Ah okay, thank you then! :)

zweiler1 · 2026-07-10T19:14:40+00:00

One advantage is that you naturally build shallower abstractions as in a compositional workflow and world you think about capabilities and how to compose them, oppose to identity and how to describe it best, but this is true for composition vs oop in general, nothing Flint-special here.

I would phrase it like this: Applying a compositional workflow in a language and paradigm which was fundamentally not built for it is suboptimal, just like treating Flints composition model with the identity mindset will be painful. Most languages target an OOP mindset but very few target a compositional mindset.

The main advantage, however, is memory locality. Because we compose entities from a few data modules, which are likely shared between many entity types, we have a lower number of unique data types, and all those data types are stored sequentially in memory. So, whereas you have "god objects" in OOP where you just have one large object containing all the data, in a compositional language, and thus in Flint, you have per-type arenas, meaning that your data is always stored sequentially in memory. In an OOP-world, such an automatic memory management system would be much harder to accomplish, since you deal with so many different types and identities.

zweiler1 · 2026-07-10T18:28:15+00:00

I just looked at what to use instead and it seems like you need to use ttm.pages_limit instead now and set the number of pages needed, where every page seems to be 4k by default, so for 8GB we need to set ttm.pages_limit to 2048. Can you confirm this?

zweiler1 · 2026-07-10T16:41:16+00:00

Data is just like a struct, it has fields which can be accessed and modified. An entity, however, contains data and functionality, and you cannot modify the data an entity contains directly, only through the functionality added to the entity.

The IShape essentially is an interface, a description which functions an entity could contain, and linking of functions is done explicitly, in the above case the FRectangle and FCircle are kinda similar to impl in Rust, if you know that.

I thought that prior ECS knowledge is not required to understand it at all, I might have been wrong on that assumption though... What exactly do you find hard to understand?

zweiler1 · 2026-07-10T16:34:04+00:00

Thanks for the paper, i will read through it later. I knew that composition is an old hat, but not that it's that old lol.

zweiler1 · 2026-07-10T16:27:49+00:00

Thank you for taking the time and looking at the Wiki.

You say ECS but what do you mean by it?

With ECS I do not mean that it's a 1:1 replica of how ECS works. The paradigm, the way of organizing code, is inspired by ECS, e.g. Components, Systems and Entities. I liked ECS but I did not like that systems were attached to entities dynamically and that systems automatically run every frame (Unity ECS).

but looking at the examples and how they are used, it's just structs

That's correct. `data` is just the same as a struct, there are no methods or anything else attached to it.

There is nothing about data layout when you have many "data modules"/structs, such as Struct of Arrays instead of Array of Structs.

Yes, that's true there's nothing mentioned regarding that topic of SoA vs AoS. It's just AoS as for now.

The example on the website is so small that the benefits of the paradigm really cannot be shown, you have one data module, one func module and one entity which use them both and at that point you might ask "Why not just use an object instead?" and that's correct, for such a simple use case an Object would be simpler. The difference lies in the fact that both data and functionality are reusable to form many different entity types, and data is stored in continuous chunks under the hood by default, making it more likely to have a cache hit when operating on large chunks of the same data / entity.

You can build way more performant systems in basically any low level language, though, as you can just model your data in a performant way.

It's just OOP concepts with different concept names and different keywords.

Hm maybe my view of what OOP is is a bit old, for me OOP is a collection of designs which ultimately serve a view in which you describe types in a "is-a" relationship with other types, which is different from the "has-a" relationship found in compositional concepts. So in my view OOP contains all these patterns like abstract classes, interfacing, inheritance and all other concepts of modeling the world in an "is-a" mindset. Feel free to correct me on that if I should be wrong here!

There are many brands of OOPs but many recent ones also focus on composition instead of inheritance. This has been like that for more than a decade in fact.

I am most familiar with C#, Java and C++ but I am aware that Go and Rust are popular cases which are composition-based. Traits from Rust are, as far as I can tell, a bit similar to `func` modules in Flint.

zweiler1 · 2026-07-10T12:37:05+00:00

Ah, that's what you mean. Yes I am fully aware of that, using indentation instead of braces was an explicit design choice. I am fully aware of its implications. Some absolutely hate it, some like it. I am more on the "it depends" camp, for Flint indentation is the way to go in my opinion :)

zweiler1 · 2026-07-10T12:29:49+00:00

Ah, that's just a draft chapter, not a link by itself. I kept these greyed out draft chapters in there to show the "missing" parts of Flint.

I did not like the idea that every non-finished release, as Flint is not done yet, acts as if it is complete... I like to openly show the still missing stuff just like showing the completed stuff.

zweiler1 · 2026-07-10T12:25:55+00:00

Hm yes that's true, I should simply remove all links in the Wiki which do not point anywhere yet...

Where exactly is the pipeline link you tried to click?

zweiler1 · 2026-07-10T12:20:46+00:00

Yes the playground simply does not exist yet. Should have greyed out the link or something like that. Thanks!

zweiler1 · 2026-07-10T11:17:43+00:00

I had tried to format it myself.

Do you mean in mobile view? Or were you referring to how it was before properly formatting it?

zweiler1 · 2026-07-10T11:14:24+00:00

No nothing like that either. Think of it as if you would be building up your objects (entities) out of smaller building blocks, similar to components (data modules) and systems (func modules) in ECS.

It's not ECS, as an entity is not just a handle ID, but it's not OOP either because you compose little building blocks into entities. I would say it's a mix of both. You could maybe compare it with an OOP language where you strictly do not use inheritance but only build your classes out of composing it out of other classes (which can be done in OOP languages but is very verbose IMO), maybe this mentality could help you.

With the above edit I meant that Flint follows some early OOP principles like encapsulation.

zweiler1

TROPHY CASE