据说用起来不错了，直接include就能调c的库，不像cgo还要自己桥接。
等有机会可以在实际项目里试验一下了。
【 在 hgoldfish 的大作中提到: 】
:  
: kotlin native 现在怎么样了？  
: --  
: 灭绝人性啊  
:
:

发自「今日水木 on Android」
--
FROM 114.254.0.*

难不难都是相对的。最近 go 的讨论中有人提到，很多 go 用户都是从 py、rb、js 之类脚本语言转过来的。我觉得的确有一定道理，作为编译型的鸭子类型语言，加上极其有限的语法，脚本语言转过来的确难度相对较低。对于 c/c++ 对性能敏感的场景，go 并不适用。效率上跟 jvm 半斤八两，所以 java/c# 也没有换的理由。这些语言里，让只懂脚本语言的人上手的话，的确 golang 算是最容易的选择了，直接上 rust 步子迈太大了。

但如果对比较现代的静态类型语言比较熟悉，比如 kotlin、swift 之类甚至 c#，我个人认为难度应该是不高的。毕竟想解决的问题都是类似的，再加上许多语法都是抄来抄去的，至少看着都眼熟。至于 c++ 自然就更不用说了，天然更容易上手。

【 在 wudashu 的大作中提到: 】
: rust太难了，大多数人都学不会。
: 而rust只在追求极致性能的时候有优势。这注定了rust只会是小众语言，用来开发底层高性能软件，比如操作系统，驱动，浏览器。常规的开发用rust太奢侈了，人都招不到。
: 发自「今日水木 on Android」
: ...................
--
FROM 203.211.108.*

有时候没得选，有的领域大部分都是用go开发的项目
【 在 wudashu 的大作中提到: 】
: 一个功能加不加，和难不难没关系。
: go的原则是一切从简，除非用户呼声够大，否则不可能加的。
: 如果可以选，我推荐试试kotlin，比go先进十年。go能干的它都能干。
: ...................
--
FROM 114.249.23.*

直接和系统/硬件打交道的时候，ffi很有用。上层业务用处倒是不大了。
举个例子，读硬件信息可以用udev，有ffi直接调libudev就可以了。内核版本，udev版本都不用关注，编译器会帮忙搞定，文档很齐全，升级也简单。如果没有ffi就难了，得自己想办法把需要的接口都做出来，文档维护升级都是噩梦。

go能在运维界大放异彩，我认为和cgo关系是非常大的。这让go不仅满足了以前写脚本的运维工程师转语言的需求，还能方便的管理系统，操作硬件。
【 在 eGust 的大作中提到: 】
:  
: 最近看 go 的讨论才知道，对 ffi 的支持完全是灾难，这在主流语言中是极其特殊的。所以其实这货跟如今的 java 是完全同质的，各个方面，甚至还更封闭一些。唯一的优点是更容易部署，但在到处 containers 的今天，这个优点也没啥意义。  
: --  
:

发自「今日水木 on Android」
--
FROM 123.118.12.*

前段时间很火的 Lies we tell ourselves to keep using Golang 里面提到了：
Because they're Go experts, they know the cost of using Go upfront, and they're equipped to make the decision whether or not it's worth it. They know how Go works deep down (something Go marketing pinky-swears you never need to worry about, why do you ask?), so if they hit edge cases, they can dive into it, fix it, and wait for their fix to be upstreamed (if ever).

But chances are, this is not you. This is not your org. You are not Google either, and you cannot afford to build a whole new type system on top of Go just to make your project (Kubernetes) work at all.

之所以 devops 这块火了，刚好是因为这帮 experts 搞出了 docker/k8s。刚好因为整套生态都建立在 golang，而且放到发明 docker 的时候 deployment 的确还是个问题。

由于整套 container 的生态都是可以用 rust 重写的，而且也不是没有意义的重新实现（比如 runc 已经有 c 的实现 crun 和 rust 的实现 youki），所以长期来看这套生态是可以被其它语言替换的。甚至虽然 js 不擅长干这活儿，但突然有一天冒出来用 js 虚拟了一套 linux kernel 然后再在它上面实现 container 也不要觉得太突然，虽然更合理的情况是 js 应该走 wasm as a service 而不是 linux as a service 的路。

放到10年前，docker 还没发布的时候，市面上也没有现在这么多可以选的 better c。现如今如果喜欢 py 的语法，有 nim，喜欢 rb 的有 crystal，还有 v、zig 一堆可以选。虽然这些语言的后台都赶不上 mozilla，但基本上都是无缝使用 c 的，想用 libxxx 都不需要太多额外工作，自然 ffi 都不是问题。这么多年过去了，除了 goroutine 以外，go 有的东西 jvm 都实现了，go 和 java 真的同质性相当严重，包括语法都是上世纪的设计。跟这些新语言比起来，除了生态环境不止好上一点儿半点以外，对脚本语言用户来说，其实也没啥优势

所以呢，go 还是要感谢 google 这个亲爹，再加上生的早搞出了 container 的生态

【 在 wudashu 的大作中提到: 】
: 直接和系统/硬件打交道的时候，ffi很有用。上层业务用处倒是不大了。
: 举个例子，读硬件信息可以用udev，有ffi直接调libudev就可以了。内核版本，udev版本都不用关注，编译器会帮忙搞定，文档很齐全，升级也简单。如果没有ffi就难了，得自己想办法把需要的接口都做出来，文档维护升级都是噩梦。
: go能在运维界大放异彩，我认为和cgo关系是非常大的。这让go不仅满足了以前写脚本的运维工程师转语言的需求，还能方便的管理系统，操作硬件。
: ...................
--
FROM 203.211.108.*