- 主题:zz为什么go没有像JAVA一样的注解
听说现在 enum 的呼声也非常高
那么问题来了，为啥不干脆直接上 rust
【 在 wudashu 的大作中提到: 】
: 翻译一下，设计的时候没想过要支持，现在想支持整个设计都得改，而且这功能也不是不可替代，大家先用简单的。
: 另一个例子: 泛型。十六年了，终于还是加上了。没泛型的恶心代码，多复制几次吐吐就习惯了。
: 发自「今日水木 on Android」
: ...................
--
FROM 203.211.108.*
最近有个关于 golang 帖子又在 hacker news 和 reddit 上面又火了
reddit 上面有个吐槽我觉得非常贴切：
Go's problem isn't that it "wasn't designed as a language for the web"; it can be more generally stated as "wasn't designed as a language for the 21st century".
【 在 wudashu 的大作中提到: 】
: 一个功能加不加，和难不难没关系。
: go的原则是一切从简，除非用户呼声够大，否则不可能加的。
: 如果可以选，我推荐试试kotlin，比go先进十年。go能干的它都能干。
: ...................
--
FROM 203.211.108.*
难不难都是相对的。最近 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 的讨论才知道，对 ffi 的支持完全是灾难，这在主流语言中是极其特殊的。所以其实这货跟如今的 java 是完全同质的，各个方面，甚至还更封闭一些。唯一的优点是更容易部署，但在到处 containers 的今天，这个优点也没啥意义。
【 在 wudashu 的大作中提到: 】
: 据说用起来不错了，直接include就能调c的库，不像cgo还要自己桥接。
: 等有机会可以在实际项目里试验一下了。
: 发自「今日水木 on Android」
: ...................
--
FROM 203.211.108.*
你是站在 c++ 的角度说 rust 基本概念不难的。我们公司用 rails，挂着 architect 头衔的人除了 ruby 和 plsql 以外，最熟的大概就算 js 了。在我的推动下，现在前端已经有部分代码变成了 vue3 + ts + composition api，这哥们儿因为 ts 直接跪了。抱怨过无数次太难用了，说周末想改一个小地方，花了8个小时都没改明白。我心想那也不是我的错，谁让你不去配或者配不明白还非要用 neovim，用 vscode 的小弟都没觉得有问题，你自己不看编译器提示在那瞎改怪得了谁。
另外你说的东西，在我短暂的使用 rust 期间没碰到有需求。不过我的东西其实也挺简单的，只不过是基于 aws-sdk 搞一个 cli/tui 工具而已。之前是用 ruby 写的，然后简单封装调用 aws-cli，缺点是慢而且不方便同时取所有 account 的信息。
rust 碰到的问题除了编译超级慢以外，就是 aws-sdk 里的结构没实现 serde，而我的一个很大需求就是把信息缓存到本地。由于 sdk 实现了 Debug，所以我还写了个东西把输出转成 json，虽然还是有很多问题，但我的场景刚好没问题。可是又没实现 deserializer，我又不想去改 aws 代码（自动生成的，而且也有人提 issue 了），最后放弃了改用 node 写。因为需求还研究了 macro，写了一些东西，觉得挺有意思的。开始碰到一些 lifetime 的问题以外，基本上没碰到其它基本语法上的问题，虽然不确定自己的代码到底好坏，不过我用啥语言都是这么开始的。
【 在 beep 的大作中提到: 】
: 我觉得 rust 主要难在文档写得不好. 实践中很关键的几个东西, 比如 temp 临时变量,
: move|copy, method lookup 的真实过程, 文档里都没怎么涉及, 至于当你看到 reference
: 的时候才开始涉及, method lookup 在 referenece 和 nomicon 里面讲的竟然还是错的,
: ...................
--
FROM 203.211.108.*
前段时间很火的 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.*
这个区别不重要啊，因为体现在最终执行效率上，两者没差别。语言选型的时候，只关心效率是哪个梯队的，有没有 gc，有的话是什么策略对产品有什么影响。当初还可以说 jvm 的策略 stop the world 多么糟，但 java 也早就有相同的策略用了。至于有没有 vm、具体怎么实现的，又不是写编译器，关心这种细节有啥用。
【 在 littleSram 的大作中提到: 】
: go跟jvm不一样啊
: go直接翻译到plan9汇编了，然后再到二进制
: jvm是解释执行中间码
: ...................
--
FROM 203.211.108.*
以前还真没关注过内存，刚搜了一下的确是差了不少。不过一般情况下，硬件成本跟人工成本是微不足道的，这也是为啥 rails、django 这些“更糟”的选择依然活的好好的。但这俩生态位的区别，其实完全不会产生到底选哪个的问题：过去用啥就还用啥完全没理由换，纯脚本语言出身的话肯定是转 go，上学时对 java 都熟的话就 java……
container 更多是一个习惯问题，我现在开发子项目基本上 docker-compose 已经是标配了，一个 db，一个 redis，目前前后端两个服务还是共用一个 container，但其实也可以分开。前段时间我特意试验了一下 win、mac 上的各种 docker，发现 rancher desktop 用起来还不错。这东西我感觉概念挺简单的，命令也设计的很友好，vscode 更是几乎原生的体验，不知道为啥推起来还是很费劲。
只要社区大到一定程度，用该语言重写其它工具只是一个时间问题。刚好昨天花了点儿时间研究 tui file manager，所以知道 lf 是重新实现 py 写的 ranger，同样 rust 重写的项目也不少。fzf 目前是老大，rust 也有类似的实现 skim，应该是接口兼容的。git 的话我知道有俩 rust 项目打算从头实现 git/libgit2，tui 也有 gitui（有段时间想写个小工具所以大概研究过）。我前段时间因为写 aws 工具研究了一下 jq，rust 这边有号称更快的重写 jaq（刚好我的刚需功能有 bug），以及类似的实现 jql。jq 作为一个好几年没更新并且还有遗留问题的项目，完全可以想象 go 肯定也有重写/重新实现的项目。
【 在 iRoNcOoL 的大作中提到: 】
: go 还是轻一些，内存用的少。实例一多，还是有区别的，一样的服务，多用机器还是少用机器
: 另外关于容易部署，在企业环境，确实到处都是 container，使得 java 之流的劣势
: 没那么明显了。但是个人环境，以及开发流程中的各种交互快捷性，go 还是更让人容易接受。
: ...................
--
FROM 203.211.108.*
也是基于 wsl2 的。我在虚拟机里试验了一下，装好一个干净的 win10，系统更新和商店之后，重启电脑。然后开一个 admin 权限的 term
winget install Git.Git --accept-package-agreements --accept-source-agreements -h
winget install --force Google.Chrome -h
winget install Microsoft.VisualStudioCode -h
winget install Microsoft.WindowsTerminal -h
winget install Mozilla.Firefox -h
winget install suse.RancherDesktop -h
wsl --install
重启电脑，然后等 wsl2 下载好 ubuntu 就可以用了
【 在 chaobill 的大作中提到: 】
: rancher desktop
: 我看一下，装 docker for windows 之后不知道怎么折腾。现在还是用 wsl
: 看看换这个能否好用
: ...................
--
FROM 203.211.108.*