Also depending on how you define "dependent types" - there are a few competing definitions - Zig has them.

How is it ambiguous? Dependent type systems/algorithms can be weaker than desired, but there's no way you can say Zig has dependent types.

For example you can do:

  const std = @import("std");
  
  fn Int(comptime value: i32) type {
      return struct {
          pub fn value() i32 {
              return value;
          }
      };
  }
  
  pub fn main() anyerror!void {
      const int3 = Int(3);
      const int4 = Int(4);
  
      std.debug.warn("Types: {} {}\n", @typeName(int3),   @typeName(int4));
      std.debug.warn("Sum: {}\n", int3.value() + int4.value());
  }

  Types: Int(3) Int(4)
  Sum: 7

[2] https://godbolt.org/z/eLWeU2

[1] https://ziglang.org/documentation/master/#Generic-Data-Struc...

Although there are differing ways to define dependent types, and they come in different varieties (dependent functions, dependent pairs/structs, very dependent types, dependent intersections, inductive types), they are all founded on a foundation of type theory. I guess if you want me to clarify, it is 'dependent types based on a well understood foundation from type theory'.

---

Edit: seems like Zig does have optional types! That is a good thing! https://ziglang.org/documentation/master/#Optionals

So D, Nim, C# (AOT compiled), Java (Embedded/Android Things/MicroEJ), Swift, Go are pretty much on the table as well.

I don't have a problem with GC so Nim/D are on the table. ATS is a pain in the ass but after the arrival of Rust it's pretty clear that linear/affine types can be user-friendly. There's no excuse any more.

http://smallcultfollowing.com/babysteps/blog/2018/11/01/afte...

http://smallcultfollowing.com/babysteps/blog/2018/11/10/afte...

So while Rust is much more productive than ATS or Cyclone, there is still room of improvement for that experience.