I think a lot is because a lack of macros. With macros it is difficult to figure out changed dependencies.
> On Nov 13, 2020, at 7:55 PM, kev kev <kevthemusic...@gmail.com> wrote: > > Oh right, I seem to not understand why golang is faster in that respect. If > you can include the precompiled headers and or have an object file > >> On Saturday, 14 November 2020 at 01:21:51 UTC ren...@ix.netcom.com wrote: >> In C there are precompiled headers which avoid the recompilation. >> >>>> On Nov 13, 2020, at 7:18 PM, kev kev <kevthem...@gmail.com> wrote: >>>> >>> >> >>> >>> Thanks for the answer. If C/C++ has object files, is it not possible to see >>> “something.h” and then fetch the corresponding object file? >>> >>> With go, if I import “package something” and that package imports another >>> package called “package bar” then at some point I will need to compile >>> “bar” and “something”. This to me is like your header example. >>> >>> I think you are maybe saying that this traversal is only done once for >>> golang and the information is stored in an object file? While in C, the >>> header traversal is done each time I see include? >>>>> On Saturday, 14 November 2020 at 00:14:41 UTC Kevin Chowski wrote: >>>>> 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...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/2e237e13-37c9-4741-8ea1-67f813923fafn%40googlegroups.com. > > -- > 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/b1f9fed3-a524-458e-965d-82fa57356f1cn%40googlegroups.com. -- 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/931F6084-D3F4-49F8-897C-D5EE049F1FC3%40ix.netcom.com.
