公司里用，RAID 也不稳，还是多搞一组、一个常用另一个定期备份下好些

看样子我买的几块二手企业级还是很划算的。。

有故障现象就拿去售后，人家没说你用户自己检测不报错就不能售后吧？

如果不考虑润、不考虑自己做产品，只从打工的角度考虑，后端研究得精深些，不是特别容易 35 被裁，我不少要好的 35+，甚至 40+的，都还大厂中坚力量，后端需要内里浑厚些，很多问题要靠这些多年深耕的选手、不是三五年的人能替代得了的。但精深也不是特别容易，知识也得一口一口啃，经验也得一天一天涨

没搞懂，gpt plus 好像是 20 刀/月吧，print(2180/12/20)=9.08 ，人民币已经贬值这么多了吗。。

写得挺好，拍得也挺好。
但个人认为：把公共场合拍摄的其他人未打码公开发布是不够妥当的，建议删除或者打码后重新上传

还是喜欢 vanila

@keithwhisper 懂了谢谢了！

个人觉得研究这些细节挺好玩，但是卷到面试题里真挺烦的

像我们很多务实的人喜欢按简单正确的方式写，不喜欢语法上的茴字的 N 种写法的那些奇技淫巧，所以除了手误、正常情况下不会在写 for lopp i 里再写个 i:=i ，即使要临时变量复制也是 idx:=i 或者其他变量名。
所以当我看到这种面试题，即使能答对，但仍然要因为同名变量耽误那么一下自己再确认下是不是自己眼花会不会看错、甚至猜测你们是不是出题手滑写错了，正常人怎么会写 i:=i 这种不规范的代码，所以又要担心，万一是你们出题错了我答对了会不会反倒被你们判断为答错了。。

同名局部变量这么搞用来迷惑老实人，感觉是跟风 cpp ，多点实在，少整点这种垃圾题目，尤其还有国内 golang 大论坛、公众号，也搞这些带节奏，然后一堆脑残面试官拿去恶心同行，搞得行业面试风气都差得很

隔三岔五看到这类题目就觉得很烦，建议改改

@wkong 我到现在都还没学泛型相关的呢 😁

家用普通产品可以按性价比选择；
车这种产品可是性命攸关的、选型务必要谨慎。。

@iseki #151

跟线程、goroutine 相比还是不够直观。
另外，这种临时起多个并发去处理一组事情并等待所有并发执行完再继续，并不是最主要场景。
最主要场景：
例如服务器，处理每个连接，为每个连接起单独协程然后写同步代码；
例如爬虫，爬很多 url ，每个站一个协程然后递归去爬子 url ；
这些都是通常具有不确定数量和不确定执行完成节点的任务。

休想骗我学 kotlin ，要学也是 rust 🤣🤣

@totoro52 #21
说句公平话，b 站炸的好像都不是直接因为 go 吧，有次我记得是 nginx lua 里的 cpu 100%
所以这个锅 go 可不背

@iseki 搞起🤣

@iseki #146
不怕你笑话，你要不说，我还不知道有 errgroup 这玩意，刚搜了下，看样子不错，以后可以考虑用下。。。
我会的不多，用到的时候才会去查，很多用不到的干脆不懂。。。
一些 golang 公众号里经常发 golang 面试题，我偶尔看一眼就是一堆的不确定不会做。。。
你 github 账号是什么啊，我来 follow 一下

@iseki #144

我不听我不听🤣🤣🤣，就你这个这个 async await 的解释我就看的累心，比起传统进程线程比起 go 协程也太不直观了，而且还有你说的一大堆什么捕获报错父子兄弟控制流一大堆，我学不动。。。

@iseki
> 但是编程时如果每次自己去搬这一个个砖头这既不符合 DRY 的原则也不够“少”。

这个完全赞同，所以我选了 go 之后基本没再回头写多少 c/cpp 了，因为没必要，go 太省事了，而且绝大多数场景也不需要极致的性能、反而更需要开发效率

> async await 算是结构化并发的一种落地形式。

但这比起 go func()来，便利性可读性还是差得多

