Maintain It with Zig

Post by gavinray » Thu, Sep 09, 2021, 3:40 PM UTC

kaba0 wrote: post #255

gavinray wrote: post #146

Earlier quoted context omitted.

Out of curiosity, have you written apps in both languages? I have written small applications in both. To be transparent: my total dev hours in D are probably somewhere around ~100, and in Zig about ~30. So I am more familiar with D than Zig, though competent enough with both to have written a few small real-world programs. > Its interoperability with C at the source and object level is first-class D has direct intero…

Is syntactical similarity or even compatibility to C a positive thing? Not taking away anything, D is a really cool language that definitely doesn’t get the fame it would rightfully deserve, I just think that breaking with some old habits (eg. postfix types with : are simply superior from a parsing perspective, and the pointer magic of C is just as terrible and the change in Zig is very welcome) when they are superse…

  // Count line length of stdin
  void main() {
      import std.range, std.stdio;

      auto sum = 0.0;
      auto count = stdin.byLine.tee!(l => sum += l.length).walkLength;

      writeln("Average line length: ", count ? sum / count : 0);
  }

  ----

  import std.algorithm, std.conv, std.functional, std.math, std.regex, std.stdio;

  alias round = pipe!(to!(real), std.math.round, to!(string));
  static reFloatingPoint = ctRegex!(`[0-9]+\.[0-9]+`);

  // Replace anything that looks like a real number with the rounded equivalent.
  void main(){
      stdin
          .byLine
          .map!(l => l.replaceAll!(c => c.hit.round)
                                  (reFloatingPoint))
          .each!(it => writeln(it));
  }

Post by ngrilly » Thu, Sep 09, 2021, 6:25 PM UTC

matu3ba wrote: post #185

ngrilly wrote: post #167

Earlier quoted context omitted.

Any plans to go one step further towards memory safety (and even better data race freedom)? Maybe using ARC when the overhead is acceptable (like Swift), it static analysis is not possible due to the type system not supporting the concepts of ownership, borrowing, lifetimes and so on? Zig is super exciting, but without a GC or Rust type system, I’m worried about going “back” to a language where I have to think about…

As of now the tradeoff of Rust's type system is that code may leak memory and you may need to investigate all occurrences to fix it, because there is no tooling yet (testing everything is infeasible). You can have either extensive static analysis or fast compile times. Tracking ownership down to semantic analysis (where type layouts are in resolved form) requires adjusting and slowing down the complete compiler.

Post by super_flanker » Thu, Sep 09, 2021, 6:50 PM UTC

amedvednikov wrote: post #254

super_flanker wrote: post #245

Earlier quoted context omitted.

> Can you list any claims that fell apart? On home page, the very first claim: > No null However V has `nil` or any reference can be initialized to `0`. How is then claiming `no null` not false?

There's no `nil` in the language, but indeed there's a hack that allows to assign 0 to references. It's on the 0.3 roadmap, high priority.

Post by AndyKelley » Thu, Sep 09, 2021, 7:29 PM UTC

flohofwoe wrote: post #248

steveklabnik wrote: post #12

Agreed for sure that working with C and C++ is the only way forward for systems languages. Rust's expression of this is the zero-cost C FFI, using native platform tooling, and stuff like that. Rust was never about re-writing the world, after all, its reason for existing was to eventually improve Firefox. The very first presentation about Rust ( http://venge.net/graydon/talks/intro-talk-2.pdf ) says "We are not “rewri…

Since Rust is built on top of LLVM, what's preventing it from "just" adding the Clang C/C++/ObjC frontends into the Rust compiler, and create cargo packages with cross-platform C/C++/ObjC headers and runtimes? This would make cross-compilation and C/C++/ObjC integration just as easy as with Zig (and without requiring any external C toolchain, which is the most important point). I guess the other (simpler) alternative…

Post by int_19h » Fri, Sep 10, 2021, 3:19 AM UTC

roca wrote: post #214

nyanpasu64 wrote: post #199

Earlier quoted context omitted.

Keep in mind that filesystem paths aren't strings. On Linux, they are raw bytes without any fixed encoding (but usually UTF-8 on UTF-8-based locales), and on Windows, they are sequences of 16-bit codepoints which are expected to be UTF-16 but not validated. Rust's OsStr is my favorite approach so far. It stores Linux's raw bytes as-is, and stores Windows's possibly-valid UTF-16 as WTF-8. This makes path management "j…

The difficulty of printing OsStr is nothing to do with Rust, it's really just the difficulty of printing Linux file names in any context given you don't know what the non-UTF8 bytes mean.