Hacker News Reader

Comment by vmchale | Hacker News Reader

> modern language features that encourage inherent reliability and safety of code

It's still missing linear/affine types, no? To me that's inexcusable given the current offering.

I wouldn't say it's inexcusable, but I'm definitely trying to avoid any systems language that has implicit null, and allows for data races and de-referencing uninitialized memory from safe code. So that only really leaves ATS and Rust, and rules out Nim, D, Zig, Jai... (for me at least).

Zig certainly has some cool ideas - I definitely think that we should be making the phase distinction more flexible. I do wish however that its compile time function evaluation was built on a firmer foundation, ie. using dependent types.

Please don't spread misinformation. Zig does not have implicit null.

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

Oh, I must be mistaken then. So pointers are guaranteed not to be null? Can I mark pointers as nullable, and be forced to explicitly check?

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

> 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.

I think Andy refers to this [1].

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());
  }

Output being:

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

Edit: The compiler does the right thing:

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

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

> So that only really leaves ATS and Rust, and rules out Nim, D, Zig, Jai

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.

I don't think I'd call Rust user friendly.

If the problem is the type system/borrow checker, it's simply a question of experience.

Not when writing GUI like code, to the point that the Rust team acknowledges that additional work needs to be done after NLL lands on stable.

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.

There's always room for improvement, but speaking of GUI, gtk-rs is pretty usable already.

It is, if you don't mind sprinkling your code with Rc<RefCell<item>> everywhere, as means to access widget struct members in callbacks.

I find Zig much more user friendly than Rust. I have been able to do much more with Zig than Rust in one-tenth the time. I am not writing any code that requires the guarantees Rust may provide, and Zig seems to make it easier to write safer C-type code to boot.

Zig doesn't force you to free all your memory (which occasionally good), so there are whole classes of errors that Rust/ATS avoid that are possible in Zig.

I love GC enabled system languages since I used Oberon, and beyond trying to fit everything into a 64KB segment, bounds checking was never an issue for the type of code that I write.

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

"linear affine types" is an ambiguous term, but I believe Zig has them in the definition that you are using. Please be careful to get your facts correct. Misinformation is harmful to society.

I don't think either "linear types" or "affine types" (they're separate but related things) are ambiguous terms. Under linear typing, values must be used once, and under affine typing, at most once.

Could you clarify the ambiguity you see, and how Zig has them?

> "linear affine types"

It's "linear/affine types," not "linear affine types".

Also: Zig doesn't have linear or affine types. You seem to be quite confused about PL theory, which frankly does not make me any more confident in the language.

A little over the top with this criticism?

Or, the other one: lack of affine/linear types is "inexcusable", really?

As if these are so mainstream that any new language should have them? It's a new language, still in development, use it or not. Zig doesn't want to be a dumpster for trendy PL concepts. It has been designed to be a safer and friendlier C, not a simpler Haskell or Agda.

> given the current offering

Current offering being of course Rust.

Rust isn't a "simpler Agda" either. It is a safer C/C++ – as in bare metal capable, no GC, natively compiled… and affine types is what makes the safety possible.

> Rust isn't a "simpler Agda" either.

Calling Rust a "simpler Agda" is a bit insane. Rust simply has a sensible, current type system. Agda is full dependent types.

> Zig doesn't want to be a dumpster for trendy PL concepts. It has been designed to be a safer and friendlier C

Exactly why the project is pointless. It doesn't offer enough beyond C for there to exist any incentive to switch. I would add that affine types are not simply a "trendy PL concept" given that Rust has used them to great effect.

Reply on news.ycombinator.com