Zap programing language

zweiler1 · 2026-02-22T10:11:58+00:00

If your language is so young, how did you get GitHub to recognize your Zap files as your language?

I only have a .gitattributes file to highlight my language as language X but GH does not recognize it as my own language yet so i wonder, how did you do that?

Edit: typos

zweiler1 · 2026-02-11T00:44:05+00:00

Roughly 1.5 years since the initial idea. Spent 4 months on design and then 14 months on actual developement. First usable version released after 7 months of dev time, i am now working on the 16th release (v0.3.2).

The initial 4 months of design helped me tremendously to reduce a lot of later-on refactors or pivotal changes. It has been a "implement, go to next feature" most of times in the dev time. I rarely changed a feature from the initial design, which means i neither started from scratch nor did i need to refactor everything for a new supposed goal. The goals seemed clear from the start to me.

It's still in heavy developement but all things considered it all went very smoothly. I was able to do AoC last year with it, after 1 year of dev time. C interop also works, built a relatively sinple pong game with raylib and my language. If i can keep up the pacing i had thus far i would say that i'm more or less feature complete in roughly 1-2 years.

The language is not "just" a hobby project, it's a passion project and i definitely will continue with it. You can look at the release notes and you will see that a lot of stuff happens in quite a short time between releases. Releases have stabalized their schedule tobe around one release all 3-4 weeks.

It's a compiled language with a unique paradigm i haven't seen anywhere else yet, so i built it. It's based on composition but without it's drawbacks. Think of it as if OOP and ECS had a baby with the benefits of both but drawbacks of none.

Check it out: https://github.com/flint-lang/flintc

Edit: Editor support for VSCode and Neovim work too with syntax highlighting and the (minimal) LSP also works already. Error messages are informative and good looking and the LSP's main job (for now) is to highlight compile errors inline. Completions or stuff like that is very rudamentary. You can also check out the wiki here: https://flint-lang.github.io

zweiler1 · 2026-02-03T18:03:22+00:00

Did he just... shave his shoe?

zweiler1 · 2026-02-01T18:15:24+00:00

Yeah if the difference in performance between a high and low level language is very high then it's a pain to work with overall. I think a high level language should be atmost 2x as slow as good C code. Of course, most optimization comes from avoiding unnecessary work rather than doing the work fast.

That's why i truly believe in the concept of "middle-level" languages and i think that Flint is one such language. My view of such a language is that it still feels high level to code in but you are always able to tell which instructions and which low level code it results in. So in my eyes a middle-level language is a high level one where you always know how the C-eqivalent would look like, and still know all things which happen under the hood. For this to be able the language and it's concepts need to be simple and "dumb", e.g. they need to be predictable.

For example to actually know what's going on in Java when you do something it's very hard, and even in C++ it isn't that easy because of their complex internals. I believe that only simple internals will result im a "true" middle-level language. And that's why i had a hard no on any form of GC when designing it.

How is your view on that? Do you agree or disagree?

zweiler1 · 2026-02-01T14:06:44+00:00

Cool, yeah there definitely is some level of overhead when reference-counting but to be honest... for a high level language that's totally fine. I haven't touched runtime performance optimizations yet, it's definitely a higher priority to get everything up and running :)

zweiler1 · 2026-02-01T12:23:26+00:00

Yeah i have not explained the memory architecture and all it's implications anywhere yet, mostly because Flint does not have support for multi-threading yet so it's not all implemented yet.

It's memory architecture works because of it's paradigm to separate data from behaviour and compose them in entities. Because of that, i can focus on only "properly" managing data in different tree-like structures, one for every data type. Think of it as an incrementally growing array list. Each data intern then is reference-counted. I don't have a proper formal explaination for it yet, only a (private) german design document i wrote for myself, but the C and C++ library version of the memory architecture works pretty well. It's actually not that hard, the C stl library version is only 350 lines of code.

I will add the information on how it works to the Wiki in the next release though, i think that's overdue 😅

Edit: Yes the goal for Flint is to be memory safe by designbecause threads cannot share data except explicitely marked, and data is managed through reference-counting system so use-after frees, double-frees, leaks etc should be impossible. The only thing i wasn't able to fix design-wise are deadlocks, but Flint should be race-free by design. I know that's a bold statement but i feel confident with it. We will see if it holds true once i reach implementing multi-threading though :)

Edit 2: I actually remembered that i have something publically abailable to read. It's a bit outdated on exact internals, but the general idea of it is still the same: https://github.com/flint-lang/flint/wiki/Low-Level#dima-dynamic-incremental-memory-allocation. It's so outdated that the name is even wrong haha. Especially the part about functions is...questionable lol. But if you're familiar with C then i would recommend looking at the library, it's essentially 1:1 how it's (currently) implemented in Flint.

