I'm not certain that blocking CGO because of compile speed should be a primary concern. The package that implements the interface to the underlying system should be built once and installed. After that, the impact on build speed should be no different than importing any other package. Unfortunately, I don't have any measurements.
The second reason to avoid CGO is the difficulty of building on windows. However, if you only need to access DLLs, all FFI calls can be made using the syscall package, so CGO is not needed. Robert On Sunday, 27 May 2018 16:51:32 UTC-4, ati...@mail.ccsf.edu wrote: > > Hello, > > I would like you guys to suggest some GUI libraries that do not have any > HTML/CSS or C bindings, are cross platform and require no dependencies. > > When I say native, I mean no dependencies. I do not mean native to the OS. > This would be great but I don't see any available that have no C bindings. > I understand that to create a native to the OS experience there must be > calls to the OS API which in most cases use the C language. > > Before anyone asks why I do not want C bindings, it is because they do not > have good cross compilation support or good compile speeds. > > Suggestions appreciated, Thanks so much! > -- 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. For more options, visit https://groups.google.com/d/optout.
