Golang Go语言开发的软件移植转换为其他语言
Golang Go语言开发的软件移植转换为其他语言
go 开发的软件编译后一般相对都比较大，go 有没有类似 Java JDK/JRE 或者是 c/c++ 运行库这样的东西，这样是不是就可以减小一些编译后的体积，特别是有多个 go 编译后的文件。由于嵌入式设备存储空间有限，想把 go 开发的项目移植转换成 c/c++, 是不是 只要 go 用到的库有 c/c++ 版本就可以完成移植转换，有没有工具能直接把 go 代码转换成 c 代码 然后编译。或者是这样的软件参考 go 项目思路直接重新实现就可以了，没有必要转换。
更多关于Golang Go语言开发的软件移植转换为其他语言的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
嵌入式？ tinygo
编译参数 -ldflags “-s -w” ？
upx ？
更多关于Golang Go语言开发的软件移植转换为其他语言的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
因为是自举类型的编译语言？依赖本身就少。
就这么设计的吧- -
一个 go 程序编译后只依赖(linux):
linux-vdso.so.1 / libpthread.so.0 / libc.so.6 / lib64/ld-linux-x86-64.so.2
这个得问作者，我想他是考虑跨平台得关系吧。 我们是因为有这个现成的成熟项目，现在也能在目标平台上运行只是它一个程序感觉都比整个系统大了，现在是看有没有方法能缩小体积，没有方法就智能全部重实现。
我的意思是编译的时候可以提供一个选项 静态打包或者是动态打包， 如果一个系统运行一个 go 的执行文件可能看不出来区别 但是 如果有多个 go 使用动态打包肯定是可以减少体积的，整个时候就有必要了啥，我个人觉得整个是跨平台语言一个通病就是不分离的话打包后都很大
动态链接库的依赖管理是个很复杂的事。Go 的设计目标之一就是避开业界著名的 DLL hell 问题，所以用了全静态链接，必然会导致单个输出变大。这是它的 trade off ，不是缺陷。你所遇到的这种业务场景不是 Go 的目标场景。换语言吧。
对了，说到 C ，在嵌入式环境里也有一种全静态的构建方式叫 busybox ，具体做法就是把多个不同程序的源代码稍作改造后拧在一起，通过单一的 main 根据 argv[0]的名字来决定其行为，编译安装好后 ln -s 创建多个名字的软链接。busybox 是全静态的，实际上比每个程序单独编译后加起来要小。不过依赖库太复杂时就不适合用 busybox 了。
因为 go 开发的软件基本上都是源码依赖的标准库和第三方库，从这点来说和依赖 header only 库的 C/C++并无不同，而且理论上源码依赖的情况下链接器是可以做到更好的代码体积优化的。
如果有很多可执行文件共享基础库的情况下，可以写一个可执行入口来执行子程序，链接器会帮你把二进制体积优化到最小的。
go 也可以编译成 c 兼容的动态链接库的形式吧。不能满足 lz 的需求吗？
https://chai2010.cn/advanced-go-programming-book/ch2-cgo/ch2-09-static-shared-lib.html
看项目，共享的 std 动态库有 30M ，共享状态下的 http server 大小是 2M ，默认编译有裁剪的大小则是 11M ，hello-world 的区别则是 20K 和 6M ，实践下看哪种方式更适合
针对Golang（Go语言）开发的软件移植转换为其他语言的问题，以下是我的专业建议：
首先，要明确Go语言与其他编程语言之间的主要差异，这包括语法、数据类型、并发模型、内存管理等方面。这些差异将直接影响代码转换的复杂性和工作量。
在进行代码转换时，需要注意以下几点：
- 代码结构转换：Go语言具有清晰的代码结构，转换时应保持目标语言的代码结构同样清晰，并符合其编程习惯。
- 语法差异处理：例如，Go语言使用“:=”来声明和初始化变量，而Python则使用“=”。需要根据目标语言的语法规则进行相应的调整。
- API替换：Go语言中的某些API在目标语言中可能没有直接对应物，这时需要寻找功能相似的API进行替换，或进行必要的代码重构。
- 性能优化：Go语言通常具有较高的执行效率，转换后可能需要针对目标语言的特点进行性能优化。
总的来说，将Go语言开发的软件移植转换为其他语言是一项复杂且耗时的任务，需要充分了解目标语言的特性和最佳实践，以确保转换后的软件质量和性能。同时，也需要根据具体项目的需求和资源情况进行合理的规划和安排。
