@cokyhe #136 其实习惯了 c 那样的错误处理的，都习惯 go 这样的错误处理
一定程度上也与做的偏底层有关——能处理的错误都处理，而不是就往上抛，个人觉得这是个好习惯

@dbskcnc #138 还真是，哈哈哈哈。这句话或许有道理（哈哈哈），

I also noticed that those who dislike Go and like Rust instead, tend to be in their 30s and under.

@wonderfulcxm #119 因为用 go 心智负担低，很多人都用脚投票了。而且有多年经验的人，用 go ，大概率是一圈语言都转了个遍，最后选了 go

@pkupyx #217 也不算冲突，人难找的意思是因为 go 本身用的人不算多（相对 java 来说），所以出来的人更少。也跟我们要招的前端，还有 c++的一样（其实 c++更少）

但 go 来说有个好处，就是别的语言的真的很容易转。比如我看到的，包括应届、毕业 1-2 年，或毕业多年（ 3 年以上）别的语言开发经验的，如原来做 web 前端的、ios 的、java 的、c++的，都很容易就转过来做 go

从我看到的数据来说，经验丰富的 2 周左右，不太丰富的 1-2 个月左右

@Lancer777 #210 招聘职位是少。因为我说的中小厂都不算的传统行业的公司，如物联网、家电、电力这些，go 的岗位都是内部直接转了。很少对外招聘

因为对外招聘回来的，又不了解本行业的业务

@pkupyx #197 恰恰相反，你不知道的是：
很多连中小厂都算不上的中小企业，很多还是传统行业的，都在选择用 go 这个技术栈

人是难找，轮子是少，但是，
1. 别的语言转 go 容易，有经验的 2 周左右；刚毕业 1-2 年的 1-2 个月左右
2. 大多数轮子都有。部分轮子自己造——不能造，反正都面向接口、服务变成，换 Java 写个服务也不是那么难

如何把一段简单的代码变复杂？
https://www.zhihu.com/question/277243683/answer/393676961

换个人话的说话就是，Java 为什么越来越啰嗦、越来越重——过度设计
——————————————————————————————

作者：Damon DanceForMe
链接： https://www.zhihu.com/question/277243683/answer/393676961
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

这问题你应该去问企业级 Java 架构师。就比如 print 一句 hello world 吧。main 函数里 print 一下？太面向过程，太 low 了。得封装一个类。叫 Printer. Printer 有个成员方法，叫 print 。但是！光一个类太 low 了，以后要是有不同的实现怎么办？所以得加一个接口。PrinterInterface 。但是！ interface 是没有实现的，还是要有默认实现才行。所以得加个虚拟类，AbstractPrinter 实现 PrinterInterface ，然后 Printer 继承 AbstractPrinter 。但是！你有了那么一套，该怎么创建实例呢？直接 new Printer()？太 low 了，那叫实现依赖。肯定不行的，所以要搞一个工厂类，PrinterFactory ，PrinterFactory 用 PrinterInterface 返回实例，这样就隐藏了实现细节了。但是！ PrinterFactory 本身也是实现类啊，太 low 了，所以得有 PrinterFactoryInterface, AbstractPrinterFactory. 而且在 PrinterFactory 里面该怎么写呢？直接 new Printer()? 太 low 了。还是实现依赖。最后，你要把这一堆玩意在代码里组装起来，也太难看了，各种 new 实现类。太 low ！好在我们有个高级玩意，叫依赖注入！把程序对象结构全写到配置文件里面。这一套当然是不能自己造轮子的。配置 Spring 吧。搞了那么多 lib ，靠命令行或者 IDE 的项目管理肯定不够啊，得有依赖管理。Maven 啊 Gradle 啊使劲上。最最后，要 print 的东西怎么传给程序呢？硬编码？命令行传参数？太 low ！当然得写在 XML 里头。光是 XML 当然还不够企业级，再加上 DTD 验证吧。然后就涉及到了 XML 解析的问题了。代码里直接操起 parser 吗？太 low! 当然要写个 parser 的包装类，interface, abstract class, implementation class, factory class 再来一套。毕竟，不能依赖实现啊，以后我要是换 parser 了怎么办。所以最后是成品是一堆配置文件，一堆 jar ，compile 出来的程序 200MB 。IDE 得装上 300 个插件，打开项目硬盘响老半天吃掉 2GB 内存，然后一堆插件弹提示要求升级。哦对了，在这一切发生之前，还得画 UML 图呢。三年后项目完工了，部署到客户的服务器上一跑，立马崩溃，一地的 stack trace 。原来客户服务器上用的是 JDK 5 而新项目需要 JDK 6. 然后问客户你们不能升级吗，答案是不行，因为另外一个企业级开发组给做的企业级解决方案只支持 JDK 5 。接着客户把你们的架构师臭骂了一顿，你搞了那么多设计就没有想过可能会换 JDK 吗？

@Tentails666
@chendy
@asanelder
说的好像各种厂的基建就自己用的一样，那干脆各种厂把云都内部开放得了，还卖 p

用了多年 Windows/Mac/Linux ，发现还是喜欢 Redhat4

deepin

用了 N 年 window + linux ，还是喜欢 Mac 。mac = window + linux
不折腾不折腾不折腾

@fawdlstty #31 #2 架构并不需要很深的技术，只是需要某些方向很深入 + 技术广度

go-zero+1

有服务器则自建 gitlab ，没有则 gitee （毕竟速度还是可以）

yapi+1

@MiketsuSmasher #90 若你是运维，自然要搞明白，确实某些问题搞不懂就很难解决；若不然，什么都要想搞明白，你这叫不务正业

@monster33 #62 snap 又不是必选项，一直用 apt-get/apt 有不会有什么问题；所以吐槽 snap 的是为了吐槽而吐槽

@yzbythesea #67 你这是闲的蛋疼的操作，什么都要去了解为什么