> 你不能说封装的程度高就一定是不好的，软件工程是权衡和妥协，君不见 Go 相比 C 不是也隐藏了许多细节吗，每个函数开头插入栈空间检查未必是个多么高效的选择，当年也有人因为用了“高级语言”就被喷浪费了机器性能。
> systemd 出现之前，如今一个 .service 文件搞定的事情要一位 bash 熟练工写上成吨的 .sh 还不一定好好解决问题。看上去 shell 里的每一个命令都好简单啊，但是组合起来的结果你能说这是“简洁”的吗。当然这个我不多说，我相信每一个工程师都很清楚。

我当然不是反对封装程度高，而是反对不必要的过度封装。
而且要分开不同的层次，一个是语言级的，一个是框架级的。
go 也好 java 也好，它们在 runtime 内的实现，都是语言级、不需要使用者去关心太多内部细节。
而框架这一层，至少我觉得 Java 是属于过度封装的，比千层饼的层数还多。。好处是更可靠，坏处当然是牺牲性能、以及真遇到问题时使用者难于深入到一层一层内部去发现和解决问题。

> 此外 Java 的轻量级线程和 Go 的 goroutine 差不多一回事，当然 syscall 该卡还是卡，go 也是在 IO 等等地方特殊处理掉的，这个不是应用程序自己做点什么就能解决的。（其它关于 Java 的内容我就不评论了，这个看场合见仁见智

这个 `当然 syscall 该卡还是卡` 要看是怎么个卡的方式，是卡协程但协程会被调度、还是卡了系统线程。
我前面 #135 里提到的 `系统调用之类的接口` 其实没说完整，准确点讲应该是 `把系统调用那些封装起来然后提供给用户的接口`，例如 go 标准库 net.Conn.Read：虽然它是阻塞的，但它不会阻塞系统线程，实现方式就是当前读不到数据时就调度了并且等待可读，runtime 里的 iocp/epoll/kqueue 等待可读事件到来再唤起。go 里直接去调用可能阻塞的 syscall 也还是可能阻塞，但标准库对于 socket fd 封装出来的 net.Conn 之类的接口都是被 poller+调度这样搞定了的，所以使用标准库的这些是真的可以写同步代码也不会导致线程池阻塞耗尽之类的。
Java 的轻量级线程如果没有配套实现全套的类似 go net.Conn 这些的话，那可能还是没有解决阻塞系统线程的问题，那至少从语言级上，就不是一个类型、不是同一可用级别的协程系统、是没有可比性的

#137
> 我们做架构、框架，最头疼的往往就是进程线程模型、并发之间的通信和一致性这些基本点的设计。

补充：
我们做架构、框架，最头疼的往往就是进程线程模型、并发之间的通信和一致性这些基本点的设计；
我们做业务写逻辑，最头疼的就是写回调，不写回调性能不给力。

语言上大概有学院派、工程派这些不同种类的人，工程上又有 CURD 派、架构派这些不同种类的人。
每个角度上的不同派别，各自的着重点都不一样。
多数学院派讲究茴字的写法是否优雅却忽略了性能之类的指标考量，所以我经常看到这类人概念大把大把地往外掏，经常让我自愧不如、因为不知道他们在说什么，但多数时候等我缓过神来，探究这些概念、优雅的玩意背后真正的实用主义，都觉得似乎并没有什么卵用，然后也就不用耿耿于怀；
工程派追求写法与实用的平衡，当然，实用的基础上也能非常优雅是最好的，但鱼和熊掌难两全，踏实做事情的人，我更倾向于实用主义；
CURD 派，就如我前面所说，能让他们自己舒服的才是最好的，什么性能优雅完全不 care 的感觉，就比如异常处理这档子事，java 的社区惯性用法就真优雅吗？审美可是没有统一标准的，怕是中尉 javaer 自娱自乐自封这样最好罢了；
架构派要考虑好多细节，但凡好点的，也都是工程派，讲求实用主义，多数 java 社区的所谓架构师，我个人都是不认同的，八成就是社区方案一把梭，什么东西适合什么场景都未必去思考过，学以致用，至于用得对不对，反正社区都是用这些东西。。。

当然，业务大了都是堆屎山，大家都是混口饭吃，能挣钱就行。世界本就复杂、好的和不好的共存，大势所趋，被下一阶段的事物取代，代码这档子智慧进化进程中的一个阶段性技术，早晚是 AI 的天下