应该是 TED 那期的例子吧？这两个不是可读性的问题，是第二个就是更好。但除非你写的是 C/C++，否则恐怕没法写出这样的代码…

尽管 low code 作用很有限，但你说的这个问题并不是它独有的问题，只能说开发团队没处理好……

JWT 和 Session ID 一起出现本身就挺奇妙的……
一个用于无状态，一个用于有状态。

给老人 15 应该够用了吧？除非你说出使用场景。

@yh7gdiaYW Web 项目本身也不会有很多 CPU 密集型任务，真有的话拆出去 C/Rust 写了做远程调用就好。
我看你下面还提到了微服务，k8s 和服务网格可以用语言无关的方式解决微服务的大部分问题，只要想做语言并不是问题。
相对的 Python 写业务逻辑速度很快，语言特性多，抽象也好做，在数据转换和处理上极其方便。
退一步说它可以做胶水去粘 C 和 Rust 代码，也可以直接编写 Spark 任务，适用性很广。

有些插件会提供一个可配置的解释器路径给你，没提供的话估计就没什么办法了

暂时没觉得…Python 和 Go 都能写，最近越来越觉得大部分业务 Python 写舒服多了，再说上个机器学习相关的功能你最后不是还得用回 Python……

@fyxtc #5 大部分人应该还是会先选择微信吧……好像是现在通过接口让用户直接授权手机号变难了，但有些应用为了合规又必须记录才会搞成这样。

@ldp940622 #3 对，所以我现在可能会选择手机号+验证码

人事开始强调考勤和绩效，出各种复杂制度，一般都是冲着所谓降本增效去的。
但大多数时候并不能增效，把忍不了的逼走就算降本了。

GPL3 ？好评

我记得作者来站里做过推广，怎么搞成这样了？

优点当然也是有的：

1. 可以练手，不然你下一份工作的简历怎么办？
2. 容器化管理起来确实容易，哪怕我就俩服务，用 k8s 也方便些，至于你说消耗的资源……那是老板的钱，又不是我的。
3. 战未来，万一火了呢？
4. 微服务不仅能拆分大型软件，还能方便拆分团队，如果一个项目有很多个组参与，使用微服务会比写成单体然后让大家工作在同一个仓库下容易些……同理，如果前提是没几个用户，进程内通信和跨进程通信相比那点优势也微不足道。至于额外的复杂度，k8s 也基本能解决，没几个用户的项目又能复杂到哪儿去呢？

额外建一张表存 B2 和对应的统计值，每次插入在同一个事务里往主表插入并让副表统计值+1 。

这个升华部分的批判毫无道理……就好像在批判 Java 这样有 GC 的语言让程序员的平均水平降低了一样……
事实上确实降低了，但它同时降低的还有这个行业的门槛，最终的结果是提高了整个行业的生产效率，而效率才是市场真正追求的东西。
至于顶尖人才变少，这个不知道有没有具体数据支撑？也许这些人的绝对数量并没有什么变化，给你这种感觉是因为他们占行业总人数的比例减少了。

需求简单的话，Ruby 的 RoR 或 Py 的 DRF 了解一下

都微服务了，要不整个 k8s 吧……也算 Go 技术栈，后面你说的这些需求甚至可能不怎么需要写代码就能解决了。