@janxin 我的意思就是省掉 check, 让用户写代码不用那么恶心，改变啥行为了？ 难道加个 handle 就不改变 Go1 的行为，就能编译了？

@janxin Go1 编译 Go2 代码？

@janxin 不明白你说的作用域问题在哪里
相对于 新草案的
r := check os.Open(src)
比较一下这个
r,err := os.Open(src)
哪个更兼容 GO1 ？
没有定位 handle,后边这个不就是 Go1 的语法么？
定义了 handle 的情况，这个明确指定了 handle 过程组，难道不更好吗？

@janxin
没懂你的意思
看代码
r, err := os.Open(src)
变成草案:
handle err { return fmt.Errorf("copy %s %s: %v", src, dst, err) }
r := check os.Open(src)
或者我说的
handle err { return fmt.Errorf("copy %s %s: %v", src, dst, err) }
r,err := os.Open(src)
哪个看起来更简洁？
反正我是很讨厌在每次函数调用加上个 check 前缀，这太啰嗦了

check handle 一点也不简洁。
check 完全可以省掉。
比如这样
func service1()(string,error){}
func example() error {
handle error1 {
.....
}
res1, error1 := service1()//error != nil 时 触发 error1
...
}

svn 直接连家里去，家里的 svn 再 rsync 备份

都是一群中医西医都不懂的人跟这瞎喷。

所以呀，有病还是找大夫，别来问程序员。

路由器内存太小了，软件稍微有点内存没及时释放，就没内存可用了。

人不要脸，天下无敌

性能

记性越来越差，一般先写注释，然后看着注释填代码。
不然写着写着就忘了先前的思路了

我弄的是铝铸的盒子，整个盒子就是散热片

进程多了，切换进程上下文环境也耗 cpu 资源,100 多进程对 tinyproxy 真不算多

tinyproxy 一点都不 tiny,每条连接起一个进程，每个进程占几兆内存，绝对是吃内存的货。路由器上跑这个，内存小了肯定不合适。

单进程单线程 600 万订单每秒？真的假的啊？

看你对"懂"这个字怎么理解，我的理解是:懂=别人问不倒你=完全掌握

1.有没有定接口协议？
没规范，那是规范制定上有问题。
2.有没有经过测试？
没测试，那是工作流程上有问题。
3.如果问题 1 是 yes,2 也是 yes，那就没这个问题。
如果 1 和 2 都是 no.那就扯皮吧