A couple of questions and suggestions

[rempas]

First of all I would like to say that so far, Vox look so promising!!!! Your design choices are on point. A d-like language without a GC, a bloated runtime with even faster compilation times? I must be dreaming! First of all I would like to ask some questions and then proceed on giving some suggestions. Of course you should read this with caution cause maybe some of them may not be good ideas. So first of all I would like to give a little bit of background about me. You can of course skip it but you may be interested and it will help you understand with I'm so Hyped with Vox. Also keep in mind that I disited to write that here rather than getting in contact in private because there will be suggestions here (I hope you would consider some of them, lol) so it will be fine to stay here and also have other people saying their opinion.

My background
I started coding in about early 2020 (I kinda had some experience with Python but I don't count that). I feel really bad for saying that, but I don't think that I have made anything significant thorough this time. Which is really disappointing if you think that we are talking about a span of 1.5 years. Well I learnt TONS of stuff but didn't do a lot in practice. Were I wasted my time? Easy! 85-90% I was searching for my ideal programming language. I've come across tons of different languages but explain each one and saying why I didn't finally used them, would literally take paragraphs and paragraphs... From what you understand, I don't like the "Choose the right language for the right job" phrase. I want to learn only 1 language that will be able to do anything (even if it's not better in everything) and be a professional about it. Anyway let's see my ideal language.

My ideal language
I will go straight to the point. My ideal language compiles fast! Really fast!!! It should be able to have compilation times close to C (or even better). The performance should also be important. It should be at worse 2-3 times slower than C (again at worse). The syntax should not be bloated (not unnecessary and hard to read code) but still clear and not Python-like. And finally It should not limit me in anything or in general make my life harder (Yes Rust I'm talking about you).

Vox has the potential to be this language
Vox is not there yet (not in everything at leas) but it has an amazing potential. If we see that we have common goals, I would like to help and make the new TRUE replacement of C (C++ and D failed to do that)

Questions

1. How does Vox compiles so fast (faster than GCC, Clang) and still produces code that is 80-100% slower than optimized (-Os) gcc? Well tbh I don't know if that's the case, I just tried one example with fib numbers. Also only 35k loc? Man wtf!!!
2. Does Vox has an optimization flag or it does it out of the box (like Go)? You say that one of the goals is: "Maximize application performance" so I suppose you care about optimization right?
3. What's the current state o Vox? What has been implemented so far?
4. Is the memory only manual managed?
5. How the structs are implemented? Are they similar to C? Are they lighter and faster than C++/D classes/structs or?
6. Are there any feature that Vox has (or is planned to have) that C++/D doesn't?

Suggestions
Before I type the suggestions out, I just want to be very clear that I don't think like a spoiled user who demands what he has or else "I won't use your language". You have the final word and you will decide. Also like I said before, If we have the same views on some topics, I would also learn and join the development. Let's see:

1. DOCUMENTATION!!! Pretty much the most important thing imo. I'm talking about both user documentation and about developer documentation. The first one will come in time but I think that in this point the second one is more important as people should learn and how Vox is structured and how it works so we can contribute and improve the language. This will be really useful for people like me that want to help
2. Please allow people to make suggestion/feature requests just like I do now and not make it necessary to write a whole HUGE proposal like D does. This is really annoying and it takes a lot of time to write, review and finally get approved. YOU should be the only one to decide the direction of Vox and choose who will get implemented and what not. D is where it is now pretty much because of this (well not only because of that but the language doesn't have a direction).
3. Create a standard library that will be linked automatically (while having a flag to not link it). Let's make the library something between C++ and D in size with performance in mind so build directly on system calls rather than build on other functions like C++ (and D if I'm not wrong) does. I know this will take a lot of years to reach to this point but we gotta start right?
4. Package/Project manager. I mean we all know the C/C++ dependency hell...
5. Make a automatic memory management system (optional) based on some rules for when the memory is freed just like how Rust does it (but not having Ownership). If you are interested on this one, I could tell you my ideas.
6. Optional semicolon maybe? I think we can have the end of a statement to be the end of the line just like a lot of other languages. The semicolon can be used when someone want to have a lot of statements in the same line.
7. This a little bit of a detail thing but I think that you should also add words for types rather than just have things like "i32" because I think having numbers is a little bit distrusting. If not then maybe implement D-like alias where people can alias the type with the name they want (which would also be a great feature in general to beginning with). Also I think the the brackets look better after the name of the variable and it will also allow us to create multiple arrays of the same type with different sizes.
8. For the end, I would say that I would like to see a strong template system like Rust's macro rules which is SUPER flexible and powerful. However you have pointed out in the "README" that you care about strong meta-programming and the you plan to implement macros (WIP) so you probably already thinking about that.

Anyway that was all. I know it was huge and I hope you don't mind but I'm so so so excited! The fast compilation times where really what I was looking for. Any language with fast compilation time would either by 4-6 times slower than C or it would be C (which is fine but really annoying when you hit the limitations). So if everything goes as planned, I'll look up the code and I hope I can help as soon as possible! Thanks for your work and I hope Vox gets big (fingers crossed!)!

[MrSmith33]

Questions:

1. Language is simpler. Compiler is written from scratch, and with minimal dependencies, which means less stuff to worry about, and code does the minimum work. Data layout and memory management is optimized for speed. Less unneeded abstractions. Maybe less modularity. Of course there are even faster compilers like tcc (which is ~5x faster than Vox). Compiler runs in single thread atm, so there are some gains there + I could make an even simpler back-end for faster builds too.
2. There are a couple of internal settings to toggle some optimizations, but all optimizations are on by default atm. Very low number of optimizations are actually implemented rn: front-end does constant folding + IR generation with minimal control flow, back-end has inlining, primitive dead code elimination and medium complexity register allocation. The plan is to have a couple more common optimizations + intrinsics. So should be in 1x-2x from LLVM/GCC perf.
3. I would say that Vox is on C level + some extras atm. By extra I mean basic templates, some CTFE.
4. For now only manual management, but with templates one can write and use containers that will manage memory for you.
5. structs are basically the same as in D. POD + methods. No constructors though.
6. I think it is mainly meta-programming + CTFE. (Also compilation speed 😄)

Suggestions:

1. See internals.md for details on how Vox compiler is implemented. Of course it is not exhaustive, but I try to fill in the gaps from time to time. Please ask me if you want me to go in detail on something specific. Some bits of user documentation are in /spec/index.md, but that is mostly on stuff that is new to D users, not going in detail on basics.
   Worth mentioning that compiler itself compiles fast (4s) and test suite runs fast (70ms), which is important for working on the compiler itself.
2. Unnecessary bureaucracy is indeed harmful for the contributions, but this doesn't mean that not doing necessary research and analysis is a good idea. The steady progression zone is somewhere between those extremes.
3. On one hand I want to cover the need for exploratory programming, where you want to go fast with less quality (battery included mode). On the other hand the main use-case for me is game development, where you need 99% of control on everything. Another point is that I prefer conservative choices at the start and I don't trust myself to write a good general-purpose std lib. So, atm I write utility code for myself.
   There is also a point that without std lib the language is easier to embed.
   One option that I see is to have std lib be a regular package in package manager. This way it is both opt in and readily available. The most important goal for std lib is not to have common implementation, but common interfaces that many other packages can agree on.
4. Yeah, this is one of those problems where all solutions are kind of meh (you can include memory management and error handling in here). However I like the way Zig and Jai do this. Note, that it is actually 2 problems: package management + build system.
5. As I already mentioned, this is one of the generally unsolved problems for me. The path that I can envision in the future include allocator system a la Zig/Jai/Odin, automatic ownership like in Lobster and wholly inclusive system like in Cone
6. I'm 95% nope on that one.
7. This was a bit of uneasy decision for me to choose between D-style basic type names and more modern one. In the end I decided to use the one with bit sizes as more consistent option. Vox supports alias declarations like in D (syntax can potentially change).
   On the topic of brackets after variable name. If I understood correctly then you mean stuff like:

   i32 var1, var2[40];

   Which is referred to as spiral rule in C (see here). Modern languages moved away from this very big flaw of the C language. This is one of those decisions that I'm very confident about.
   Another thing that is currently unimplemented in Vox is ability to define multiple variables on the same line. I'm not a fan of doing opinionated things in the language, but I a) don't personally use those b) find it surprising when I encounter multiple definitions on one line, often missing the rest of the line. c) find it more readable when every definition is on its own line.
   So, I prefer this:

   i32 var1;
   i32[40] var2;

8. Some kind of code generation is definitely on the list. But the goal is to have in a more procedural way, so that it is both more like regular code and more performant to run.

Atm priorities are like that:

1. Compiler stability and bug fixes. There are a couple of places that are inexhaustible source of bugs, which need systematic solution. That includes node evaluation order problems and IR generation when dealing with aggregates.
2. Improving existing features
3. Adding new language features

Thanks for your feedback! Make sure to read internals/spec files, those contain most of the documentation I have so far. I hope for productive collaboration.
P.S. I will move this in Discussions tab if you don't mind.

Edit: forgot to mention 2 code bases that use Vox:

• https://github.com/MrSmith33/voxelman2 - which uses Vox embedded inside D host
• https://github.com/MrSmith33/rltut_2019 - which is pure Vox + SDL2 project

[rempas]

That was more than I expected! I will try my best to learn and help you fast! Thanks a lot for your time and effort