I like it in general, but i have a few comments:<p>1. "Data oriented. Just functions, structs and enums. NO: classes, inheritance, properties, etc."<p>I think you should allow for struct "inheritance", at least in an Oberon-style manner. There are many cases where having a common "head" between structs is useful (e.g. widgets for a GUI toolkit, object types for a scripting language, etc).<p>2. "Memory is initialized to zero. Array bounds are checked (can be turned off where needed)."<p>It is not clear from this, but how can both be disabled in a case-by-case basis? For example in D local variables are initialized to zero by default but you can do something like (IIRC): Foo foo = ? (or = nil, i do not remember) which the compiler interprets as "do not zero-initialize this). Similarly can i do something like array[foo] (bound checked) and array{foo} (non-bounds checked, imaginary syntax)?<p>3. "An LLVM backend is in the works which will avoid any undefined behavior."<p>LLVM inherits most of C's undefined behavior, so it will not solve your problem there - you'll need to explicitly generate code that works around undefined behavior. This is a problem that the Free Pascal developers also faced (the language has much less undefined behavior than what LLVM assumes).<p>4. I am not fan of the language enforcing code style (e.g. "The name of a type parameter must be a single uppercase character." and significant whitespace)<p>5. Nitpick, but "List<T> struct #RefType { dataPtr pointer count int capacity int }" is a dynamic array, not a list (also, an example of why significant whitespace isn't a great idea :-P)<p>6. "Type inference for function return values and locals"<p>I actually prefer to explicitly see the data types passed around, it helps better understand what exactly the code is doing (not just the algorithms, but also the data types which are important) without needing to have too much "implied code" in my mind (i.e. with explicit data types i don't need to "know" that "foo" returns "bar" when looking at its use in a diff (or any other non-syntax highlighted, non-code aware code viewing context), i actually know it because i see it in the code).<p>(FWIW for this reason i also dislike auto in C++ and similar constructs in other languages - you save a bit of short term typing now, for a lot of long term headache later)<p>7. "fgets(s pointer #As("char <i>"), size int, stream pointer #As("FILE </i>")) pointer #Foreign("fgets")"<p>I think you need to make your type system good enough to natively express C types, otherwise the string-based pseudotypes will bite you hard later when you want to move away from using C as a backend.<p>8. I do not see any mention of a preprocessor, how is code supposed to IFDEF stuff (like, e.g. a commercial program that needs to have something like IFDEF DEMO, or a source file that needs to behave slightly differently if linked as a static library or dynamic library, or the use of two APIs like e.g. IFDEF LINUX, IFDEF WIN32, IFDEF OPENGL, IFDEF VULKAN, etc) or work around language limitations (like the non-availability of inherited structs mentioned above that C programs often work around by using a macro that defines common elements for structs)?<p>9. "Number literal suffixes"<p>I'm not fan of the underscore in the suffixes and also i'd avoid the uppercase L and introduce an i (that is 'nop' but could be useful for automatically generated code via scripts and/or macros).<p>There are other minor nitpicks, but i'd need to actually check it in practice to write more :-P.