一到周二晚上就不知道干什么。
周三往后基本就看着AS的直播摸鱼了。
周一拿Hanser当AS代餐。
周二谁都不播。只能看看QA。
尤其是现在，周二前半个晚上还有课。
上完课以后就更不想干活了。
打完一局Dota，离回去还有这么一会。很尴尬。
把5223的lab写完以后，下一项既定任务是写一个OJ。总之今天先写了写自己玩的。
虽然oskr用C++写了很多，但是还是想换成Rust。
一个是C++虽然是C++20，但用起来还是很衰老。
给人一种满头白发还学年轻人赶时髦，常怀一颗年轻的心，的心酸感觉。
另一个是，随手捡出来一篇看起来平平无奇的论文准备组会上讲，然后发现它是用Rust实现的。
忽然感觉，除非我已经是业界翘楚，有决定自己技术栈的资本，否则我就得用Rust来写，不然，我就得另外花精力证明自己的先进性。
明明Rust才是我的主场啊。
为什么要放弃主场，然后还要被人误会不先进呢。简直自讨苦吃。
用Rust写oskr不算容易。好在已经尝试了好多次，这回的模型接口似乎已经足够合理的。
目前只有一点小瑕疵。
Transport在各个Receiver之间共享，因此套在Arc里面。只要求我们一旦开始构建Receiver，Transport就不能再变化了，即再也没有&mut。
然而，如果想把Receiver注册在Transport中，就要更改Transport。也就是说，需要在创建Receiver以后再更改Transport。两者产生了矛盾。
实际上，注册一个Receiver并不需要创建完整的Receiver（即持有Transport的Arc的对象），因此，按照Rust的正确，应该把Receiver的创建拆开成两个阶段。
这个思路理论上可行，只是直接写肯定要写很多无聊的代码。想想怎么搞简练一点，看起来好看点。
当然，还有其他更赋予表面的方法，以前的我也能想得到的，比如把Transport包在Mutex里之类的。那种就太滑稽了，不会再考虑的。
以后这种时候可以考虑看一会Software Foundation。