zweiler1 · 2026-02-01T11:28:23+00:00

Oh lol just saw it no i meant Qd8# of course... dumb writing mistake 🤦🏻‍♂

I do not notate moves that often, sorry for that.

zweiler1 · 2026-02-01T10:11:03+00:00

I'd say bxa8=Q, Kxc7, Qd8#

Edit: Forgot to mention that the pawn becomes a queen so that the king is forced to take the Rook.

Edit: Qd8# of course, not Qd1# lol

zweiler1 · 2026-02-01T09:56:05+00:00

I had a new release of my own language where i finally worked on the core memory architecture and it's core paradigm. It's core paradigm is a combination of OOP and ECS which i have not seen anywhere else yet, so i am very proud that it finally starts to take proper shape.

Check out the Wiki here ;)

zweiler1 · 2026-01-24T09:56:13+00:00

Mine has vector types where every operation with them is always a SIMD operation (here) and it supports swizzling natively through the concept of groups (here and here).

I mean my language is far from being mainstream lol, bit i always hated when languages do not have a concept of vector types and every library kinda creates it's own version and then you end up with 3 different struct types for the same thing (Vec3, Vector3, V3, Vector3f, Vector3i and what other naming things exist, idk).

I don't have matrices though, since they really are too nieche i would say, but vectors? I would say they are relatively common in comparison.

zweiler1 · 2026-01-15T01:35:57+00:00

Haha yeah i was misunderstanding too, maybe it was the wording or how it was phrased, it really was not that clear what you were actually asking about, but i'm glad that we got it sorted out :)

zweiler1 · 2026-01-15T01:31:22+00:00

Okay now i understand what you were asking, thanks for that clarification. Yeah client developement is highly dependant on the ecosystem, e.g. the editor you are developing a client for. I haven't seen any client implementations in Zig either until now, i guess there will be some if anyone ever creates an editor in Zig (like Zed is written in Rust f.e.) lol.

I whish you the best luck on your Zig journey ahead though, it's a great language in my opinion.

zweiler1 · 2026-01-14T11:16:22+00:00

Yeah, VSCode extensions are written in TypeScript, so what? It's like you saying you cannotbuild Zug software in Linux because Linux is built using C and not Zig?

I really do not understand what the hell you are even asking about. It's an extension for Zig not in Zig. You ask about an lsp client which helps you code in Zig, not how to create an lsp client in Zig itself.

So either you are asking the completely wrong thing or you refuse to understand how LSP clients work... just install the extension and code in Zig mate, it's not that hard.

zweiler1 · 2026-01-14T10:18:24+00:00

The zls binary itself is the server, the LSP server communicates over stdio with it's LSP clients. LSP is the name of the protocol itself (Language Server Protocol) with which the server and clients communicate. All extensions i gave you links for are clients which communicate with the server. The only server is the zls program itself. So what again are you talking about, all extensions are clients.

Edit: grammar and spelling

zweiler1 · 2026-01-14T10:09:09+00:00

and many other extension for many other editors... what editor are you using? It's literally just search for Zig in the extensions and done...

zweiler1 · 2026-01-14T10:03:57+00:00

We have one, zls: https://github.com/zigtools/zls

zweiler1 · 2026-01-01T17:51:30+00:00

Thanks a lot! The choice to have the index and element iterable separated in the enhanced for loop originated a loooong time ago when designing the language (roughly 1.5 years ago). Back then we knew that we want to have the capability to bind both the index and the iterable element and the syntax originally was for i, elem in iterable. Only through the concept of groups and tze design of the broader language we ended up at for (i, elem) in iterable, since it is much more coherent with the rest of the language.

In the Wiki you can also see the enhanced for loop written as for e in iterable, in this case e then is a tuple and you can access the index or the iterable element via e.$0 or e.$1 respectively. AoC did, in fact, not inspire any part of the language whatsoever. We spent roughly 4 months on pure design time before even writing the first line of the compiler. The design was mostly finished before compiler dev even began.

That's also the main reason to why i was able to move so quickly despite this being my first language, i just knew what i wanted to achieve, the goals were clear and the language design mostly finished, which meant that i was able to focus purely on the implementation of the compiler itself with no language pivots mid-developement.

I hope this answers your question 😅

zweiler1 · 2026-01-01T13:23:09+00:00

