compare and contrast, my own pet language

[dobkeratops]

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.

[Hejsil]

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.

• RAII (destructors)
• function overloading+UFCS
• limited operator overloading (no conversions yet)
• new/delete

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:

• most C operators, functions, structs,if-else,
• 'everything is an expression' syntax (Well, mostly)
• rust-like 'enum/Match' - tagged-unions & pattern-matching (We only have switch on tagged unions)
• C for loops + break../else{..} expressions
• Forward+Reverse Type Inference within functions, (Now, I'm not well versed in the terms you use for type inference, and a quick google search didn't yield useful results. Zig has type inference on variable declaration, but not for type parameters to functions).
• templated functions & structs (Using comptime and first class types at compile time).
• emits LLVM sourcecode
• a systems language, 'for games'. no GC,zero overhead principle. (If you can write efficient games in C, then you probably can in Zig too).

I'll also take the time to comment on some of your "open questions" if they are related to Zig:

• inbuilt slice/vector types like .jai?
  • Zig have slices, and they are used extensively.
  • Vector is implemented in userspace (ArrayList)
  • Map is implemented in userspace (HashMap)
• default value passing behaviour especially * vs &, C++ vs rust..
  • Default is to pass by value.
  • Structs can't be passed by value and must be passed by const pointer instead (&const T)
  • &const T automatically takes a pointer to the value, like C++ references. They are not derefed automatically.
• this language wants immutable default, like rust.
  • There is no "default" per say. Either you make a variable const or var (const is not immutability).
  • It is however considered good style to use const when possible.
• its nice that Rust makes copy explicit (.clone()), as its' expensive
  • It has been discussed, and it seems it is a feature that'll come down the line.

Idk if this answered anything useful. I'll let @andrewrk or another language guys look into which features could be "stolen".

[dobkeratops]

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.

[andrewrk]

There is no "default" per say. Either you make a variable const or var (const is not immutability).

Minor correction here:

• it is planned to have an error for using var when you could have used const add an error for using var when one could have used const #224
• const does mean immutable. Maybe you're thinking of this situation:

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.