- 主题:编程语言中的null，算不算是一个失败的设计？
我觉得不是，现实中确实有missing的概念
go语言想去掉null，但是不行，切片，函数还是nil
而且很多时候我们想知道哪些值是missing
但是go有默认值，搞得不知道到底是不是入参
不过go确实避免了大量的Null判断，for循环nil值也不会报错
【 在 shibor 的大作中提到: 】
--
修改:littleSram FROM 124.64.18.*
FROM 124.64.18.*
我也不喜欢optional，没什么本质改变，还不如go的默认值设计，字符串永远不会为null
【 在 hgoldfish 的大作中提到: 】
: 关键是默认整个编程环境都是 non-null 的，optional 也是少部分，免得心智负担太重。现有语言写多了都是 optional<> 和 ?. 到处飘，很丑很恶心。
:
--
FROM 124.64.18.*
写go的一些高性能库的，也要关心的。是分配到goroutine的栈上还是堆上。
切片是个好东西，但是只要动态改变大小就要在堆上重新分配，所以各种技巧就来了
【 在 z16166 的大作中提到: 】
: 用go的码农不需要关心内存分配和释放，
: 但是go runtime的实现者需要关心这个问题，不把内存分配失败作为null暴露给码农，那就只能在out of memory时直接panic了。
:
--
修改:littleSram FROM 124.64.18.*
FROM 124.64.18.*
go有指针，会有dereference
【 在 z16166 的大作中提到: 】
: null涉及的是关心的是失败与否，不是性能。
:
--
FROM 124.64.18.*
是啊，稍微深入用go，就发现傻眼了
好多人问什么时候用 T，什么时候用 *T，哪个性能好
go官方给的回答是，看情况，如果不确定该用哪个，就用 *T
【 在 z16166 的大作中提到: 】
: make和new？卧槽这个口子一开，等于是go和cpp在null问题上是一样的啊
: go的文档貌似没描述new在内存不足时是返回nil，还是直接panic。估计得看实现代码？
: 如果能接受new直接抛异常，cpp其实可以不用处理null。
: ...................
--
FROM 124.64.18.*