刚学 golang，写了个命令行翻译工具

[fazero]

因为经常使用终端，之前一直用偏右写的node 版本的，学了点 golang，用 golang 来实现一下，练一下手，golang 的交叉编译真的方便啊，写点命令行工具也方便，不依赖环境，可执行文件，跑起来就是爽。

mac 安装体验：brew install sakz/tap/fanyi

linux 安装体验：source <(curl -sL https://git.io/fanyi-install)

项目地址：https://github.com/sakz/fanyi

[PHSix]

脚本不支持 Arch

[Juszoe]

我也很喜欢 go 的交叉，但是每次看到 go 的语法我就不想学了...

[Rwing]

@Juszoe 考虑下 C#，也可以写命令行工具呀😁

[fazero]

@PHSix 现在应该可以了

[AlisaDestiny]

如果想用命令行翻译不如看看这个成熟的 https://github.com/soimort/translate-shell

[hwdef]

可以直接 go get ?

[lewis89]

@Juszoe #2 go 的交叉？ 很多库都不是跨平台的.. go 目前应用比较广的就是服务端了.. 嵌入式环境由于硬件产业死脑筋，万年 4M ROM 的设备 + C 语言搞得飞起，go 交叉编译的 mips 版本 基本上就是个半残废.. 市面上大部分能买到的 mips 架构的路由器 rom 就没几个大到能装下 golang 虚拟机的

[Juszoe]

@lewis89 #7 感谢科普，还以为 go 应该对 mips 支持挺好的...想着到时候用 go 给路由器写点东西，还是得转投 C

[lewis89]

@Juszoe #8 不存在的，golang 2.0 之前貌似没有对体积优化的进度表，主要是这玩意设计的时候就没考虑过中国的嵌入式环境，另外中国嵌入式这个行业 又比较死脑筋 特别封闭，跟其它的 IT 技术圈子基本上没什么交流跟沟通，都 0202 年了，还在那里用死扣门的硬件+爷爷辈的技术 C/C++，实际上这两个东西除了高性能的底层部分需要，写应用层用这些简直就是浪费人的脑细胞，另一方面是出货量大的话，rom 小一点确实能节省不少钱，但是话又说回来了，用以前那套玩意搞，还不如用新的技术搞，招人也方便，不过以前搞嵌入式的人都占着茅坑，自然市场上的产品也是那老一套的思维，另外中国人力成本不值钱，其实硬件节省的那点钱根本算不了什么，用新技术 python golang java 来搞的话，从市面上招人能省很多钱，开发起来速度也快，但是奈何人力成本摆在那里，根本不算什么，所以死扣硬件还是能省出不少钱的，但是现在很多小公司做嵌入式硬件就开始慢慢用新技术 /硬件了，因为他们很多时候招不到合适的人，你要用 QT GTK 来画 UI，你可能环境还没搭好，人家这边用 vue+前端把活都干完了。

[MrTreasure]

go 的目标本来就不是嵌入式，定位就是服务器端开发语言。服务器上的交叉编译 windows mac linux 做的还是很好的。

语法个人觉得挺好的，规则定的很死，也不会出现 1000 个开发 1000 个规范了

go 的开发效率还是很高的，和脚本语言有一拼了

[lewis89]

@MrTreasure #10 市面上高性能计算平台之间的 交叉编译就是个伪命题.. 交叉编译本来就是用来给低性能嵌入式设备编译二进制代码用的.. 如果你的目标设备 在市面上大面积都能买到，而且性能足够编译..那么何必在 linux 下编译 windows 的二进制包，在 windows 下编译 linux 的二进制包.. 不是脑子有病？而且现在云化 deploy 一个 linux macos windows 有这么难？

[MrTreasure]

@lewis89

> Go is an open source programming language that makes it easy to build simple, reliable, and efficient software.

我觉得你说的场景都是很高大上，现实中我的服务器程序都是本地 用 windows 编译成 linux 包，然后发布到 linux 服务器上运行。为什么不搞 docker 服务器端构建。懒、麻烦，很多用户也应该是这样用 go 写一些玩具。这种情况下交叉编译很香

[fenglangjuxu]

那些 key 会过期么 用了一个 感觉 appid Appsecret 过期了

[qwertyssp]

@lewis89 Go 有虚拟机吗 不是直接编译二进制吗

[lewis89]

@qwertyssp #14 有虚拟机的，内存回收 二进制系统 ABI 接口 都是靠虚拟机实现的，当然不是传统意义上的那种 运行时对代码进行编译成二进制的这种方式..

[lewis89]

@qwertyssp #14 另外虚拟机这个概念太笼统，因为 golang 并不是完全的按你写的代码去编译二进制代码的，中间会插入很多代码 作为运行时的 GC 还有 goroutine 用的，据我之前查的资料结合我对系统 IO 的理解，在应用层面实现协程，golang 是把所有同步系统调用接口全部在内部改成了异步实现了 这样就可以利用操作系统的 epoll 跟 select 调用 实现 IO 多路复用，这样可以使用较少的系统线程去实现 golang 语言层面的协程，因为在引用层面的协程调度，其实只有代码走到系统调用之后，就可以改变协程的状态，此时线程可以交给另外一个协程去 run，等 epoll 调用返回的时候，然后再使用调度器让之前触发系统调用的协程 run 起来就好了，这本身并不是一件很难的事情，在 c/c++里面都有类似的协程实现，但是头疼的是选择调度算法，像 Java 反正语言层面受限，所以干脆拿线程池死扛就是了。

[lewis89]

@qwertyssp #14

传统的线程池并发模型有一个缺点就是线程的开销太高，而且由操作系统掌控，另外线程由 CPU 的 ring3 权限切换到 ring0 权限，需要切换 MMU 的内存页表，可能还不能利用上 L0 L1 缓存，CPU L0 L1 主存之间分别读取数据的时间差距是指数级别的，这些也就是通常网上俗称的内核态切换开销，如果用一个线程专门去处理其它线程的 IO 调用，例如 epoll 关键字就可以大幅度降低 CPU 在内核态跟应用态的切换开销，而且原本因为系统调用而进入阻塞的线程 就不用再阻塞了，只要让其它的协程代码继续在这个线程上跑起来即可，这样可以节省很多开销。

[lewis89]

@qwertyssp #14 我个人对二进制编译 可能认知是 C/C++这种直接展开成 IR，然后基本上可以将高级语言跟汇编直接对应起来的这种方式，但是 golang 并不是如此。