谈谈我个人的理解哈。

技术（或者说一些实在的东西）是基础，比如在学校、刚毕业，我们都会关注一些技术上的成长，觉得自己能够带来变革。

但是一般到后来才会发现，赚钱多的，有名气的人，大部分都是有资源的，比如有钱的、有权的。所以就会苦苦钻营这些，比如如何赚钱，如何结识贵人，如何谋求权利（不仅仅是自己的权利，还有自己族群的权利）。这就涉及到政治了。

再后来就会发现，钱和权，本质上是关于人的。然后就会想着维护人际关系，把自己织入一个大的社会网络中，让自己成为关键节点。

接下来就是幡然醒悟了。要不就是回归初心，再度钻研技术（或者爱好），由于没有金钱等外在的压力，处于一种“自由自在”的研究之中，乐此不疲，类似科学家。要不就是回报社会，参与公益等等，让自己的人生变得有更大的“价值”。

当然，如上仅仅是我的观察，还很浅薄，需要各位指正。

最后，目标很重要，不管目标是求财还是别的什么，有目标并且坚信的人，是幸福的。

`https://plugins.jetbrains.com/plugins/super-early-bird/list`

虚拟化不能跨架构，要不要试一试 qemu （虚拟化 and 模拟）

golang 的挑战有两个 goroute 和原生二进制，
希望 loom 和 graal 能够早点成熟吧。

我刚好相反，喜欢在公司😂，因为租的房子，没有显示器、办公椅等装备😂。

生产环境，还是不要用 k3c/k3s 了，第一遇到问题资料比较少；第二要调研的东西比较多，比如默认用 sqlite，线上要如何切换到 etcd 。

生产环境还是老老实实 kubeadm （如果嫌麻烦，直接云服务）。

另外，对于本地环境，我一直觉得，在资源允许的情况下，还是尽量保持和线上环境一致，要不然不就失去了 docker 的初心——统一本地环境和线上环境——了吗？
比如 k8s etcd 遇到的 informer 问题，本地用 k3s 就没法测出来😂

可以试一下 reptyr

eci 有预留实例券可以用的。

我 off topic 一下哈。

《人月神话》书中提了软件工程的复杂度主要来自两个方面：本质性的的困难、附属性的困难。

题主所属的，C++过于复杂，可以从其他语言吸收特性等，都是附属性的困难。

但需要注意的是，“没有银弹”的主要原因，是本质性困难的存在。本质性的困难难以解决，因为大部分的活动是发生在人们的脑海里，缺乏有效的辅助工具：
* 复杂性（ complexity ）：软件要解决的问题，通常牵扯到计算步骤，这是一种人为、抽象化的智能活动，多半是复杂的。
* 隐匿性（ invisibility ）：尚未完成的软件是看不见的，即使利用图标说明，也常无法充分呈现其结构，使得人们在沟通上面临极大的困难。
* 配合性（ conformity ）：在大型软件环境中，各子系统的接口必须协同一致。由于时间和环境的演变，要维持这样的一致性通常十分困难。
* 易变性（ changeability ）：软件所应用的环境常是由人群、法规、硬件设备、应用领域等，各因素所汇集而成，而这些因素皆会快速变化。

所以编程语言的发展还是有必要的，在解决附属性困难上很有必要。
但是如果我们要大幅提升开发效率，目前比较好的方向是 AI 、形式化验证等。现阶段，编程语言的进化在解决本质性困难上用处不大。

dubbo

虽然题主限定了“无需声明格式”，但是从回复来看，题主是要上微服务。

那么我觉得还是用 dubbo 或者 grpc 这种成熟的序列化、rpc 方案比较好。
选择一个技术其实是选择了它的生态，比如你在初期选择了 msgpack，那么后续的网关（比如网关的 session 粘滞）、mesh （解析协议内容），都需要选择支持 msgpack 的。初期的技术选型会极大地影响后续的选择。

另外，基于 msgpack 自己做 rpc 框架（或者采用现有的），后续很多已有的坑都需要自己踩一遍（加班 N 小时 /天 /月），比如如何实现流式调用，如何实现 rpc 连接池，如何做监控等。从这一方面来说，dubbo 成熟度比 grpc 要高，官方的模块中包含了很多生产中用到的特性，而且 dubbo3 也会支持 grpc，也能享受到 grpc 的生态优势。

总而言之，如果是自己研究，可以多看看一些序列化 /rpc 框架；如果是生产使用，还是看下业界的流行方案。

这个问题真的很差，完全没有描述清楚问题。

另外，这个可以在 jvms 中找找答案。

loom 还没出，java 的异步编程还是比较难用的

也真是敢用，第三方个人开发者发布的一个镜像，如果里面有木马或者后门呢？

首页不支持 https

cm9iYmVycGhleA== （ base64 ）

谢谢楼主

看需求，个人觉得 flutter 好一点。

官方支持多平台，而且大厂也在逐渐采用。

bashdb?

Java 的默认编译规则是缓存友好的，你不改.java 文件，它就不会重新编译对应的文件。
一般比较耗时的，要不就是打包，要不就是自定义流程。
1. 对于打包而言，java 项目，一般在 IDE 内运行的时候，都是直接编译到 target 目录运行，省去了打包这个流程。
2. 对于自定义流程，很难优化。一般也就缓存一条路了，哦，还有并行编译。

总而言之，开发阶段的编译，时间要尽可能短。

至于“分布式编译”，是有这么个东西，但是不是为了开发过程使用，而是项目快要上线了，重新编译这个项目的问题。
楼上提到了 Facebook 的 Buck，不过那个看起来也仅仅是并行编译，没法利用多台机器。
要真正利用多台机器来编译的话，可以试一试 Bazel 的 Remote Build Execution （我不知道目前是不是已经可用了）。