The backstory is interesting, though I wish it covered more the rationale behind the language and the thought-process that went into its design.
I especially like that track covers everything from switch statements to if-else statements in a nice concise way.
Curious if the 1 based arrays get confusing in @low mode.
As far as the benchmarks go, I didn't see, was there any other languages compared?
At some point, I began thinking that I wanted to create one programming language that could do everything. It was something I had wanted to make for a long time. I wanted it to be safe, flexible, simple, and fast.
I did not want to keep changing languages whenever I moved to a different part of a system. I did not want to constantly switch my way of thinking between different languages, syntax, and models. I wanted to be able to build everything within one language.
For the benchmarks, I intentionally chose not to compare X with other languages. I want X to be X, and I want the results to represent only what X actually produced. I do not want the benchmarks to be used for boasting that X is better than another language, or for speaking negatively about other languages. I want X to exist as its own language without competing with anyone. Readers can decide for themselves whether they want to compare the results.
For the names and syntax, my main goal was to make them as easy as possible. Even if a beginner knows almost nothing about programming, I want them to feel that the language is understandable, and to be able to guess what something means quickly.
I think that creating too many different syntax forms for closely related ideas forces people to remember too much. Reducing a group of related operations into one consistent form can reduce how much the user has to memorize.
More generally, I try not to create a new syntax form for every small variation. I think humans remember patterns more naturally than they remember many separate words and rules about exactly when each one must be used. A familiar pattern can continue to feel natural and simple even when the behavior behind it is still detailed and powerful.
The simplest summary of my design process is that I kept asking what people actually need, and thinking about the problems I experienced when I first started learning programming.
Like you said in your backstory, it's an awful shame to work so hard on something and have it get absolutely no attention.
I haven't tried out any of the code yet, but I'm curious enough to maybe try it sometime, especially since it has a robust FFI already. I had just uninstalled rust because I'm more of an old school C guy and don't like writing "safe" code.
Alien1Being•1h ago
Nothing in the repository seems to be over 4 days old.
x-xxx•1h ago
I developed X locally in folders on my computer and wasn't using Git or GitHub during most of the development. I created the public repository only when I was preparing to release it, so the Git history doesn't represent how long I worked on X.
jupr•57m ago
Unexperienced builders just use git as a save button.
Im not saying this is the right way to do things, but the measure of how much effort was put into something can't really be determined from the git history.
There are plenty of reasons to develop, then throw something over the wall, one being general privacy.