I note that at a glance Zig looks a lot like rust, as if you were inspired by rust but wanted a few things different. Thats a process I went through a while back, producing this language: example code https://github.com/dobkeratops/compiler/blob/master/example.rs repo https://github.com/dobkeratops/compiler
Maybe you could take a minute to flick through my preferences and intended use case and comment how many of my goals could be absorbed here (or are already delivered). I note this language has a few more syntax sugars here and there like ? for maybe, which is nice.
One of my key features was compatibility with the C++ overloaded naming , so it would have been possible to make a 2 way transpiler for a mutual subset. In that respect the project was similar to SPECS I guess, but I also took my favourite Rust features eg pattern matching/expression-based-syntax. I never got as far as self-hosting: the plan was to write that transpiler and run it on the compiler.
I gave up figuring that surrounding tooling (especially debugger integration and dot-autocomplete IDE) was too much for one person.
Idk if you read the following links already, but I'll point you to them just in case.
Why Zig When There is Already CPP, D, and Rust?
Zig Proposals
I link to these as there is a few feature of your language that you'll probably never see here.
Rust on the other hand is a little too restrictive; in particular I want to be able to think primarily in Functions & Structs - not classes,traits, or hierachical modules. Rust Traits are good but I'd prefer them optional & duck-typed. Rusts philosophy edges toward verbosity,'costs must be explicit' -IMO costs should be deterministic sure, but typing more for slow code doesn't make it faster- it wastes time on setup,tools,tests.. What is important is expressivity, ability to write optimal code more elegantly. Rust has to over-estimate safety to be sure. Some performant patterns are still safe, without being compile-time provable. empirical tests are usually good enough.
Your notes on Rust here are interesting. Zig (right now), is really all about functions and structs. Some dynamic dispatch/vtable mechanic have been discussed, but it seems far off. If it ever becomes a thing, I don't think Zig will turn into "Everything in std is a trait!" like Rust. As for the "costs must be explicit", I think Zig fall into this category as well. This is evident in Zigs philosophy "allocation is userspace" and "if it allocates, it should take an allocator". Zig is however not as scared of unsafe code as Rust is, so it is a lot easier to write your "Not compiler provable safe performant patterns".
Anyways, that was a little off topic for the question. As for features your language and Zig have in common:
comptime and first class types at compile time).I'll also take the time to comment on some of your "open questions" if they are related to Zig:
&const T)&const T automatically takes a pointer to the value, like C++ references. They are not derefed automatically.const or var (const is not immutability).const when possible.Idk if this answered anything useful. I'll let @andrewrk or another language guys look into which features could be "stolen".
Thanks for taking the time to read my long docs. So it seems there is indeed 'some overlap', but 'some divergence' .. as such the two worlds may be more different than the syntactic inspiration would first suggest.
I guess my "it should be transpileable" goal isn't shared; what I had done was wrote the compiler using very simple vtables i.e. "the base class is an interface", a vtable format - my idea was to support just that rather than all the C++ type hierarchy stuff.
My idea was that instead of needing a whole new language ecosystem, one should really be able to think about reskinning/cleaning up some C++, and integrating it much more closely (for reference see how closely Swift and Objective-C inter-operate r.e. the apple frameworks)
RAII - i've always seen this as good and indeed Rust also uses it to build abstractions (but I think I saw Defer in zig, and I'm guessing your inbuilt handling of Slices goes a long way to reducing what it needs)
I notice you have an IRC channel, i'd enjoy the oppornity to compare notes and ideas. My own language is (as you can tell from the repo) shelved - but I will definitely take some time to see if I can consider using this, which does seem to have more followers than I managed to get.
There is no "default" per say. Either you make a variable const or var (const is not immutability).
Minor correction here:
var x: i32 = 1234;
const y = &x;
// seems like y should be immutable, but you can still do
*y += 1;
// however the value y itself is immutable, the following is an error
y = &some_other_value;
I will definitely take some time to see if I can consider using this
If you find that you cannot use it after all, I would be very interested to hear where zig falls short of your needs.
Most helpful comment
Idk if you read the following links already, but I'll point you to them just in case.
Why Zig When There is Already CPP, D, and Rust?
Zig Proposals
I link to these as there is a few feature of your language that you'll probably never see here.
Your notes on Rust here are interesting. Zig (right now), is really all about functions and structs. Some dynamic dispatch/vtable mechanic have been discussed, but it seems far off. If it ever becomes a thing, I don't think Zig will turn into "Everything in std is a trait!" like Rust. As for the "costs must be explicit", I think Zig fall into this category as well. This is evident in Zigs philosophy "allocation is userspace" and "if it allocates, it should take an allocator". Zig is however not as scared of unsafe code as Rust is, so it is a lot easier to write your "Not compiler provable safe performant patterns".
Anyways, that was a little off topic for the question. As for features your language and Zig have in common:
comptimeand first class types at compile time).I'll also take the time to comment on some of your "open questions" if they are related to Zig:
&const T)&const Tautomatically takes a pointer to the value, like C++ references. They are not derefed automatically.constorvar(constis not immutability).constwhen possible.Idk if this answered anything useful. I'll let @andrewrk or another language guys look into which features could be "stolen".