也许他认为给你个 ip,账号密码,你就该能搞定(这点屁事还要老板教么)。可是你搞不定？
老板已经讲清了他的需求，听不懂，不理解就问啊。
对于老板提的需求，千万别不懂装懂。

这不是 ub，这是野指针

不知道咋贴图，将就看一下 ￣ ￣)σ

所谓老司机，就是开车老老实实的司机

低水准的就别用 c/c++了

搞个 vps

同事一直纠结华为还是小米。然后买了 MagicBook，刚买来就坏了，不给换只给修，结果查出来是主板坏了，拿去修了三个月。整天抱怨，摊上这样的，恶心不恶心？

没工牌，不打卡

max3

教主都死了好些年了，还在迷信苹果

kcptun 的前向纠错抢带宽抢的太厉害，
所谓前向纠错，就是这个算法可以做到 n 个包编码成 n+m 个，收到其中的任意 n 个就能恢复原始 n 个数据。
所以只要 m/n 大于丢包率，就能基本保证不用重传数据。
随着丢包率上升，只要调整 m 值，就能保证速度和数量。
有限带宽下，kcptun 把带宽都抢走，别人就没的用了，大家都用 kcptun,网络就堵死了。因为丢包率越来越高，所以发包的 m 值越来越大，这是个死循环。
即使基于这个原因，封锁 kcptun 也是合理的。所以，还是尽量少用

机器人发帖？

项目失败了呢？谁承担责任？

@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
...
}