@karott7
我们现在所有服务都是 Docker 打包上 K8S ，很方便。
不知道你们用什么部署，如果图省事可以上 Docker-compose ，也很方便。

但是 Next.js 打包出来是个 Node.js 项目，所以部署 node 的方式应该都可以用吧。

管理后台还是用 Angular 简单快速。

@CommandZi
不是举例的问题，你就算用过 100 个 Flutter 做的 App 都很屎，也无法得出 Flutter 垃圾的结论。
你可以说你用 Flutter 做的 App 遇到过哪些问题，让你的体验不太好。
而且 Flutter 生成的就是原生 App ，体验不好大概率还是开发问题。

虽然 github star 数不是绝对的，但是 13 万 star 说明他还是收到人很多人的认可。
就像很多人骂 Vue 抄袭，但是 10 几万 star 也能说明，他确实对很多人受用。

@CommandZi
闲鱼垃圾跟 Flutter 有什么关系？
你访问了一个 java 写的网站很卡你是不是要说 java 垃圾？
你街上看到一个人在你面前吐痰是不是要说天朝人垃圾？

你要说屎得说到点上，拿几个垃圾 App 举例明显没啥说服力。

@yazinnnn 奇了怪了，如果不是因为 Go 语言的语法和生态，那为啥要转 Go 呢？

@nanxiaobei
首先并没有觉得 Recoil 太罗嗦，至少跟 Redux 比简直是极简。
其次 Recoil 15k 星说不温不火就有点。。。
而且，没有明白一点是，为啥要出 3 个库？现在选择困难症患者很多啊。

@sjhhjx0122 如果是这种限制方式，那可选项很少啊

@KuroNekoFan
em.... recoil 项目包确实内容挺多的，但是不知道实际打包出来会多出来多少。
但是跟以往的一些状态控制相比，Recoil 真的很简单高效，关键是兼容 hook 语法。

至于 taro ，不太清楚他与实际 React 兼容性如何，如果是纯 React 项目应该没啥问题。

好久没弄过小程序了，但是这年头网站动不动都好几 MB ，加载也不会太慢，小程序多出来几百 KB 加载速度会慢很多吗？

@986244073 你是问 hook 是啥？还是说 hooks 用啥实现的？还是 hook 怎么用？

@KuroNekoFan Recoil? 体积大？你是怎么测算它的体积的？
况且 Recoil 都 1 万 5 星了，在各种环境下均运行良好。（当然主要还是为了 cross component share state 使用，页面的大部分内容还是用 hook 写。）

2022 选比较火的技术栈：
前后移动端：(Nest.js / Gin / Actix / FastAPI / kotlin spring boot) + (Next.js / Angular / Material UI) + Flutter
部署：K8s + Docker+ Istio + OPA + Nats + Redis + Postgresql + MongoDB + EFK + Prometheus/Grafana/Kiali + GRPC + Harbor + MinIO + Bazel 全家桶带走。

状态管理只需要 hook 和 recoil 就能绝大部分需求。

计算机计算整数是精确的，所以如果想要达到精确计算通常可以使用类似 Decimal 的库，或者用 BigInt 转换使用。

浮点数不管哪个语言都有这个问题，打开 chrome 控制台，在里面输入 0.1 + 0.2 回车试试。

@Goooooos
其实你稍微了解下就能明白，不是说当圣经，而是 Go 语言确实有一些独特的设计思想。

你觉得 filter 和 泛型这类几乎所有语言都有的东西，谷歌那些开发者们不知道吗？

而 Go 语言的设计思想里就有一条就是能用一种简单方法解决的问题就没必要给你第二种。
所以你会发现 if else 可以解决问题，所以不会给你三元运算符（还有一个原因是三元运算符容易被 abusing ）
for 循环可以解决的问题，就不会给你 while 循环和 forEach 循环。

而这种设计思想到底让我们的开发更简单了还是更复杂了是见仁见智的。
但是反观 Go 语言今天的成绩，说明这种思想正在被越来越多人所接受，他们在用这种设计思想开发更多有意义的服务。
这时你就要回来反思，这种看似好麻烦的设计为什么会被这么多人接受？

@liaohongxing 我也觉得自己挺无聊的。

但是最近看到太多奇葩的言论，实在是看不下去。

类似，关系型数据库不要用 join ，API 接口全部用 POST 因为更安全，接口统一回复 200 ，Go 语言没有 filter 所以标准库有缺陷等等。。。
你可以这么用，你们公司也可以这么规定，每个人都有自己的决定权，虽然明白这是国内的现状，但...看到满屏幕这种奇葩言论，还好多人点赞附和，emmm...可能我确实有点无聊吧

@BeautifulSoap
我其实早就没兴趣给你说通什么，只是太多人有你类似的想法，进而误导更多人。

你做假设的时候能匹配上你刚开始的言论吗？健全这件事已经没必要再纠结了，我上面也说了，横向对比其他语言，Go 语言标准库已经算是比较 Robust 的了。

我现在只想看看你到底怎么为 Go 语言标准库做贡献，完善你说的那些缺陷，我也好学习学习。
你现在已经脱离了最初的论点，揪着“健全”讲个没完，能把你一开始抱怨拿出来说说吗？
数组没有 filter ，你来解决一下，代码发出来给大家看看，好不好？
（我本来不想这么说的，但是你开始耍 wu lai 了嘛，那就拿出点东西，证明一下标准库连这么简单的功能都没有。）

@BeautifulSoap
怎么还 json ，sort 啥的都没了，你看了标准库吗？

你能有点逻辑吗？我说的不够清楚吗？

如果有一个你觉得应该存在于标准库的功能，但是标准库没有，那么请你去 Gerrit 上贡献你的代码。
去完善标准库，你去尝试去实现你所说的那些没有的功能。好吗？而不是在这儿抱怨？

任何人都可以去贡献啊，你说数组没有 filter ，你写个 filter 到 Go 语言标准库里，跟他们说：“你们的标准库不太完善，我帮你们完善一下，填补标准应该有的基本功能”。ok ？
如此基础的功能应该谁都能实现吧？标准库不健全，那么就请完善它。
如果觉得麻烦，你可以把你的实现代码发出来，让大家一起讨论讨论，如何？

@zoharSoul 你也被上面这个人洗脑了？
这么清晰的逻辑，你能不能也通过自己的大脑思考一下呢？
或者说你也想去贡献一下？

@dragonsunmoon
同意，

很多人接触 Go 都是先有过其他语言的开发经验，这种情况下很容易就会进行横向对比，问为什么这么方便的功能 Go 语言没有，然后就开始抱怨吐槽，这当然无可厚非。

我的观点也很清晰，之前那位说的缺点确实是 Go 语言的一些设计导致的，且短时间不太会提供解决，与标准库无关。
既然是这么设计的，那更应该查一下为什么这么设计，这么设计的初衷是什么，带来了这些不便利的同时是否为我们的开发工作带来了其他收益。

@lybcyd emmm ，这个杠其实说服力不大。

首先这个定义里也说了：成功的、令人印象深刻，且不太会失败或变弱。
这与中文定义的：完备的、健康的、而无缺陷的。

大致匹配，你非要说不同，也没办法。
但是我上面也说了，“Go 语言标准库与其他语言标准库相比，已经算是比较健全的”。