这是一个创建于 1584 天前的主题，其中的信息可能已经有所发展或是发生改变。
因为经常使用终端，之前一直用偏右写的node 版本的，学了点 golang，用 golang 来实现一下，练一下手，golang 的交叉编译真的方便啊，写点命令行工具也方便，不依赖环境，可执行文件，跑起来就是爽。
mac 安装体验：brew install sakz/tap/fanyi
linux 安装体验：source <(curl -sL https://git.io/fanyi-install)
项目地址：https://github.com/sakz/fanyi
 |
1
PHSix 2020-08-26 15:54:56 +08:00 via Android
脚本不支持 Arch
|
 |
2
Juszoe 2020-08-26 16:02:37 +08:00 via Android
我也很喜欢 go 的交叉，但是每次看到 go 的语法我就不想学了...
|
 |
5
AlisaDestiny 2020-08-26 16:08:36 +08:00
如果想用命令行翻译不如看看这个成熟的 https://github.com/soimort/translate-shell
|
 |
6
hwdef 2020-08-26 16:09:57 +08:00
可以直接 go get ?
|
 |
7
lewis89 2020-08-26 16:21:54 +08:00
@Juszoe #2 go 的交叉？ 很多库都不是跨平台的.. go 目前应用比较广的就是服务端了.. 嵌入式环境由于硬件产业死脑筋，万年 4M ROM 的设备 + C 语言搞得飞起，go 交叉编译的 mips 版本 基本上就是个半残废.. 市面上大部分能买到的 mips 架构的路由器 rom 就没几个大到能装下 golang 虚拟机的
|
|
8
Juszoe 2020-08-26 17:16:37 +08:00
@lewis89 #7 感谢科普，还以为 go 应该对 mips 支持挺好的...想着到时候用 go 给路由器写点东西，还是得转投 C
|
|
9
lewis89 2020-08-26 17:24:53 +08:00
@Juszoe #8 不存在的，golang 2.0 之前貌似没有对体积优化的进度表，主要是这玩意设计的时候就没考虑过中国的嵌入式环境，另外中国嵌入式这个行业 又比较死脑筋 特别封闭，跟其它的 IT 技术圈子基本上没什么交流跟沟通，都 0202 年了，还在那里用死扣门的硬件+爷爷辈的技术 C/C++，实际上这两个东西除了高性能的底层部分需要，写应用层用这些简直就是浪费人的脑细胞，另一方面是出货量大的话，rom 小一点确实能节省不少钱，但是话又说回来了，用以前那套玩意搞，还不如用新的技术搞，招人也方便，不过以前搞嵌入式的人都占着茅坑，自然市场上的产品也是那老一套的思维，另外中国人力成本不值钱，其实硬件节省的那点钱根本算不了什么，用新技术 python golang java 来搞的话，从市面上招人能省很多钱，开发起来速度也快，但是奈何人力成本摆在那里，根本不算什么，所以死扣硬件还是能省出不少钱的，但是现在很多小公司做嵌入式硬件就开始慢慢用新技术 /硬件了，因为他们很多时候招不到合适的人，你要用 QT GTK 来画 UI，你可能环境还没搭好，人家这边用 vue+前端把活都干完了。
|
 |
10
MrTreasure 2020-08-26 17:28:05 +08:00  1
go 的目标本来就不是嵌入式，定位就是服务器端开发语言。服务器上的交叉编译 windows mac linux 做的还是很好的。
语法个人觉得挺好的，规则定的很死，也不会出现 1000 个开发 1000 个规范了 go 的开发效率还是很高的，和脚本语言有一拼了 |
|
11
lewis89 2020-08-26 17:32:14 +08:00
@MrTreasure #10 市面上高性能计算平台之间的 交叉编译就是个伪命题.. 交叉编译本来就是用来给低性能嵌入式设备编译二进制代码用的.. 如果你的目标设备 在市面上大面积都能买到，而且性能足够编译..那么何必在 linux 下编译 windows 的二进制包，在 windows 下编译 linux 的二进制包.. 不是脑子有病？而且现在云化 deploy 一个 linux macos windows 有这么难？
|
|
12
MrTreasure 2020-08-26 17:41:56 +08:00
@lewis89
> Go is an open source programming language that makes it easy to build simple, reliable, and efficient software. 我觉得你说的场景都是很高大上，现实中我的服务器程序都是本地 用 windows 编译成 linux 包，然后发布到 linux 服务器上运行。为什么不搞 docker 服务器端构建。懒、麻烦，很多用户也应该是这样用 go 写一些玩具。这种情况下交叉编译很香 |
 |
13
fenglangjuxu 2020-08-26 17:47:31 +08:00
那些 key 会过期么 用了一个 感觉 appid Appsecret 过期了
|
|
15
lewis89 2020-08-26 18:07:51 +08:00
@qwertyssp #14 有虚拟机的，内存回收 二进制系统 ABI 接口 都是靠虚拟机实现的，当然不是传统意义上的那种 运行时对代码进行编译成二进制的这种方式..
|
|
16
lewis89 2020-08-26 18:16:35 +08:00 1
@qwertyssp #14 另外虚拟机这个概念太笼统，因为 golang 并不是完全的按你写的代码去编译二进制代码的，中间会插入很多代码 作为运行时的 GC 还有 goroutine 用的，据我之前查的资料结合我对系统 IO 的理解，在应用层面实现协程，golang 是把所有同步系统调用接口全部在内部改成了异步实现了 这样就可以利用操作系统的 epoll 跟 select 调用 实现 IO 多路复用，这样可以使用较少的系统线程去实现 golang 语言层面的协程，因为在引用层面的协程调度，其实只有代码走到系统调用之后，就可以改变协程的状态，此时线程可以交给另外一个协程去 run，等 epoll 调用返回的时候，然后再使用调度器让之前触发系统调用的协程 run 起来就好了，这本身并不是一件很难的事情，在 c/c++里面都有类似的协程实现，但是头疼的是选择调度算法，像 Java 反正语言层面受限，所以干脆拿线程池死扛就是了。
|
|
17
lewis89 2020-08-26 18:23:03 +08:00
@qwertyssp #14
传统的线程池并发模型有一个缺点就是线程的开销太高，而且由操作系统掌控，另外线程由 CPU 的 ring3 权限切换到 ring0 权限，需要切换 MMU 的内存页表，可能还不能利用上 L0 L1 缓存，CPU L0 L1 主存之间分别读取数据的时间差距是指数级别的，这些也就是通常网上俗称的内核态切换开销，如果用一个线程专门去处理其它线程的 IO 调用，例如 epoll 关键字就可以大幅度降低 CPU 在内核态跟应用态的切换开销，而且原本因为系统调用而进入阻塞的线程 就不用再阻塞了，只要让其它的协程代码继续在这个线程上跑起来即可，这样可以节省很多开销。 |
Select Language