- 主题:zz为什么go没有像JAVA一样的注解
我赞同你的观点。go本身的设计不先进，主要还是占齐了天时地利。
如果不是受生态限制，我愿意选择kotlin，哈哈。
【 在 eGust 的大作中提到: 】
:
: 前段时间很火的 Lies we tell ourselves to keep using Golang 里面提到了：
: Because they're Go experts, they know the cost of using Go upfront, and they're eq
: ..................
发自「今日水木 on Android」
--
FROM 123.118.12.*
c#有吧
【 在 zhangyoung 的大作中提到: 】
: python也有注解
: c#没这玩意儿
--
FROM 58.61.245.*
go跟jvm不一样啊
go直接翻译到plan9汇编了，然后再到二进制
jvm是解释执行中间码
go的目标就不是重新实现一个jvm，因为jvm已经很完美了
jvm调用cpp当然要容易了
【 在 eGust 的大作中提到: 】
: 前段时间很火的 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.
: ...................
--
修改:littleSram FROM 223.104.39.*
FROM 223.104.39.*
这个区别不重要啊，因为体现在最终执行效率上，两者没差别。语言选型的时候，只关心效率是哪个梯队的，有没有 gc，有的话是什么策略对产品有什么影响。当初还可以说 jvm 的策略 stop the world 多么糟，但 java 也早就有相同的策略用了。至于有没有 vm、具体怎么实现的，又不是写编译器，关心这种细节有啥用。
【 在 littleSram 的大作中提到: 】
: go跟jvm不一样啊
: go直接翻译到plan9汇编了，然后再到二进制
: jvm是解释执行中间码
: ...................
--
FROM 203.211.108.*
对大多数人，的确是这样的
我现在对go感兴趣的主要原因就是我能比较容易的编译go，可以研究更深入一些，这个项目比较新，可以跟着学习一下，多了解一些汇编
【 在 eGust 的大作中提到: 】
: 这个区别不重要啊，因为体现在最终执行效率上，两者没差别。语言选型的时候，只关心效率是哪个梯队的，有没有 gc，有的话是什么策略对产品有什么影响。当初还可以说 jvm 的策略 stop the world 多么糟，但 java 也早就有相同的策略用了。至于有没有 vm、具体怎么实现的，又不是写编译器，关心这种细节有啥用。
:
--
FROM 114.249.23.*
go 还是轻一些，内存用的少。实例一多，还是有区别的，一样的服务，多用机器还是少用机器
另外关于容易部署，在企业环境，确实到处都是 container，使得 java 之流的劣势
没那么明显了。但是个人环境，以及开发流程中的各种交互快捷性，go 还是更让人容易接受。
我注意到一个现象，有不少 linux 的工具选择用 go 来开发，什么 fzf, lf, lazygit 等等，和 rust 一起，搞出各种工具悄悄咪咪的侵入我们系统里。
【 在 eGust 的大作中提到: 】
: 这个区别不重要啊，因为体现在最终执行效率上，两者没差别。语言选型的时候，只关心效率是哪个梯队的，有没有 gc，有的话是什么策略对产品有什么影响。当初还可以说 jvm 的策略 stop the world 多么糟，但 java 也早就有相同的策略用了。至于有没有 vm、具体怎么实现的，又不
: 是写编译器，关心这种细节有啥用。
--
FROM 125.168.119.*
以前还真没关注过内存，刚搜了一下的确是差了不少。不过一般情况下，硬件成本跟人工成本是微不足道的，这也是为啥 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.*
rancher desktop
我看一下，装 docker for windows 之后不知道怎么折腾。现在还是用 wsl
看看换这个能否好用
【 在 eGust 的大作中提到: 】
: 以前还真没关注过内存，刚搜了一下的确是差了不少。不过一般情况下，硬件成本跟人工成本是微不足道的，这也是为啥 rails、django 这些“更糟”的选择依然活的好好的。但这俩生态位的区别，其实完全不会产生到底选哪个的问题：过去用啥就还用啥完全没理由换，纯脚本语言出身的
: 话肯定是转 go，上学时对 java 都熟的话就 java……
: container 更多是一个习惯问题，我现在开发子项目基本上 docker-compose 已经是标配了，一个 db，一个 redis，目前前后端两个服务还是共用一个 container，但其实也可以分开。前段时间我特意试验了一下 win、mac 上的各种 docker，发现 rancher desktop 用起来还不错。这东西
: ...................
--
FROM 111.28.164.*
也是基于 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.*