- 主题:编程语言中的null，算不算是一个失败的设计？
null的始作俑者自己早就承认了，是一个多少billion的失败了啊
https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/
所以kotlin、dart啊啥的，都加了编译器层面的东西搞定这个问题
Rust和cpp后来的搞法，是optional吧
--
修改:z16166 FROM 125.35.125.*
FROM 125.35.125.*
std::optional(cpp)、std::option(Rust）可以认为就是一个object，两种状态：有值、无值。
kotlin的搞法是码农要告诉编译器某个变量的值是否可能为null，用语法糖 ? 区分，
对于可能为null的变量，编译期跟踪码农是否做了null check，不做的编过不去。
对于一定不会为null的变量，禁止可能的null赋值。
【 在 chaobill 的大作中提到: 】
: 返回 object 多好，然后由语法检测是 empty
--
FROM 125.35.125.*
cpp的optional还不是针对指针的
主要内存分配失败这个操作没法完全避免，失败时也没法返回一个有意义的值（会被拿来读写内存），如果不想null被到处传播，那就只能就地panic或者扔异常，但有些应用不能这么干。
GSL里搞了个not_null，只能部分缓解
https://visualstudiomagazine.com/articles/2016/06/01/using-the-not_null-template.aspx
【 在 hgoldfish 的大作中提到: 】
: 关键是默认整个编程环境都是 non-null 的，optional 也是少部分，免得心智负担太重。现有语言写多了都是 optional<> 和 ?. 到处飘，很丑很恶心。
:
--
修改:z16166 FROM 125.35.125.*
FROM 125.35.125.*
用go的码农不需要关心内存分配和释放，
但是go runtime的实现者需要关心这个问题，不把内存分配失败作为null暴露给码农，那就只能在out of memory时直接panic了。
【 在 littleSram 的大作中提到: 】
: 我也不喜欢optional，没什么本质改变，还不如go的默认值设计，字符串永远不会为null
: :
--
FROM 125.35.125.*
null涉及的是关心的是失败与否，不是性能。
【 在 littleSram 的大作中提到: 】
: 写go的一些高性能库的，也要关心的。是分配到goroutine的栈上还是堆上。
: :
--
FROM 125.35.125.*
make和new？卧槽这个口子一开，等于是go和cpp在null问题上是一样的啊
go的文档貌似没描述new在内存不足时是返回nil，还是直接panic。估计得看实现代码？
如果能接受new直接抛异常，cpp其实可以不用处理null。
pure C也可以规定用统一的allocator，做到内存不足时直接panic，而不返回null。
可惜的是很多情况下同一个team的各人搞各人的，各种代码写法混在一个工程中。调用的第三方库也得封掉null。
另外有些工程不允许直接panic。
【 在 littleSram 的大作中提到: 】
: go有指针，会有dereference
: :
--
修改:z16166 FROM 125.35.125.*
FROM 125.35.125.*
null没问题，而且避免不了（没人能避免内存分配失败，顶多失败后不传播这个null出去）
null ref/deref有问题，应该想办法避免。
【 在 ackerx 的大作中提到: 】
: NULL为什么失败？没懂。挺好的啊。
--
修改:z16166 FROM 123.115.163.*
FROM 123.115.163.*
应该是取决于造的是原子弹还是茶叶蛋
茶叶蛋随便崩，原子弹崩了就是大事故。
比如有HA要求的业务，不能随便崩，即便是有watchdog、主备切换的。
不过我也没造过原子弹，就是YY一下
【 在 libgcc 的大作中提到: 】
: 我想问下
: 你们代码里真的会去去处理内存申请失败的逻辑么
: 我觉得一般情况下应用程序申请不到内存,这机器也干不了什么了,程序挂不挂已经不重
: ...................
--
修改:z16166 FROM 123.115.163.*
FROM 123.115.163.*