C/C++ also has object file caching (depending on how your build is set up, I guess). In C/C++ the issue is that you need to possibly open a large number of header files when you import any header file.
For example, if I write a file "main.c" which imports "something.h", which in turn imports "another.h" and "big.h", and compile just main.c, the compiler has to open all three header files and include them in the parsing of main.c in order for the compilation to correctly move forward. In Go, the compiler arranges things such that it only has to open one file per package that is imported. The post you linked goes into greater detail, so I will avoid duplicating the details for now, but feel free to ask a more specific question and I can try to answer. There's a bit of nuance there, which the post also goes into: Go's strategy ends up requiring that some package much be compiled before any package which imports it is compiled. In C/C++ the ordering is a little more flexible due to the more decoupled nature of header files, meaning that theoretically more builds could occur in parallel. But I suspect that in your average Go program the dependency tree would still allow you to execute a large number of builds in parallel. Also note that the article claims this is "the single biggest reason" Go compilation is fast, not the only one. There are lots of smaller, yet important, reasons as well. For example, parsing the language is pretty straightforward because it is not very complex, and linking the final binary together is continually being optimized. Plus there are no turing-complete meta-language features like the templates C++ compilers have to deal with ;) As for your following, the whole set of files in some package are the compilation unit, at least as far as I understand the terms. This is because if a.go and b.go are both in the same package (e.g. in the same directory), code in a.go can call code in b.go without explicitly declaring anything. So before the code in a.go can be fully compiled into an object file, b.go must be considered as well. On Friday, November 13, 2020 at 3:54:34 PM UTC-7 kev kev wrote: > I recently read the post by Rob Pike about language choices for Golang: > https://talks.golang.org/2012/splash.article#TOC_5. > > The seventh point refers to how Golang handles dependencies. It mentions > an "object file" for packages that a _dependent_ reads. > > Below I go through my interpretation of this section: > > Example: > > package A imports package B. > > When I compile package A, package B would have already been compiled. What > package A receives is not the AST of package B, but an "Object file". This > object file only reveals data about the publicly accessible symbols in that > package. From the example, if B had a private struct defined inside of it, > this private struct would not be in the object file. > > This part seems to make sense for me, hopefully I did not make any > mistakes. > > It seems that the speedup compared to C/C++ is because the object file is > created once per package, while in C/C++ you need to re-compile the thing > you are including each time? > > Followup question: > > Is a single file a compilation unit or is it a package? > > Thanks > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/04284b0f-7e99-42c8-ae66-2d567e3a4bcan%40googlegroups.com.
