从方便合作角度肯定不希望有几十种语言，但是现有三四种之外某团队尝试一种新的我觉得还好吧。

不考虑合作问题的话我觉得是真无所谓，现在微服务+docker，你用啥写都行。

【 在 gqlu 的大作中提到: 】
: 贵司对于语言的选择有没有限制？ 只要完成任务就行？
--
FROM 140.207.23.*

一般的，判断图灵机m（递归函数，程序）是否有性质P都可以规约到停机问题。
类型系统的做法是在全体有性质P的程序集合S里面划一个子集T，有算法（type checker）可以判断任意代码c是否属于T。若属于T（类型正确），则c必有性质P。若不属于T（类型不正确），则c可能有也可能没有性质P。
类型系统有三个矛盾的目标：
1 T的定义要简单（人能理解）
2 判断T成员的算法要高效（编译器类型检查快）
3 T覆盖尽可能多的S，至少是常用的部分（人不用跟类型系统搏斗）

以上对“判断程序没有内存泄漏”和“判断程序没有访问野指针”同样适用。
这里的区别，可能是能证明前者的类型系统，其T太小（太多没有内存泄漏的程序不能通过类型检查）。

Rust有趣的是它T的定义和判断算法都没有明确，允许编译器越来越“聪明”（允许当前版本不通过类型检查的代码在下个版本更复杂的类型检查算法（扩大了的T）下通过）。

【 在 F001 的大作中提到: 】
: 没什么奇怪的。这两类问题本质上是停机问题，不可能单靠静态检查解决。你读一下我以前写的这篇文章
: https://zhuanlan.zhihu.com/p/22294916
--
修改:ilovecpp FROM 123.147.250.*
FROM 123.147.250.*

你们越说越复杂（且不正确）了。
一般对语言是否有gc的概念很简单：
缺省所有内存都自动回收，也许可以显式分配不自动回收的内存(opt-out)：语言有gc。
需要手动使用某个库（即使是标准库）对一部分内存实现自动回收(opt-in)：语言没有gc。

【 在 eGust 的大作中提到: 】
: 引用计数怎么到你那里就变成 gc 了？上个世纪在 gc 出来之前 reference counting 就在用了，比如早期的 delphi、win com，对循环引用的处理方式就是不处理。
: 为了解决循环引用问题，有两种方案，一种是 weak reference，说白了还是不处理；另外一种才是用 gc 来解决。而在实践中如果一门语言高度依赖 reference counting，那么基本上都是不处理的，换句话说由程序员负责 weak reference，写错了就泄露。
: 道理很简单，引用计数的 overhead 非常高。而 gc 的问题只是发生回收时的高延迟，它本身不破坏执行流水过程，不破坏 cpu cache，反倒提高了不发生回收时的运行速度。所以在实践中 gc 跟 reference counting 是对立的概念，如果说有 gc，那不大可能是基于引用计数实现的，反过来如果说用了 arc，那大概率就得你自己管 weak reference。
: ...................
--
FROM 61.170.164.*

struct TreeNode
  list<shared_ptr<TreeNode>> children
改用什么？

【 在 hgoldfish 的大作中提到: 】
: 这时候报个错，让程序员改用 weak_ptr 可以吧。
: 还有继承的情况：
: struct Parent {
: ...................
--
FROM 112.64.68.*