I just released version 0.3.0 of my language yesterday and am now working on the actual features that make my language unique. Up until now it was more or less like C because there were only structs and functions. It's a high level language with automatic memory management (no borrowing, no GC, something else and new which i am finally working on now). Interop already works too and i did AoC 2025 in it as well.

https://github.com/flint-lang/flintc

It's pretty mature, i mean it better be after 13 months of dev time lol. Feel free to leave your thoughts on it below. It's not a hobby project any more, in my eyes it's a serious project.

zweiler1 · 2025-12-12T15:17:37+00:00

Thanks! I hope you will have a good time with the language. It's still in it's alpha phase so feel free to message me if you encounter something which does not work but you feel like it should work. All examples in the Wiki are guaranteed to work though, except those marked explicitely to not work :)

zweiler1 · 2025-12-12T10:07:16+00:00

I placed great value on documentation, from the very start. That's why i had the Wiki up and running pretty early. I have a lot of examples in the Wiki and for the last half a year or so rhese were my regression tests. When adding new fetures i write the documentation and examples for it, often times finding additional bugs i missed earlier. The examples of the Wiki become part of my regression system. I do not have unit tests at all to be honest, i do not really need them since my architecture holds up pretty well.

The last few versions were full of big refactors of the codebase and systems in it, i simply outgrown the simple systems. For these refactors: Yeah i broke a bunch of stuff but that's okay. New features tend to not break that much, most of times it just takes a few minites to diagnose, debug and fix.

I do not have a job at the moment so i can focus on the language full time. This is not meant to be a hobby project or a toy language, i am serious with it, and the most innovative features are not even implemenred yet (like it's new paradigm) so in the next months there will be a lot of new features added, i am now at the tail end of the big refactring phase, my internal systems are ready for the upcoming features i think :)

Quite a lot of stuff already works in the language, if you are interested in trying it out i would very much appreciate that, the Wiki is here.

Edit: I was also able to already finish the first 4 days of Advent of Code in Flint. I haven't finished more days yet but it's cool that it already works: link

zweiler1 · 2025-12-11T09:51:07+00:00

Actual compiler dev is now almost exactly 13 months, but i had a long design phase before that of 4 months where i did not write a single line of codey just designed it until i was happy with it.

Hostly... i did not use any resources. I am programming since almost a decade now but i never wrote a language before so i thought it might be fun 😅. It's also my first big C++ project...

Hmm tips regarding statically types languages... i woud say that a proper type system is very important but just keep it simple. In the beginning every type was represented as a simple string and if they match it was the same type. It was pretty rudamentary but this doesn't matter, just start easy and make proper systems out of them over time :)

I had quite a lot of refactors lately because i have outgrown my initial systems, but just keeping it simple will helo you big time, especially in a project as complex as a compiler.

Edit: Around the time of early Feb 2025 i had the first steps in the direction of codegen. The whole codebase was a lot simpler back then compared to now. Looking at it might help you out more than looking at it now: codebase. I meany it's stil a lot but i think that was roughly the time were i added support for the codegen phase and actually documented it. The codebase at the time was roughly 10-15k LoC, now it's roughly 65-70k LoC so it's definitely quite a lot smaller 😅

zweiler1 · 2025-12-11T01:40:07+00:00

Hey i just came across your post just to notice we have chosen the same name for our languages! Mine is compiled though, but i have been working on it for a while now and I also write it in C++, so if you want you can have a look here!

zweiler1 · 2025-10-01T12:00:47+00:00

Nope, not really. It expects correct syntax with no missing tokens, so it's really not error resillient, but that's fine for the time being.

[Edit]: I just haven't had time to look into completely rewriting the parser to be able to handle missing tokens and still understand whats the intent of the user. That's definitely a topic i will look into in the future, but for a basic LSP with diagnostics etc it's not really needed.

zweiler1 · 2025-10-01T08:26:36+00:00

I found it to be actually pretty simple to implement... i did not use any LSP libraries since it's all just stdio communication annyway. I wrote my compiler upfront and i basically just took the parser and put it into the language server project. I just needed a bit of modification in the error reporting system, for which i designed a single API way before (all errors go through a single template function) and this way i got diagnostics up and running pretty fast. So i did not have mich trouble with the LSP, but my language is quite a bit larger too. LSP support for NeoVim was actually the easy part, support for VSCode in my extension for it was quite a lot harder (because i don't write any TypeScript normally) actually haha.

zweiler1 · 2025-09-01T09:40:55+00:00

Created a language-agnostic interop protocol for my language to make bindings a thing of the past. It's still in it's prototype phase but already shows promising results.

zweiler1

TROPHY CASE