4 ms·
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 un
by bjz_ 8y ago
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.
- AndyKelley 8y agoPlease 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.
- bjz_ 8y agoOh, 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 https://ziglang.org/documentation/master/#Optionals
- vmchale 8y ago> 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.
- stateoff 8y agoI 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 https://godbolt.org/z/eLWeU2 [1] https://ziglang.org/documentation/master/#Generic-Data-Structures https://ziglang.org/documentation/master/#Generic-Data-Struc...
- vmchale 8y ago> 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.
- oconnor0 8y agoI don't think I'd call Rust user friendly.
- vmchale 8y agoIf the problem is the type system/borrow checker, it's simply a question of experience.
- pjmlp 8y agoNot 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/after-nll-interprocedural-conflicts/ http://smallcultfollowing.com/babysteps/blog/2018/11/01/afte... http://smallcultfollowing.com/babysteps/blog/2018/11/10/after-nll-moving-from-borrowed-data-and-the-sentinel-pattern/ 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.
- pjmlp 8y agoI 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.