@lesismal 接口有个很大的问题是不能只实现部分，也就说接口不适合完成 feature trait 的目标（用接口函数组来定义 concept ，往接口类型里加入新方法后，旧的已实现原来方法的但没实现新方法的类型就无法被 trait 了），但泛型可以。不过这两种语言特性都是为了实现某种形式的多态而存在的，所以很多时候确实也可以相互取代，尤其是在 golang 里语言实现它们的方式还如此类似，基本可以把泛型看做接口的某种简化形式。

这个问题之前讨论过
/t/904511


type typeProxy interface {
Close() error
}

func CanCompile[T T1 | T2](t T) error {
return any(t).(typeProxy).Close()
}

CanCompile(T3{}) // 拒绝编译

用一个接口类型代理 method 访问，并不需要 switch type

你路由器里也 ping 不了 v6 地址吗？
如果路由后面的设备能获得 v6 地址，说明 SLAAC 是没问题的，RA 广播也正常。 看其它各种有 ip 却不通的经历一般都是地址并不可用，比如旧前缀生成的地址未过期，或者路由什么的有问题。你可以看看路由器上获得的是什么前缀，在后面的其它设备上手动配一个 ip 试试

ipv6.baidu.com 的解析挂了。它现在就是没有 v6 地址的。
用这个测：curl -6 ip.sb

你想测自己的 v6 链路有没有问题，最简单的办法是用手机开移动网络来访问你 PC 上的 web 服务器


另外还有，ipv6 的地址是一次分配一个 64 位长的地址段（国内家宽都这样），所以你应该打码的是最前面 4 个段的内容，后面一般都是随机生成的，知道也没用
https://i.imgur.com/sH4ffFd.png

GUI 编程。

对话框类 => 对话框的具体设计
对话框对象 => 几个一模一样但不同的对话框
接口 => 对话框模板

我当初一夜之间领悟 OO 这些概念全靠的是 MFC

喷得好，但是内容和标题有一丢丢偏差，我来帮 OP 重新拟个符合他想表达的内容的标题：


> 我从来没见过比 [JAVA 这种只能面向对象还要试图解决一切问题的东西] 更糟糕的编程范式和语言



深表赞同啊，滑稽

@heiher 所以说，套上 CF 就有双栈了啊，这不是在说建站嘛

不是， 都 2023 年了，我对这楼里的其它回复感到震惊，你们真的没意识到现在已经没有内网穿透这个伪需求了吗？

ALL YOU NEED IS IPv6

我不明白是什么在阻碍你们，我连 wsl 都用得很爽了

是你们的运营商会阻止 ipv6 入站？

有没有一种可能，现在 ipv6 已经是首选了
https://i.imgur.com/vkXqn84.png

再套上 CF ，就能 v4 v6 双栈接入了

你应该让他想清楚，他喜欢的是打乒乓球还是捣鼓打乒乓球的拍子。
并且向他科普，不对，应该大肆渲染一下消费主义这个概念，渲染到他脑子里全是这个概念回到学校还要吹嘘并鄙视一切攀比行为都是「消费主义的陷阱和阴谋」为止

付款验证我这都能打钩，但是最终确认没一次能过的

你账单地址填的和 ip 所在地理位置一样吗？

以及主区域是否有影响？ 我是没尝试过欧洲区域

@vazo 是可以这么类比，也可以看成学习环境中必然存在的变量和意外等等。 但其实还是跟目标问题有很大关系。如果一个机器学习算法要解决的目标问题，有一个确定最优解且能被最终找到，那最后不同随机算法也会收敛到这个解上，这样模型也很有可能是完全相同的。

我觉得你要是稍微了解一下所谓的训练是怎么做的就不会问这个问题。有大量的模型是随机试错再收敛得到的，这个随机过程肯定不会完全一样，但也有少数网络是比较 deterministic 的，比如最经典的手写识别这种。那你重复无论多少次应该都是一样的，不引入变量的话。

如果你需要对数据随用随查随删随改

为什么不数据库？

随时用笔记记录吃饭时、刚起床、看到某个人后，产生的奇妙想法

@Nazz @learningman @leonshaw @lanlanye @RedisMasterNode

我提醒你们一下关于放到对应序号结果槽的实现：


- 这个结果 array （它有大小，我这里用 array 来称呼，并不是指实现），是有「洞」的，需要有个机制能按顺序检查每个位置是否完成了，没完成要能阻塞住，意味着 array 里放的是锁或 chan 或任意什么东西总之是一个可锁对象，但有 promise 的情况下不需要这种可锁对象

- 我们不能一次性等待一批 worker 全部完成，而是要时刻能分派已完成的 worker 占用的任务槽

- spwaner 本身要可以等待或阻塞

@RedisMasterNode @Nazz @leonshaw

不是的，wait group 只能在所有任务完成前一直阻塞住。而作为一个 spawner ，你需要时刻维护一个有长度的队列，当队列空出来时立即解除正在预约（ schedule ）任务的 routine 的阻塞，wait group 显然不合适。


注意我们的目标是，让结果按照添加的顺序依次输出，而不是一次性等待所有的结果一起输出。


有异步语法的语言，在这个场景的做法是

- 一个有长度的阻塞队列
- 当外界 scheduling 新任务时，spwaner 向队列获取一个空槽，如果队列已满，那么 spanwer 和 请求者都会被阻塞
- 如果获取了空槽，将任务放入空槽，获得一个 promise
- 创建新 promise, 在这个 promise 里 { await 任务队列的尾部任务（因为我们需要按任务的添加顺序而不是任务完成顺序来返回），await 到之后返回上一步获得的 promise }
- 把上面这个 promise 加到 out 队列里，每次提取结果时 await out 队列的头部


而 golang 要模拟这个做法的话，首先它没有 promise ，也没有 goroutine 的 handler ，然后要实现跟上述等价的 spawner 必须使所有调用 spanwer 的线程共享同一个 channel ，意味着 chan 要么是全局的，要么扔到 context 里。先简单考虑全局唯一 chan 的做法。（但复制 chan 用 context 传这种逆天玩意我也写过）

提取任务槽这步没问题，但怎么模拟一个 promise ？
- c := make(chan,1) ; go func(){c<-do();)}

那怎么获取任务队列的尾部任务并 await 它？
- 如果任务队列只是个简单的 channel 是做不到的，因此需要一个 slice + channel ，可是 slice 就没有锁了，你这时候要考虑一个可阻塞环境（ chan ）下的锁问题，头开始疼起来了

怎么返回 await 了 c 的新 promise ？
- ……

对了，这个新 promise 还要放到 out 队列里
- …………