[HN Gopher] Goodbye to the C++ Implementation of Zig
___________________________________________________________________
Goodbye to the C++ Implementation of Zig
Author : nyberg
Score : 234 points
Date : 2022-12-08 20:53 UTC (2 hours ago)
(HTM) web link (ziglang.org)
(TXT) w3m dump (ziglang.org)
| iskander wrote:
| Naive question about Zig: is there any tooling for embedding it
| within larger Python codebases akin to Maturin (for Rust) or
| Nimporter (for Nim)?
|
| I have seen examples where the Zig code imports Python.h and uses
| low-level Python C API calls but I want something very
| lightweight for accelerating computational bottlenecks without
| worrying about unwrapping/wrapping data.
| shp0ngle wrote:
| > We provide a minimal WASI interpreter implementation that is
| built from C source, and then used to translate the Zig self-
| hosted compiler source code into C code. The C code is then
| compiled and linked, again by the system C compiler, into a
| stage2 binary. The stage2 binary can then be used repeatedly with
| zig build to build from source from that point on.
|
| Nope, no matter how many times I read this, I'm still lost.
|
| But then I never needed to care about VMs, compilers and
| bootstraps.
| Arnavion wrote:
| Read the "To summarize:" section a little after the part you
| quoted.
| gavinray wrote:
| Okay so we start from some C source code, and we build an
| interpreter for WASM + WASI from that (WASM that has access to
| system calls) C source -> WASM interpreter w/
| system access
|
| Now we can take the Zig self-hosted compiler (the one in .zig),
| which has been compiled to .wasm/.wasi files. Since we have an
| interpreter for those now, we can do this: Zig
| compiler as .wasi instead of .exe --> WASM interpreter -->
| Zig's "translate-to-c" function, for the .zig file sources of
| the Zig compiler
|
| E.G. $ run-webassembly "zig-compiler-as-
| wasm.wasi" --translate-c <source code to zig compiler>
|
| At this point, we have the Zig compiler as .c files. Now you
| can use GCC/clang or whatnot, to build a regular binary for the
| compiler Output of Zig's "translate-to-c" from
| previous step --> GCC/clang --> Zig compiler but NOT AS WASM,
| as a regular binary
| MrBuddyCasino wrote:
| how do you compile the Zig self-hosted compiler to wasm?
| capitalasset wrote:
| 1vuio0pswjnm7 wrote:
| Why not provide either hex editor or wasm as options. Let the
| user choose. The former is time-tested and has no ties to a
| commercial entity or the online advertising "business". Whereas
| the later has only been around since 2015 and was created by a
| company that subsists off an agreement with a deviant online
| advertising company.
| CharlesW wrote:
| > _Whereas the later has only been around since 2015 and was
| created by a company that subsists off an agreement with a
| deviant online advertising company._
|
| Mozilla created a precursor technology, but I thought Wasm was
| developed via the W3C standards process from the start. From
| the notes of the first meeting, you can see attendees from
| Adobe, Apple, Arm, Autodesk, Google, Intel, Mozilla, Stanford,
| and more.
|
| https://github.com/WebAssembly/meetings/blob/main/main/2017/...
|
| Additionally, Wasm has been a W3C standard since 2019.
| projektfu wrote:
| https://en.wikipedia.org/wiki/MLX_(software)
|
| Example of use:
|
| https://lparchive.org/Computes-Gazette/Update%2008/
| nektro wrote:
| you might be interested in https://github.com/oriansj/stage0 if
| you haven't seen it before
| kristoff_it wrote:
| > Let the user choose.
|
| The main user of this bootstrapping process are core
| contributors, normal users are still supposed to download
| prebuilt executables from the official website.
|
| Distro maintainers also are not the target user of this
| bootstrapping process, since it involves a binary blob provided
| by us.
|
| The real users of this procedure are Zig contributors, so that
| they can trivially build latest zig always, and without the
| annoyance of having to keep a C++ version of the compiler in
| sync with the main one. That's it.
| kalkin wrote:
| This is cool.
|
| I'm surprised that compiling a partial Zig backend to WASM and
| then compressing that ends up meaningfully smaller than compiling
| to C and compressing the C, when you include also the C partial
| WASM implementation and zstd decoder. This sounds kind of like a
| general strategy for compressing C code which I would not have
| expected to work well, but cool that it does!
|
| If AndyKelley ends up reading this - did you end up doing a
| direct comparison of "zig1.c.zstd + zstd.c" size vs the
| "zig1.wasm.zstd + zstd.c + wasm.c.zstd" set that you ended up
| with? If so, how did it turn out?
| AndyKelley wrote:
| I ran the command locally just now:
|
| zig1.c: 86 MiB
|
| zig1.c.zstd: 3.5 MiB
| kristoff_it wrote:
| I think it boils down to how bloated is the C code generated by
| the C backend, which to some degree has to be, since it's
| generated programmatically.
|
| My undestanding is what ends up happening is that the wasm step
| acts as a form of semantic compression that brings its own
| benefits over zstd (and which can still be combined with zstd
| by compressing the wasm file).
| nektro wrote:
| this is likely due to LLVM being involved in the WASM
| generation and it being able to perform all of its optimization
| steps before outputting code.
|
| whereas Zig's C backend has not yet gained the ability to
| perform all the same optimizations.
| titzer wrote:
| This is great. The more self-contained (really self-hosted) a
| language is, the more implementation freedom and ability to
| evolve it gets.
|
| For Virgil, version 1&2 were a Virgil->C compiler written in
| Java. Later, I wrote an interpreter for version 3 in Java and
| then began writing a compiler in version 3. When that compiler
| could compile version 3 (to JVM bytecode), I checked in the first
| "stable" compiler as a jar. Then periodically when enough new
| features and bugs were fixed, I checked in a new stable binary
| (jar). Later, I developed and eventually fully switched to native
| backends for 32- and 64-bit x86 on MacOS and Darwin. Today, 5
| stable binaries are checked in: jar, x86-darwin x86-64-darwin,
| x86-linux, and x86-64-linux.
|
| Initially I was worried that a codegen bug would prevent
| bootstrapping from a compiler binary and that I'd need to fall
| back to running on an interpreter. So far, there's never been a
| codegen bug bad enough to break bootstrapping, so I am not
| worried about this. The compiler never needs to bootstrap from an
| interpreter.
| torstenvl wrote:
| Glad to see Zig _move_ off C++ as it 's really _taking off_.
|
| (sorry, couldn't resist)
| wdb wrote:
| Nice, the biggest achievement for a new programming language is
| met :D
| randyrand wrote:
| > We provide a minimal WASI interpreter implementation that is
| built from C source, and then used to translate the Zig self-
| hosted compiler source code into C code.
|
| What do you use to compile the Zig source into C code? Wouldn't
| you need a Zig Compiler?
|
| I would have expected this?
|
| > We provide a minimal WASI interpreter implementation that is
| built from C source (i.e. so we don't need a Web Browser), then
| used to translate Zig Self-Hosted Compiler WASM code into C code.
| The Zig Self-Hosted Compiler WASM code is committed to the code
| base each time it changes, so when building a commit you already
| have the WASM source to a Zig compiler right there.
|
| > Of course, in the context of bootstrapping, this Zig Self-
| Hosted Compiler WASM source needed to be generated the first time
| at some point. For that first time, we used the C++ compiler to
| compile the Zig Self-Hosted Compiler from Zig into WASM.
| Yujf wrote:
| The Zig compiler gets compiled to WASM. The WASI interpreter
| runs the WASM binary to compile Zig to C.
| randyrand wrote:
| > The Zig compiler gets compiled to WASM
|
| This is the part I don't understand. In the context of
| bootstrapping, where does the Zig to WASM compiler come from?
| Laremere wrote:
| WASM is platform agnostic, so it is one of the things you
| start with, along with the compiler source code. It is
| built on a different computer before the bootstrapping
| process begins.
| defen wrote:
| This is a method of ensuring that _future_ builds do not
| depend on the existence of a Zig compiler; it 's not a way
| to go from 0 to Zig without a Zig compiler ever having
| existed. Technically this already existed in the form of a
| Zig compiler written in C++; the point of this exercise was
| to stop using C++.
|
| So:
|
| Presume the existence of a compiler that can compile Zig.
| Use that compiler to compile the written-in-Zig Zig
| compiler to WASM. Now you have a big chunk of WASM, so you
| also need a WASI interpreter. Write that in 4,000 lines of
| highly portable C. Then use that WASI interpreter to run
| your big chunk of WASM code and give it your written-in-Zig
| Zig compiler, and tell it to output C. Then compile that C
| code with your system compiler, and then use that native
| executable to recompile the written-in-Zig Zig compiler. At
| this point you should be at a fixed point and further
| recompilations of the Zig compiler will yield the same
| binary.
| deepsun wrote:
| > There is exactly one VM target available to Zig that is both
| OS-agnostic and subject to LLVM's state-of-the-art optimization
| passes, and that is WebAssembly.
|
| Honestly, sounds like old Java would also fit their requirements.
|
| There was a time when multiple languages ran for multi-platform,
| which is eased nowadays with containers and remote developer
| environments. So if their main concern is multi-platform, then
| feels like they want to look at the technologies developed at
| that time.
| brundolf wrote:
| From my understanding, the JVM is much more opinionated than
| webassembly (it has built-in GC, and I've heard it even has a
| notion of classes and related concepts at the bytecode level).
| Particularly for a low-level C-like language like Zig, it seems
| like a pretty bad match.
| kristoff_it wrote:
| > Honestly, sounds like old Java would also fit their
| requirements.
|
| Yes, it would, as would any other VM target. That said WASM is
| extremely convenient because it's a target that LLVM supports
| and because writing a VM for it (or something that compiles it
| to C) is easy. Java from this perspective seems way less
| convenient, as it would require us first to build a Zig backend
| for it, and then we would have to implement our own java
| intrepreter / aot compiler / ... for it.
| compiler-guy wrote:
| One reason (among many) to do this is because compilers require
| complex and demanding source code across a wide-range of theory
| and algorithms. And so make good tests for both the source
| language (is it sufficiently expressive to do this cleanly?) and
| for the various analysis, optimization, and code-generation
| passes.
| Decabytes wrote:
| I really like how when Andrew makes a decision about something
| related to Zig, he outlines how other programming languages do it
| and gives his thoughts.
|
| My question is. I feel like Zig is trying to do a lot of things
| that GO set out to do. To reduce a lot of complexity of programs
| by removing hidden control flow, macros etc. But how will Zig
| keep itself from repeating the mistakes GO made that make people
| dislike it?
| deepsun wrote:
| Zig doesn't offer garbage collection. And also no Rust's
| complex memory tracking. So it's doesn't really free you from
| memory-related bugs, just like good-old C. But it's a "better
| C" IMHO.
| tines wrote:
| I haven't used Zig at all, but doesn't the fact that Zig
| supports from-what-I-understand pretty powerful metaprogramming
| facilities already put it way ahead of Go in that regard?
| AndyKelley wrote:
| Thank you for the compliment.
|
| I have some interesting news for you... Go is a smashing
| success, wildly popular, and eating Java's lunch. It is an
| objectively incorrect generalization to say that people dislike
| Go.
| acedTrex wrote:
| > It is an objectively incorrect generalization to say that
| people dislike Go
|
| It is not, people USE go, they do not like go really.
| lordgroff wrote:
| Really? I like Go, I might even love it.
| phinnaeus wrote:
| I like Go
| [deleted]
| thadt wrote:
| This is true, I don't really like Go. After years of
| writing code in Assembly, C, C++, Perl, Basic, C#, Java,
| Python, Rust, JavaScript, TypeScript, Lua, Zig, and Go I
| find that what I _really_ like is good tooling, and code
| that is easy to read and reason about. Go the language and
| toolset happen to do this really rather well at the moment
| though.
| bmurphy1976 wrote:
| Nonsense. I love it and I've been programming since the
| 80's.
|
| I watched (and used) C++ as it grew into the monstrosity it
| is today. I've written and maintained production code in
| F#, C#, Python, Ruby, Perl, Java, JavaScript, Go, PHP, Lua,
| VBScript, Visual Basic, C, and C++ and every variant of
| shell scripting imaginable.
|
| I've spent time working with Erlang, Haskell, Rust and a
| variety of other exotic languages because I found it
| interesting. I created a port of Clojure's Transducers to
| C# because I could.
|
| I am not afraid of abstractions, functional programming, or
| complicated CompSci concepts. And yet I keep going back to
| Go.
| pa7ch wrote:
| Agreed, go has kept me liking programming because, for me, it
| most the most reliable tool for making trustworthy software.
| All langs have tradeoffs and areas they excel in but go
| brings me the most joy/motivation.
|
| Its nice to see a language with similar philsophies tackle
| the space where go isn't as good at: when you don't want a GC
| and you need to interface with C. For many that is Rust and I
| respect it, but I think Rust values concurrency "safety" too
| high and makes too many compromises in language design to
| achieve it. Memory safety is a BIG deal to me, without it,
| sufficiently complex software has never ending CVE's but
| concurrency bugs just doesn't cause anywhere close to the
| same number of security problems (orders of magnitude) and
| crashing programs is fine in most applications and I find
| concurrency bugs usually are easy to fix early in application
| lifecycle.
| zozbot234 wrote:
| Rust only protects against data races, not general
| concurrency bugs.
| pron wrote:
| Whoa, slow down there :) Go is certainly a success in
| absolute terms, making it to the top ten in some rankings,
| but at age 13 -- an age when virtually all languages have
| either reached or neared their all-time peak with only a
| single exception I can think of -- it's only ~1/10th as
| popular as Java [1][2], and not eating nearly as much of its
| lunch as PHP or Ruby did back in the day.
|
| [1]: https://www.devjobsscanner.com/blog/top-8-most-demanded-
| lang...
|
| [2]: https://www.hiringlab.org/2019/11/19/todays-top-tech-
| skills/
| AndyKelley wrote:
| Fair point! Thank you for adding nuance to the discussion.
| auggierose wrote:
| What is the exception?
| clord wrote:
| Certainly Haskell is an exception; it has a distinct
| bimodal distribution, if not more.
| bmicraft wrote:
| I pretty sure that would be python
| [deleted]
| azakai wrote:
| 1/10th as popular as one of the by-far most popular
| programming languages of all time is still a huge success
| story.
| WalterBright wrote:
| It was a good day when we finally removed 100% of the C and C++
| code from the D compiler and all of the runtime library
| (including the memory manager). The assembler code uses D's
| inline assembler.
|
| The _test_ suite has C code in it, because of course D can
| compile C code.
| Kukumber wrote:
| I fail to understand how this is a good idea
|
| Looks like they regret writing their compiler with C++, are too
| lazy to rewrite it in C, so they go with WASM to them automate
| the conversion to C, loosing a lot of source information and
| readability in the process
|
| That doesn't seems like a good idea
|
| If your code is so bad that your compiler is memory hungry and
| slow, you should either rewrite it or optimize it
|
| Or perhaps let someone else write the compiler for you if you
| don't know how to make a fast compiler
| [deleted]
| lifthrasiir wrote:
| Assuming you are genuinely not aware of language implementation
| processes, this is called bootstrapping. You may want to
| implement a language A in A (a very common goal!) but this is
| generally impossible when you don't have a compiler for A, so
| you first write an implementation of A in an already
| implemented language B, and then use that implementation to
| write an A implementation in A, abandoning the initial
| implementation at the end. Zig just did this.
| kaba0 wrote:
| I'm not the parent commenter, but I will be honest -- I fail
| to understand the purpose of bootstrapping low-level
| languages. Like, if you just were to given a task to write a
| compiler, would you honestly choose Zig? No. Then why don't
| have the compiler be written in Haskell or whatever high-
| level language where writing code is actually productive and
| not error prone, since it is not a performance-critical
| application?
|
| EDIT: since my performance critical sentence is getting
| misunderstood: https://news.ycombinator.com/item?id=33914718
| nyberg wrote:
| Compilers are performance critical in the sense that you
| wouldn't want to wait 15 minutes to an hour for your code
| to build. Consider the number of layers of cache applied to
| compilation pipelines along with distributed builds to
| speed it up in places where they have millons of lines of
| code (e.g game studios) along with turning off linker
| features which slow things down.
|
| You'd want faster compilation so that you can test your
| changes without it breaking your flow where having to wait
| a 1-5 minutes means you'll end up reading HN or checking
| chat for 10 or so minutes. That's also why there's interest
| in hot-code reloading and incremental linking to make it
| faster as it will further reduce compilation to just the
| changes you've made and nothing more.
| kaba0 wrote:
| There is no significant difference between managed
| languages and something like zig in this category of
| programs, it is not a video codec, so I stand by my "no
| performance sensitive" claim. And especially because
| algorithms matters much much more, there is a good chance
| that a faster one can be implemented when you don't have
| to care about whether that memory location is still alive
| or not.
| kristoff_it wrote:
| You might be interested in this talk from Andrew:
|
| https://media.handmade-seattle.com/practical-data-
| oriented-d...
| dralley wrote:
| The Zig developers would strongly disagree that a compiler
| is not a performance-critical application, and they would
| also probably disagree that Zig doesn't bring anything to
| the table when it comes to writing compilers.
|
| As a generalization, the people who are motivated enough to
| work on a language, want to use that language. It's only
| natural that they would want to write their compiler in
| that language too, if practical. Contributors to the Zig
| project would on average probably be more proficient and
| productive in Zig than they would be in a language they
| don't care about so much.
|
| It's also just helpful to have the people who are designing
| the language working in that language regularly in the
| context of a sizable and nontrivial project.
| grumpyprole wrote:
| > The Zig developers would strongly disagree that a
| compiler is not a performance-critical application,
|
| Have they written am incremental compiler then? Or just
| an old-fashioned slow batch one? Compiler architecture
| matters much more than whether it's runtime has a GC or
| not.
| RussianCow wrote:
| What does that have to do with the choice of programming
| language? You can't implement an incremental compiler in
| Zig?
| grumpyprole wrote:
| > What does that have to do with the choice of
| programming language?
|
| It's more important than the choice of programming
| language. Not all C++ is fast.
|
| > You can't implement an incremental compiler in Zig?
|
| I never said this. This is a thinly veiled ad hominem.
| dralley wrote:
| Yes, that is something they care about
|
| https://kristoff.it/blog/zig-new-relationship-llvm/
|
| https://mobile.twitter.com/andy_kelley/status/15651098597
| 708...
| grumpyprole wrote:
| Glad to see it and more important than implementation
| language I think.
| nkozyra wrote:
| [ as someone who does not work in language design ] - it
| does feel sometimes like this achievement is more a source
| of pride than a hard requirement. A sort of symbolic (no
| pun) closing of the circle.
|
| Is there a reason why keeping a compiler in, say, C would
| be a bad idea long-term?
| fanf2 wrote:
| As TFA says, the Zig developers did not like having to
| implement features twice.
| garganzol wrote:
| Every good language has a compiler developed in that
| language. This creative process is called dogfooding [1].
|
| [1] https://en.wikipedia.org/wiki/Eating_your_own_dog_food
| lifthrasiir wrote:
| Dogfooding is not always related to bootstrapping. In
| fact, this is a reasonably common pitfall for language
| designers, because language implementations are very
| specific and if you _only_ tune your language for them
| your language will of course need ADTs and generics and
| value semantics and GCs. Not to say that those are great,
| but you may have missed a whole slew of possibilities by
| doing so! And that 's why you can do dogfooding without
| bootstrapping---you can instead have other big enough
| software written in your language and coevolve with it.
| For example Rust did this with Servo.
| dralley wrote:
| I think that's probably an overstatement considering it
| would exclude languages like Python, Ruby, etc.
| Kranar wrote:
| Not sure about Ruby but pypy is a pure Python
| implementation of Python:
|
| https://www.pypy.org/
| dralley wrote:
| It's not the implementation that 99.9% of people use,
| though.
| Kranar wrote:
| The original poster never claimed that it was; the only
| claim is that good programming languages have
| implementations in that language.
| lifthrasiir wrote:
| I'm of course not Andrew Kelley ;-), but I think it's
| strategic. C++ would be indeed less productive than Haskell
| when you write a language implementation, but if the target
| audience---at least initially---already knows C++ then
| writing a compiler in suboptimal languages may help. I know
| this is not universally applicable; for example Rust
| bootstrapped from OCaml, but it has achieved self-hosting
| very early in its life (and back when the goal of the
| language was not yet certain), so that might have been also
| strategic.
| grumpyprole wrote:
| Writing the initial compiler in C++ is a rather
| surprising choice. My time would be too precious for
| that. OCaml was a good choice from the Rust devs and had
| a nice influence on the language. Rust has proper
| algebraic data types and pattern matching.
| TUSF wrote:
| They wrote it in C++, because llvm is in C++. Currently
| the only critical parts of the Zig compiler that are in
| C++ are the bindings to llvm and I think stuff for
| linking clang.
| emef wrote:
| how are compilers not performance-critical applications?
| kaba0 wrote:
| I was sure that sentence would not be clear.
|
| Today's managed languages are very fast. For example, if
| Java is not fast enough for your HFT algorithm, than nor
| is C++ or generic CPUs even! You have to go the custom
| chip route then. Where there is a significant difference
| between these categories is memory usage and
| predictability of performance. (In other applications,
| e.g. video codecs you will have to write assembly by hand
| in the hot loops, since here low-level languages are not
| low level enough). Since these concerns not apply to
| compilers, I don't think that a significant performance
| difference would be observable between, say a java and
| zig implementation of a certain compiler.
| derekp7 wrote:
| Think of porting to a new CPU architecture. If you have
| your compiler written in its own language, then when you
| add support for the new CPU target you can compiler your
| compiler using your compiler and target the new CPU. Now
| you have a compiler that not only produces code for the new
| CPU, but you have one that also runs on that CPU.
|
| The alternative would be to port your Haskell compiler to
| the new CPU too in order to set up a self hosting
| toolchain. Much more work involved, because you not only
| have to be proficient in Haskell, but you need to have
| Haskell compiler implementation skills in addition to your
| own compiler.
| kaba0 wrote:
| Well, this might be a valid reason, especially given that
| embedded is important for Zig's target domain. (Though,
| is there all that many new architectures nowadays?)
|
| Thank you!
| rtfeldman wrote:
| As far as I can tell, the main reason we all spend so much
| time waiting for compilers is that compilers aren't
| considered as performance-critical as they should be.
|
| My full-time job is making a compiler for a high-level
| language, and I only considered systems languages (e.g.
| Zig, Rust) as contenders for what to write it in - solely
| because compiler performance is so critical to the
| experience of using the compiler.
|
| In our case, since the compiler is for a high-level
| language, we plan never to self-host, because that would
| slow it down.
|
| To me, it seems clear that taking performance very
| seriously, including language choice, is the best path to
| delivering the fastest feedback loop for a compiler's
| users.
| kaba0 wrote:
| If I were to give a bad faith argument, I would say that
| Rust's compiler, while being written in Rust is not
| famous for its speed (but I do know that it is due to it
| doing more work).
|
| I honestly fail to see _why_ would a lower level language
| be faster, especially that compilers are notorious for
| their non-standard allocation and life cycle patterns, so
| a GC might actually be faster here.
| zozbot234 wrote:
| The slow part of Rust compiles is LLVM, though some of it
| may be due to bloated IR input that's a frontend concern.
| There's an alternate cranelift-based backend that's
| usable already if runtime efficiency is not your
| priority.
| kaba0 wrote:
| But LLVM is written in C++ so "should be fast" based on
| language choice only.
|
| Didn't know about that backend though, will check it out,
| thanks!
| sanxiyn wrote:
| LLVM's fast path (used by clang -O0) is fast. Rust's
| primary problem is that it can't use LLVM's fast path
| (because it implements only a subset of LLVM IR) and LLVM
| upstream is uninterested in extending it because it will
| slowdown clang -O0.
| tobz1000 wrote:
| Compilation can be very intensive, and it's detrimental to
| a developer's workflow if they must wait for long
| recompiles.
|
| Rust was originally written in OCaml before being self-
| hosted, and it wouldn't be as fast (or would be even slower
| ;) ) today if it was still OCaml.
|
| And remember, low-level =/= poor abstractions. I think
| there are several novel abstractions available in Zig which
| the compiler devs probably want to make use of themselves.
| kaba0 wrote:
| > low-level =/= poor abstractions
|
| They might have good language abstractions, but manual
| memory management is simply an orthogonal implementation
| detail to solving a problem -- dealing with that is
| simply more work and more leaky abstractions.
| rollcat wrote:
| > Like, if you just were to given a task to write a
| compiler, would you honestly choose Zig? No.
|
| Actually, yes.
|
| A compiler is not just a dumb filter that eats text and
| spits out machine code. It can provide infrastructure to
| other tools (like linters, analyzers, LSP servers...), and
| even allow importing and using parts of it in user
| programs.
|
| Some of this can't be done in a different language (like
| Haskell) without some very crazy FFI, and might add an
| extra runtime dependency for those tools, which might not
| always be desirable.
| peatfreak wrote:
| Thank you for this comment, I only wish it was at a
| higher level up in this thread.
|
| The number of ignorant comments in this thread is
| astounding. All this criticism feels like it was written
| by back-seat drivers who have no clue about the
| complexities of language design or compiler
| implementation.
| satvikpendem wrote:
| > _Like, if you just were to given a task to write a
| compiler, would you honestly choose Zig? No._
|
| Why wouldn't you? I understand why not for high level
| languages like Python or Ruby (since they're interpreted)
| but not for low level ones. Rust for example is also
| bootstrapped.
| slt2021 wrote:
| Even for python there is pypy.
|
| Bootstrapping is actually a very old tradition that any
| programming language must implement in order to showcase
| the power of language.
| Kukumber wrote:
| They didn't abandon the initial implementation, it's compiled
| to WASM then converted back to C
|
| I maintain what i said, i do not understand how this is a
| good idea
| cogman10 wrote:
| Not quiet.
|
| They are compiling the current compiler to wasm and then
| using that compiler to build future versions of their
| compiler.
|
| In other words, they are doing the described rust approach
| but instead using a platform agnostic target instead of
| doing a binary. That allows them to build on any platform
| that has a C compiler and to use current language features
| without needing manually backport them.
|
| They could directly target C or C++ but that runs a greater
| risk of accidentally generating UB. Targeting a bytecode
| decreases that risk.
| fanf2 wrote:
| The WASM is built from the second Zig compiler written in
| Zig, not the initial C++ compiler.
| dottedmag wrote:
| They did.
|
| WASM file is produced by compiling new compiler, one
| written in Zig.
| jeremycw wrote:
| I think you need to be a bit more humble on a topic that's
| clearly going over your head.
|
| Imagine a scenario where you are testing out a brand new
| RISC-V development board. The vendor has only provided a C
| compiler for this board as is often the case. You want to
| be able to use the zig language to write programs for your
| new development board but no zig compiler exists for this
| board yet. That means you need to compile the zig compiler
| from source. The latest version of the zig compiler is
| written in zig. Again you don't have a zig compiler so how
| will you compile the zig compiler from source? You need a
| way to go from C compiler to Zig compiler. That's what this
| is describing. It does not make sense to maintain two
| completely separate versions of the compiler. The "real"
| one written in Zig and the "bootstrap" one for compiling
| from C. So the zig source is compiled into WASM and stored
| in the repo. On a system with only a C compiler this WASM
| can be ran instead of a native zig binary. The WASM version
| can then be used to compile an actual native zig binary.
| lifthrasiir wrote:
| That's not "converting back", because by going through
| WebAssembly you have restricted the language. As long as
| you have a correct wasm-to-C implementation this is a valid
| strategy to finish the bootstrap---you no longer depend on
| C, just WebAssembly.
| Dwedit wrote:
| How common is the need for bootstrapping when you have cross-
| compilers?
| kristoff_it wrote:
| The main use case here is not as much building Zig for an
| new architecture, as it is a way to let contributors build
| latest Zig trivially.
|
| Without a bootstrap process like this one, it could happen
| that you run git pull and then can't build the compiler
| because it's using a new feature that the version of the
| compiler you have doesn't support yet.
|
| The wasm process ensures that you can always build the
| latest commit.
| fantyoon wrote:
| The need for bootstrapping in this context comes from the
| lack of a compiler for the language you want to implement,
| as in before the Zig compiler in C++ there was no Zig
| compiler.
| skitter wrote:
| If you want to have a Zig compiler written in Zig, you need
| to bootstrap it once initially. Cross compilation makes it
| so you don't need to do that again when you want the
| compiler to work on a different architecture. Of course,
| there's the question of why you want to self-host your
| compiler (instead of keeping the C++ one): - dogfooding
| identifies problems & helps prioritizing - it demonstrates
| that the language is suitable for serious projects - most
| importantly, Zig developers prefer writing Zig over having
| to use C++
| kzrdude wrote:
| gcc bootstraps using itself. Rust bootstraps using itself.
| Go bootstraps using itself. D bootstraps using itself. Zig
| bootstraps using itself. It seems pretty common :)
| lifthrasiir wrote:
| Cross-compilers are about target platforms (e.g. producing
| a macOS executable from Windows). We are talking about
| implementing a language in a different language. (The word
| "bootstrap" is very general and can be used for both
| cases.)
| YoumuChan wrote:
| I don't think people really care about "source information and
| readability" too much towards intermediate building files.
| otikik wrote:
| I hope you use this as a learning opportunity in the future
| because that was a really bad take.
| nyberg wrote:
| The issue is mostly maintaining two diverging compilers as
| every feature needs to be implemented twice. Thus, by removing
| the C++ compiler the project gains from only needing to
| implement new features once and thus lowers the maintainance
| burden of keeping the two in sync.
|
| It's not that they're too lazy to rewrite this in C but rather
| that it's impractical when there are still breaking features to
| be implemented.
|
| Also the process is `zig -> wasm blob -> c -> zig` where
| they're not commiting C source code to the repository at all,
| it's just used as a stepping stone to compile the real compiler
| from the bootstrap compiler.
| garganzol wrote:
| WASM allows them to bootstrap Zig compiler on completely
| foreign systems that only have a C compiler. This solves the
| chicken-and-egg dilemma that occurs when one wants to use a
| language under development to develop the language itself.
|
| It's not about code size or efficiency. They are talking about
| the ability to use the latest versions of Zig for further
| development of the Zig compiler. This improves and speeds up
| the compiler development cycle by removing the limitations
| imposed by the bootstrap process.
| Kukumber wrote:
| That's exactly what i said, they regret writing their
| compiler in C++, and are too lazy to do a proper and
| optimized C rewrite, hence they go with WASM to then generate
| C code
|
| Reason why it still is running poorly, because it is the same
| implementation, just went with optimized code gen steps,
| making the source non human readable
|
| Seems like i was right when i made this comment few days ago:
| https://news.ycombinator.com/item?id=33763102
| kllrnohj wrote:
| > they regret writing their compiler in C++, and are too
| lazy to do a proper and optimized C rewrite
|
| lol, very few things migrate from C++ to C. Rather they do
| the reverse (like how GCC migrated from C to C++).
| garganzol wrote:
| Nope. The ultimate goal is to develop Zig in Zig. C and C++
| are not the goals, they are means.
| derekp7 wrote:
| Just so you know, the reason your comment isn't productive
| (especially with the culture of this site) is that your are
| creating a projection of the developer's mind and
| motivations, that most likely isn't true (I doubt they are
| lazy, and I also doubt there is regrets there too).
| moloch-hai wrote:
| Please identify a system where you might want to run a
| compiler, and there is no C++ compiler for it.
|
| There are of course many places you might run code that
| cannot host a compiler for any language. You use a cross
| compiler for those.
| satvikpendem wrote:
| Are there not a lot of embedded systems that only have a C
| compiler?
| moloch-hai wrote:
| You want to run a Zig compiler on an embedded system?
| josephg wrote:
| The fact that basically every platform has a working C
| compiler is why this approach works.
|
| The benefit of this compared to the previous approach is
| that the developers no longer need to maintain a second
| compiler written in C++.
| moloch-hai wrote:
| They have only ever needed to maintain the one, original
| compiler. The one in Zig is the second one, and is not
| strictly needed at all.
|
| There was a time when self-hosting your language made
| sense.
|
| I did notice that you did not identify the system which
| can run a C compiler but cannot run a C++ compiler.
| mwcampbell wrote:
| > There was a time when self-hosting your language made
| sense.
|
| Why doesn't it now?
| jesse__ wrote:
| I don't follow the zig community particularly closely, but from
| what I can tell 'too lazy' is not an accurate description of
| many people that are part of it, and certainly not the compiler
| author(s).
| garganzol wrote:
| This use-case shows a big potential of WASM. Just imagine how we
| would run a 50 years old software in year 2072 thanks to WASM and
| WASI standards.
| kristoff_it wrote:
| It just so happens WASM is the one VM target that LLVM
| supports. Sure, it's a nice VM that can be implemented without
| too much fuss, and ditto for WASI, but that's it. It's just the
| most convenient VM to target for us.
| spullara wrote:
| The Zig implementation is 3x the C++ implementation? That is
| surprising.
| civopsec wrote:
| Apparently it is just used to build the main compiler from
| source, so perhaps less featureful.
| AndyKelley wrote:
| Features that the new compiler has which the C++ implementation
| lacked:
|
| * The ability to translate C code into Zig
|
| * A caching system
|
| * A Mach-O linker, ELF linker, COFF linker, and WebAssembly
| linker
|
| * Logic to build musl libc, mingw-w64 libc, and (dynamic) glibc
| from source, as well as libunwind, libc++, libc++abi
|
| * Liveness analysis
|
| * A documentation generation system (Autodoc)
|
| * An x86_64 backend, aarch64 backend, WebAssembly backend,
| RISCV-64 backend, arm backend, SPIR-V backend, and C backend
| acdha wrote:
| I wouldn't be surprised if it had some more advanced
| optimizations or similar things which don't affect
| compatibility but also note there's one trailing clause in the
| description: "plus sharing Zig code with the new one". I'd be
| curious exactly how much code could be reused across the two
| like that -- it doesn't seem like it should be _that_ much
| because they were trying to do this to avoid commonly needing
| to implement things in two places.
| nektro wrote:
| there was a lot of code shared between the implementations
| cosmic_quanta wrote:
| I imagine it has more features. Maybe more optimizations, for
| example.
| kristoff_it wrote:
| If after reading the post you're still unsure about why we're
| going through this process, I made a video that focuses more on
| the reasons from the perspective of a Zig contributor, showing
| how the bootstrapping process helps contributors on their day to
| day tasks.
|
| https://youtu.be/MCfD7aIl-_E
| KingLancelot wrote:
| Decabytes wrote:
| I have honestly been more excited about Wasm for desktop than I
| am for the web. And I'm really excited about it for the Web.
| Really cool to see this use case pop up right as I'm trying to
| integrate it into my stack!
| throwaway894345 wrote:
| I've never really thought about wasm for the desktop (I've
| thought about it for server and of course browser), can you
| elaborate on your excitement? Is it just for this sort of
| bootstrapping application, or are there other benefits?
| als0 wrote:
| Write once, run anywhere... but this time the dream will come
| true!
| henry_viii wrote:
| Could someone explain to me why Zig is getting hyped so much on
| HN? From a quick glance it looks like Zig is memory-unsafe like
| C/C++. I thought the macro trend was moving onto memory-safe
| languages:
|
| https://news.ycombinator.com/item?id=33819616
|
| https://news.ycombinator.com/item?id=33560227
|
| https://news.ycombinator.com/item?id=32905885
|
| What innovation does Zig bring that I'm missing?
| detaro wrote:
| Not everyone thinks that macro trend is the most important
| thing ever and Zig is an interesting spin on a low-level
| language/a better C.
| nektro wrote:
| it's perfectly possible to make memory safe programs in Zig.
| there are many an innovation that Zig brings to the table
| AaronFriel wrote:
| That isn't really an interesting statement, it's perfectly
| possible to make memory safe programs in C or assembly. The
| question is, how easy is it it to ensure a program is memory
| safe in Zig?
|
| The trend toward memory safety is marked by languages and
| tools making it harder to inadvertently write exploitable
| code, and easier to verify that the program is not
| exploitable. My understanding of Zig is that while it does
| _some_ of the same things as so-called memory safe languages,
| it is not a "memory safe language" in the same sense as they
| use the term.
| WalterBright wrote:
| D has steadily moved towards full memory safety. The one
| remaining thing is dealing with manual storage allocation, and
| D has a prototype borrow checker to address that.
| civopsec wrote:
| The compile-time features and the fact that you have to use
| allocators explicitly are interesting things. Other than that
| there's nothing else there, for me. But it's turned out to be
| more interesting than when I first saw the first blog post
| about intending to start on this language.
| adamgordonbell wrote:
| This article here deserves attention because its interesting
| and counter-intuitive even if you don't use Zig. It's a story
| of problem solving.
| kristoff_it wrote:
| > I thought the macro trend was moving onto memory-safe
| languages
|
| I guess some people like to Zig when others zag :^)
| bachmeier wrote:
| Apologies, but I can't resist reposting a comment I made on a
| different story earlier today.
| (https://news.ycombinator.com/item?id=33910750)
|
| > > Your personal experiences make up maybe 0.00000001% of
| what's happened in the world but maybe 80% of how you think the
| world works.
|
| > This explains every online discussion about programming that
| has comments invoking "toy problems" and "in production".
| flumpcakes wrote:
| What do you mean by memory safe? This line is trotted out all
| the time but no one defines what they actually mean. Is Go
| memory safe? Rust is not a "memory safe" panacea. You can write
| memory unsafe code in Rust.
|
| Zig also has a much better developer experience around "memory
| safety" compared to C/C++. It really is an interesting
| alternative to writing something in C. You can compile it in
| debug mode and get out of bounds checks, for example.
| stephc_int13 wrote:
| Aside from many sane and clever design choices, a key feature
| of Zig is that it's not Rust.
|
| Why does it matter?
|
| Because (some of) the Rust community is turning out to be toxic
| and repulsive.
|
| Zig is different player in the same space (C/C++ replacement)
| with a much less toxic community.
| recuter wrote:
| What makes the Rust community toxic and repulsive and what is
| to stop the Zig community from becoming such in the future?
| [deleted]
___________________________________________________________________
(page generated 2022-12-08 23:00 UTC)