@sampeng #35 真是张口就来，一个开头全靠编。要啥没啥，好歹列个例子，比如哪些是没有的？
同一个项目，半年后去看？我们现在 n 个项目，一年后去看，还不是清楚明白；而且参与项目的都是毕业 1-3 年的

日常 mac 。需要 linux 环境（不管是 desktop 还是 server ），ubuntu 最新的 lts 版本
就三个字：不折腾

不挑最好的（包括宣称的），只选合适的

@passer9527 #19 好的基本是一个萝卜一个坑

而且国内目前部分需求底层内核的，有些技术含量的面都是极窄极专，比如 gpu 驱动或图形引擎的，或 usb 或 pci 驱动这些

一般人想学习然后进入其中，概率可以直接忽略

@xsen @16 我认识的，包括自己基本都转行。有转后端或物联网的（比如我及之前的 tl ），有跑 RedHat 做咨询的，有转做机器人的。。。。等等

因为国内要吃内核饭，太少；而且也就局限在一两个城市，几个头部企业

@passer9527 #15 内核基本没从 0 开始的，从 98%开始的都没有；除非是芯片原厂，或做 Linux 操作系统（如针对云服务器的方案等诸如此类）发行版的——这样的会开发自己的内核模块（比如内核 rpc 的、虚拟网卡、虚拟磁盘等等诸如此类的）

但绝大多数公司，都是内核定制、驱动移植，稍微好些的还会做一层 HAL （如 android 就是）给应用层调用

若可以选择，真不建议。因为选择越来越少，面越来越窄

音视频（包括 WebRTC ）是面越做越窄，选择越来越少
而且大多数公司都做不起来，因为需要投入大、专注，技术面还极其广

我认识的，包括我自己，N 年实时音视频经验的（包括 WebRTC ），N>=5 ，基本都转行了，除了一个之前做 WebRTC C++ SDK 的去了腾讯

@passer9527 #13 底层最大的一个工作是移植，真的没什么意思
看一大堆代码、一大堆 datasheet ，然后改几行、几十行

做多就会觉得没什么意思。毕竟你不是做内核，只是定制、移植内核驱动，还有就是硬件抽象层（ hal ）

转 linux 底层，不如转后端
linux 底层做多了一样没有意思——而且一个位置一个坑，机会少

@v2vTZ # 237 要规范，不如汇编。寄存器都要指定，更规范。哈哈哈

@pkupyx #226 go 而言呢
1. 对应届或毕业 1-2 年的新手友好，极易上手
2. 对有多年别的语言经验的切换成本极低，不会有任何难度；单纯就是意愿的问题

所以采用 go 技术栈，对说不上名字的中小微厂来说是极其划算的

@wonderfulcxm #131 按照您的意思，吃饭、睡觉、走路（左脚右脚）等等诸如形成习惯的事情，都是 yz

本质上，或许你您是个勤快的人。但我不一样，本质我是个懒人

@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 吗？