6 ms·

I don't know. C is very close to the hardware, and it's pretty portable, too. I'd suggest doing what some other languages do, and get yourself to the point wh

I don't know. C is very close to the hardware, and it's pretty portable, too. I'd suggest doing what some other languages do, and get yourself to the point where almost all of the code for Zig is written in Zig. In other words, you'd first write a `microzig` that's written in C++, and microzig knows enough to make `minizig`, which knows enough to make the rest of zig. This is what Perl does, and I expect other languages do the same thing. On the other hand, zig is supposed to be able to cross-compile really well, so maybe you can skip that: Have version 0.9.9 be the last version written in C++. Then, for version 1.0, re-write the entire toolchain in Zig, and use the 0.9.9 compiler to compile Zig 1.0. At that point you are in full dogfood mode. Finally, since it's called Zig, I get to close with this sentence: "You have no chance to survive make your time."

toomanybeersies 10y ago
AKA Bootstrapping: https://en.wikipedia.org/wiki/Bootstrapping_(compilers) https://en.wikipedia.org/wiki/Bootstrapping_(compilers)
dllthomas 10y ago
> C is very close to the hardware At this point, I'd more say that the hardware does an awful lot of work trying to look like it's close to C.
- bradhe 10y ago
  It's an interesting phenomenon, specifically how processor companies (erm, Intel), who make "general purpose" CPUs, have clearly made trade offs to optimize for OSes that behave like UNIX or Windows varients!
  - dbcurtis 10y ago
    Well, in fact, Intel and all the other major makers spend a huge amount of effort benchmarking important workloads. It isn't a decision to optimize for Unix or Windows, it is a decision to chase dollars. They will optimize processors for your favorite workload, too. Just demonstrate how many millions of dollars of business your workload represents, and create some sound benchmarks for it. Easy.
    - dman 10y ago
      Any information on how many millions before a workload becomes interesting to Intel/AMD/Nvidia?
  - jakub_h 10y ago
    Well it's certainly better than what they were doing before, trying to look like the iAPX 432 with their memory segments and all that stuff.
- deleted 10y ago
  [deleted]
- lohankin 10y ago
  This seems to be changing. Hardware is trying to move closer to java -by adding support of GC, bounds checks, etc - something that won't help C programs as much.
  - Sanddancer 10y ago
    Unfortunately, the C compiler devs didn't implement the bounds checking extensions of C11, etc. It would have been really nice to have a good checked C that was the standard.
    - pjmlp 10y ago
      Making it optimal is not a way to foster adoption.
      - dllthomas 10y ago
        Sounds like a great way, actually. ... I assume that you meant "optional".
        pjmlp 10y ago
        Yeah, every time I post to HN via mobile, my autocorrection plays such jokes on me, when I type in a hurry.
AndyKelley 10y ago
https://github.com/andrewrk/zig/issues/89 https://github.com/andrewrk/zig/issues/89 As long as we rely on libclang and LLVM there will be a part of the compiler written in C++, and I foresee these dependencies sticking around.
tom_mellior 10y ago
> C is very close to the hardware, and it's pretty portable, too. Here you seem to be suggesting that portability is good, but then... > zig is supposed to be able to cross-compile really well, so maybe you can skip that ... you seem to be suggesting that this project should give up its (already existing!) portability. Without saying why. In 2016, it's not clear at all why having having a compiled language be self-hosting should be considered a worthy goal. It's just a lot of busywork instead of simply using an existing toolchain. Certainly not the right thing to do from a software engineering point of view. Certainly not the right thing to do if you want portability. Certainly not the right thing to do if you want interoperability with existing sanitizers. Certainly not the right thing to do if you want powerful optimizations. I'd agree that the frontend should probably be bootstrapped, at some point. But the whole toolchain? Just to avoid random HN commenters throwing "every self-respecting programming language is bootstrapped" at you? Nah.

toomanybeersies 10y ago

AKA Bootstrapping: https://en.wikipedia.org/wiki/Bootstrapping_(compilers) https://en.wikipedia.org/wiki/Bootstrapping_(compilers)

dllthomas 10y ago

> C is very close to the hardware At this point, I'd more say that the hardware does an awful lot of work trying to look like it's close to C.

bradhe 10y ago
It's an interesting phenomenon, specifically how processor companies (erm, Intel), who make "general purpose" CPUs, have clearly made trade offs to optimize for OSes that behave like UNIX or Windows varients!
- dbcurtis 10y ago
  Well, in fact, Intel and all the other major makers spend a huge amount of effort benchmarking important workloads. It isn't a decision to optimize for Unix or Windows, it is a decision to chase dollars. They will optimize processors for your favorite workload, too. Just demonstrate how many millions of dollars of business your workload represents, and create some sound benchmarks for it. Easy.
  - dman 10y ago
    Any information on how many millions before a workload becomes interesting to Intel/AMD/Nvidia?
- jakub_h 10y ago
  Well it's certainly better than what they were doing before, trying to look like the iAPX 432 with their memory segments and all that stuff.
deleted 10y ago
[deleted]
lohankin 10y ago
This seems to be changing. Hardware is trying to move closer to java -by adding support of GC, bounds checks, etc - something that won't help C programs as much.
- Sanddancer 10y ago
  Unfortunately, the C compiler devs didn't implement the bounds checking extensions of C11, etc. It would have been really nice to have a good checked C that was the standard.
  - pjmlp 10y ago
    Making it optimal is not a way to foster adoption.
    - dllthomas 10y ago
      Sounds like a great way, actually. ... I assume that you meant "optional".
      - pjmlp 10y ago
        Yeah, every time I post to HN via mobile, my autocorrection plays such jokes on me, when I type in a hurry.

AndyKelley 10y ago

https://github.com/andrewrk/zig/issues/89 https://github.com/andrewrk/zig/issues/89 As long as we rely on libclang and LLVM there will be a part of the compiler written in C++, and I foresee these dependencies sticking around.

tom_mellior 10y ago

> C is very close to the hardware, and it's pretty portable, too. Here you seem to be suggesting that portability is good, but then... > zig is supposed to be able to cross-compile really well, so maybe you can skip that ... you seem to be suggesting that this project should give up its (already existing!) portability. Without saying why. In 2016, it's not clear at all why having having a compiled language be self-hosting should be considered a worthy goal. It's just a lot of busywork instead of simply using an existing toolchain. Certainly not the right thing to do from a software engineering point of view. Certainly not the right thing to do if you want portability. Certainly not the right thing to do if you want interoperability with existing sanitizers. Certainly not the right thing to do if you want powerful optimizations. I'd agree that the frontend should probably be bootstrapped, at some point. But the whole toolchain? Just to avoid random HN commenters throwing "every self-respecting programming language is bootstrapped" at you? Nah.