CGO and Go languages are different.

CGO not go

Borrow a word from jwz

Some people, when they face a problem, think "I know, I will use CGO". So now, they have two questions.

I am very worried about the recent use of CGO on Gopher's Slack Channel, especially if there is an organization that intends to use a project to show Go, which is a bad idea. I have said many times about this, so maybe you hated my lobbying, so I thought about writing it down and doing it.

CGO is an amazing technique that allows Go programs to interoperate with C's class libraries. It is an extremely useful feature, and today it achieves a position that Go cannot reach. CGO is the key to getting the Go app running on Android and IOS.

However, this is only my personal opinion, I do not speak for anyone, I think CGO is overused in the Go project. I believe that when faced with the need to reload a large section of the C code written with go, programmers would prefer to use CGO to package libraries rather than go, because they think it is easier to solve the problem. I think that's a fake economy.

Obviously, CGO also has some unavoidable problems, the most obvious problem is that as a binary blog, you have to interact with the graphics card driver or window System. However, the use of CGO problems, after the trade-offs, most people think it is still relatively small.

When you build a CGO library on a Go project, you may not realize that this tradeoff is actually incomplete.

All day, dry and dry, translated 1 years ago2 person TopTopWell translated! Build time gets longer

When you reference the import "C" in the package, go build does a lot of extra work to build your code, and the build doesn't just pass a bunch of. Go files to the Go tool compile, instead:

• The CGO tool is called to generate various files between C conversion go and go conversion c.

• Your system's C compiler will be called to process all the C files in your package.

• All independent compilation units are combined into an. o file.

• The generated. o file will be checked for a fix in the system's connector.

When you program for this package, all of the above work will be done during your compilation or testing. The Go tool handles these tasks in parallel, where possible, but the compilation time of this package increases with all C code constructs.

You can refactor this part of the C code to solve this package, but if you don't have to CGO, you will not encounter this problem naturally.

Yes, you also have to debug C code compatibility issues on different platforms.

Drkaka translated more than 1 years ago0 Person TopTopWell translated! Complex construction

One of the goals of Go is to produce a language, which is the process of describing itself; Your program's resources contain enough information to use a tool to create the project. This is not to say that using Makefile to automate building projects is bad, but before CGO is introduced, you create and test nothing, except the Go tool. Later CGO was introduced, setting all the environment variables, keeping track of the shared objects and header files that might be installed in strange places, which you need to do now.

Remember, go supports those platforms that don't load out-of-the-box, so you have to spend some time proposing a solution for Windows users.

Also, now your users will install the C compiler instead of just installing the go compiler. They also need to install the C library on which your project depends, so you also have to bear the cost of these support.

All day, dry and dry, translated 1 years ago1 person TopTopWell translated! Cross-compilation does not support

Go is the best support for cross-compilation. Depending on Go1.5 cross-compiling, you can install the program from any supported platform to any other platform via the official license on the Go Project website.

By default, CGO is not allowed to cross-compile. Usually this does not pose a problem if your project is pure go. When you mix the dependencies of C libraries, you either have to give up cross-compiling your product, or you have to spend time looking for and maintaining C's cross-compiler toolchain to achieve your goals.

Perhaps the product you are doing is communicating with the client only through TCP, and you plan to run it on a model of SaaS (software-serviced software as a service), then you don't care about cross-compiling at all. However, if you are doing a product that other people will use, it may be integrated into their product, perhaps it is a monitoring solution, perhaps it is a client of your SaaS service, then you will be able to easily cross-compile the features to lock the dead.

The platform supported by go continues to grow. Go 1.5 adds support for 64-bit arm and PowerPC. Go 1.6 adds support for 64-bit MIPS, while IBM's s390 architecture is in Go 1.7. Available in Risc-v. If your product relies on C libraries, not only do you have to face all of the cross-compilation issues described above, you also have to make sure that the C code you rely on runs reliably on the new platform supported by Go-you have to do these limited debugs using C/go hybrid. This leads to the following question.

All day, dry and dry, translated 1 years ago1 person TopTopWell translated! You lost the entrance to all your tools.

Go has some great tools, such as race analysis, performance analysis, coverage, fuzzy testing, and other source code analysis tools. None of these barriers can span cgo blood or cgo the brain.

Conversely, good tools like valgrind do not understand the calling convention and stack layout of go. At this point, the work of Ian Lance Taylor, which combines C's memory cleanup and null pointer debugging in Go 1.6, will be very useful for CGO users.

Combing go code and C code results to two world intersections, not alliances; C Memory Security, go program debugging.

Performance is always a problem

C Code and go code live in two different universes, cgo the dividing line between the two of them. The transition is not free, it depends on where it is in your code, and the cost may be insignificant or huge.

All day, dry and dry, translated 1 years ago1 person TopTopWell translated! Other translation versions (1)

C does not understand the call contract or stack of go, so the go language calls to C code must first record all the details of the GO function entrance stack, and then switch to the C stack, run C code, this part of C code does not know how it was called, much less know the external Go language runtime environment.

To be fair, Go also doesn't know anything about C. That's why the rules for passing data between Go and C are becoming more complex as the compiler and the garbage collector evolve to locate useless stack frames and heaps.

If an error occurs during C, go can at least print the error stack information and exit the program instead of exposing the core file.

It's really not easy to manage this stack of mutual calls, plus the signals, threads, and callbacks. Ian Lance Taylor has done a lot of work in the 1.6 version of the Go language to improve interoperability with C-language signal processing.

This is to say that the C and Go language between the call is more cumbersome, and will always have performance overhead.

Snow falls without trace Xdj translated 1 years ago0 Person TopTopWell translated! Other translations (1) C is dominated, not your code

It doesn't matter if you bundle or wrap C code in that language, Python, a jni java, some libffi language, or a CGO go; this is the world of C, you just live on it.

The go code and the C code must be consistent in how the resources are shared, such as address space, signal processing, and thread scheduling--and what I say is consistent is the assumption that go revolves around c. The C code can assume that it has been running on a thread, or that it is running in an environment with many threads without worrying about any preparation work.

You are not writing a go program using some of the logic in C library, instead you are writing a go program that must coexist with a conflict-prone, hard-to-replace C code that is difficult to negotiate without worrying about your problems.

All day, dry and dry, translated 1 years ago1 person TopTopWell translated! Deployment becomes more complex

For ordinary readers, any description of go should contain at least one of the following words:

simple, static binary

This is the magic of Go, which leads go to be a typical representative of the virtual machine and running management. With CGO, you'll have to give up these.

Depending on your environment, putting your go project into a deb or RPM package and assuming that your other dependencies are packaged, adding them to the installation dependencies, and then throwing the problem out of the operating system's package management may be possible. But the important changes to these build and deploy programs are just as hasty and straightforward as go build && SCP.

It is possible to compile a completely static go program, but if your project contains CGO it will never be easy, and the consequences will affect the lifecycle of an entire build and deployment.

Please choose wisely

To be clear, I am not saying that you should not use CGO. But before you make the deal, think carefully about the pros of go that you're giving up at the same time.

Related articles:

1. Introduction to cross-compilation of Go 1.1

2. Cross compilation of Go 1.5

3. Cross-compilation becomes more complete in Go 1.5

4. Introduction to go cross-compiling

CGO and Go languages are different.