1
00:00:00,000 --> 00:00:00,300
大家好

2
00:00:00,366 --> 00:00:01,633
这里是 AsyncTalk

3
00:00:01,666 --> 00:00:03,466
我是 AsyncTalk 主播 Annatar

4
00:00:03,533 --> 00:00:05,233
今天想跟大家来聊一聊

5
00:00:05,233 --> 00:00:07,133
前段时间发布的一个 typescript 7 

6
00:00:07,166 --> 00:00:08,700
我相信大家在去年的时候就已经

7
00:00:08,700 --> 00:00:10,966
收到这个比较爆炸性的新闻了

8
00:00:11,000 --> 00:00:13,433
就是 typescript 它去拿 go 来去做重写

9
00:00:13,466 --> 00:00:15,733
今年它终于把这个端上来了

10
00:00:15,800 --> 00:00:16,633
那 typescript 7 

11
00:00:16,633 --> 00:00:19,200
它有非常巨大的一个性能提升

12
00:00:19,266 --> 00:00:21,700
它的性能提升达到 10 倍左右的样子

13
00:00:21,733 --> 00:00:22,166
首先一点

14
00:00:22,233 --> 00:00:25,333
Vscode 它的 一个 TSC 的这个类型检查

15
00:00:25,366 --> 00:00:27,666
从 78 秒降低到了 7.5 秒

16
00:00:27,766 --> 00:00:29,433
这是一个非常巨大的提升

17
00:00:29,466 --> 00:00:30,766
尤其是像 VSCode 

18
00:00:30,766 --> 00:00:32,433
这样一个超大的项目来说

19
00:00:32,466 --> 00:00:35,033
那其实我公司那边也有个项目

20
00:00:35,033 --> 00:00:38,466
它是一个大概 58 万行代码的一个量级

21
00:00:38,500 --> 00:00:40,466
那这个量级代码检查速度

22
00:00:40,633 --> 00:00:43,533
它是一个 TS 6 是 14 秒左右

23
00:00:43,533 --> 00:00:45,800
当我把它升到 TS7 的时候

24
00:00:45,866 --> 00:00:48,633
它只有大概3秒钟左右的一个检查

25
00:00:48,666 --> 00:00:50,333
它效果是非常明显的

26
00:00:50,366 --> 00:00:51,200
虽然我们代码仓库

27
00:00:51,200 --> 00:00:52,733
没有达到十倍的这个效果

28
00:00:52,766 --> 00:00:56,966
但是它已经让人非常的惊艳了

29
00:00:57,000 --> 00:00:58,033
最主要的是这个

30
00:00:58,033 --> 00:01:00,666
升级过程是几乎无痛的

31
00:01:00,733 --> 00:01:02,066
如果你的产品比如说

32
00:01:02,066 --> 00:01:03,633
普通的一个 Web 开发的一个产品

33
00:01:03,700 --> 00:01:06,166
其实对你来说它是完完完全全无痛的

34
00:01:06,200 --> 00:01:07,666
基本上像我们代码写完之后

35
00:01:07,733 --> 00:01:08,733
我们有一些 lint

36
00:01:08,766 --> 00:01:09,800
有一些类型检查

37
00:01:09,866 --> 00:01:11,366
那类型检查我们基本上

38
00:01:11,366 --> 00:01:14,100
是去调 TSC 的这个命令行去做的

39
00:01:14,133 --> 00:01:17,333
如果你也是这样一种普通的项目的情况

40
00:01:17,366 --> 00:01:20,000
你今天就可以完全直接无痛替换了

41
00:01:20,066 --> 00:01:22,266
因为对于这种 CLI 使用的场景来说

42
00:01:22,300 --> 00:01:24,200
基本上是没有任何变化

43
00:01:24,266 --> 00:01:27,133
它只是一个内部代码的重写

44
00:01:27,166 --> 00:01:28,433
它去拿 go 去重写

45
00:01:28,500 --> 00:01:30,266
用了一些多线程的一些技术

46
00:01:30,266 --> 00:01:33,200
来去加速整个检查的过程

47
00:01:33,266 --> 00:01:34,466
其实对我来说最重要的是

48
00:01:34,466 --> 00:01:36,433
关于编辑器的使用

49
00:01:36,466 --> 00:01:37,733
但我知道大家现在基本上

50
00:01:37,733 --> 00:01:40,533
可能已经去拿 coding agent 来去做

51
00:01:40,566 --> 00:01:41,900
可能相当一部分人

52
00:01:41,900 --> 00:01:44,400
都已经不怎么看代码了

53
00:01:44,466 --> 00:01:46,833
但对于我这种稍微有些传统的人来说

54
00:01:46,866 --> 00:01:48,966
我还是有时候去拿这些编辑器

55
00:01:48,966 --> 00:01:50,500
来去做一些事情

56
00:01:50,533 --> 00:01:51,733
来去检查一些代码

57
00:01:51,766 --> 00:01:54,200
自己要手动微调一些代码的场景

58
00:01:54,266 --> 00:01:55,866
那在这种场景下

59
00:01:55,900 --> 00:01:58,233
TS7 它所带来的变化

60
00:01:58,233 --> 00:02:00,200
对我来说是最为重要的

61
00:02:00,266 --> 00:02:01,333
我在工作的时候

62
00:02:01,366 --> 00:02:03,733
有一个项目是从前几年

63
00:02:03,733 --> 00:02:06,300
大概 200 万行代码的规模

64
00:02:06,300 --> 00:02:08,133
拓展到最近大概开始

65
00:02:08,133 --> 00:02:10,466
有一个 300 万行代码的一个级别了

66
00:02:10,533 --> 00:02:11,700
当你在维护

67
00:02:11,700 --> 00:02:16,100
一个如此量级的代码库的时候

68
00:02:16,133 --> 00:02:18,500
你会发现里面有很多各种各样的问题

69
00:02:18,533 --> 00:02:19,333
它都放大了

70
00:02:19,366 --> 00:02:20,533
像我之前有跟大家

71
00:02:20,533 --> 00:02:22,466
在 Oxlint 里边提到过的

72
00:02:22,466 --> 00:02:24,100
说一个编译速

73
00:02:24,133 --> 00:02:25,400
一个速度的提升

74
00:02:25,466 --> 00:02:28,100
同样在这样一个巨大项目的情况之下

75
00:02:28,133 --> 00:02:30,433
你的代码编译器承担的任务

76
00:02:30,433 --> 00:02:31,733
是非常庞大的

77
00:02:31,800 --> 00:02:33,300
那你就像我那个项目

78
00:02:33,333 --> 00:02:34,966
我一天打开编辑器

79
00:02:35,033 --> 00:02:36,666
基本上编辑器里边的 

80
00:02:36,666 --> 00:02:38,833
 typescript language Protocol LSP 

81
00:02:38,833 --> 00:02:42,000
基本一天是要 crash 个五六七八次的

82
00:02:42,033 --> 00:02:44,233
因为里边要么就是代码占用太高

83
00:02:44,266 --> 00:02:45,500
要么就是 CPU 太高

84
00:02:45,533 --> 00:02:45,633
当然

85
00:02:45,700 --> 00:02:46,766
我没有细查过问题了

86
00:02:46,833 --> 00:02:48,333
但情况就是这样

87
00:02:48,400 --> 00:02:50,600
它就是会 crash 非常多的次数

88
00:02:50,633 --> 00:02:52,266
我相信是因为我们的代码量级

89
00:02:52,266 --> 00:02:54,733
有些过于庞大了

90
00:02:54,800 --> 00:02:56,966
当我们迁移到 TS7 的时候

91
00:02:57,000 --> 00:02:58,366
它带来的效果不仅仅是

92
00:02:58,366 --> 00:03:00,200
这个项目并不 crash 了

93
00:03:00,233 --> 00:03:03,900
而是当在进行一些 TS 类型提示的时候

94
00:03:03,900 --> 00:03:05,366
它会响应的更快

95
00:03:05,400 --> 00:03:08,033
这个快是随着你这个代码量级越大

96
00:03:08,100 --> 00:03:09,000
它越明显的

97
00:03:09,066 --> 00:03:09,466
当然了

98
00:03:09,500 --> 00:03:10,500
300 万那个项目

99
00:03:10,533 --> 00:03:12,333
我并没有去做这个升级

100
00:03:12,366 --> 00:03:14,233
因为它的升级有点可怕

101
00:03:14,300 --> 00:03:16,400
但是对于 58 万行的那个项目

102
00:03:16,466 --> 00:03:17,533
这边有做升级

103
00:03:17,566 --> 00:03:18,533
那升级之后

104
00:03:18,566 --> 00:03:20,566
我自己体感效果是相当不错的

105
00:03:20,566 --> 00:03:22,266
应该是没有再 crash 过了

106
00:03:22,300 --> 00:03:24,633
它的代码的类型的提示速度

107
00:03:24,633 --> 00:03:26,800
我体感上也有一些提升

108
00:03:26,866 --> 00:03:28,800
但是我前面说的那种项目

109
00:03:28,800 --> 00:03:31,133
都是一个非常标准的 Web 开发项目

110
00:03:31,200 --> 00:03:34,066
它都是一些 TSC 的命令行的工具

111
00:03:34,100 --> 00:03:34,933
如果你的项目就有

112
00:03:34,933 --> 00:03:37,333
用到 typescript 的 API 

113
00:03:37,333 --> 00:03:39,433
那情况就会变得有点麻烦了

114
00:03:39,500 --> 00:03:40,166
比如说

115
00:03:40,166 --> 00:03:44,966
至少在 next 13.2 的一个版本之前

116
00:03:45,000 --> 00:03:46,366
它实际上 lint 是通过

117
00:03:46,366 --> 00:03:49,033
typescript 里边的 API 来去做的

118
00:03:49,100 --> 00:03:50,833
那它就需要去调用 

119
00:03:50,833 --> 00:03:52,733
typescript 这个包里边的 API 

120
00:03:52,733 --> 00:03:54,133
来去做一些事情

121
00:03:54,166 --> 00:03:54,933
那这种情况

122
00:03:54,966 --> 00:03:57,800
它在于 TS7 还是没有原生支持的

123
00:03:57,800 --> 00:03:59,766
像一些大的开源库

124
00:03:59,933 --> 00:04:03,200
目前据我所知是已经支持了

125
00:04:03,233 --> 00:04:05,166
那比如说像 next 13.3 

126
00:04:05,166 --> 00:04:06,500
其实可以通过 next config 里面的

127
00:04:06,500 --> 00:04:10,066
一个 experimental use typescript 的 CLI 的

128
00:04:10,066 --> 00:04:11,833
这样一个参数去开启

129
00:04:11,866 --> 00:04:14,133
那这样你的项目如果只有 nextjs

130
00:04:14,200 --> 00:04:16,433
它就可以升级到 7 了

131
00:04:16,466 --> 00:04:18,233
然后正常的去使用

132
00:04:18,266 --> 00:04:20,566
但是如果你有一些其它的项目

133
00:04:20,633 --> 00:04:23,266
比如说我之前有推荐过的 hey API 

134
00:04:23,300 --> 00:04:25,666
它去通过有一些 

135
00:04:25,666 --> 00:04:27,866
typescript 里面 API 的调用

136
00:04:27,900 --> 00:04:29,000
对于这样的项目来说

137
00:04:29,066 --> 00:04:30,266
你可能就要去观察

138
00:04:30,266 --> 00:04:32,566
它们的仓库的这个兼容情况了

139
00:04:32,633 --> 00:04:33,633
据我了解到的消息

140
00:04:33,666 --> 00:04:35,133
typescript 的 7.1 版本

141
00:04:35,200 --> 00:04:38,066
它会去支持到 API 这样的东西

142
00:04:38,100 --> 00:04:39,033
所以如果你的项目

143
00:04:39,033 --> 00:04:40,900
有重度依赖 typescript API 的

144
00:04:40,966 --> 00:04:43,000
那你可能并不能这么丝滑的升级

145
00:04:43,033 --> 00:04:44,933
你可能要再去看一看其它的方案

146
00:04:45,000 --> 00:04:46,800
或者说稍微再等一等

147
00:04:46,833 --> 00:04:48,166
接下来其实我想聊一个

148
00:04:48,166 --> 00:04:51,133
关于并不 typescript 的东西

149
00:04:51,200 --> 00:04:52,666
因为 typescript 7 这个版本

150
00:04:52,666 --> 00:04:53,866
在我看来它是一个

151
00:04:53,866 --> 00:04:55,966
没有什么好讨论的一个版本

152
00:04:56,000 --> 00:04:58,633
因为它就是很好 很快

153
00:04:58,700 --> 00:04:59,866
功能也很正常

154
00:04:59,900 --> 00:05:01,300
你如果只是 CLI 版本

155
00:05:01,333 --> 00:05:02,800
你就直接无脑升级就好

156
00:05:02,833 --> 00:05:04,933
这个在我看来是没什么有疑虑的地方

157
00:05:05,000 --> 00:05:06,600
因为社区上以及包括一些公司

158
00:05:06,600 --> 00:05:08,033
都已经在用了

159
00:05:08,100 --> 00:05:10,700
那如果说你的项目有重度依赖 API 的

160
00:05:10,733 --> 00:05:11,900
那就再等等呗

161
00:05:11,933 --> 00:05:13,566
等到 7.1 版本去看看

162
00:05:13,600 --> 00:05:14,400
其实在之前 

163
00:05:14,400 --> 00:05:16,000
typescript 7 Preview 的版本

164
00:05:16,000 --> 00:05:17,200
刚发的时候

165
00:05:17,233 --> 00:05:20,333
在外网是引起了相当大的舆论风波的

166
00:05:20,400 --> 00:05:20,866
目前来说

167
00:05:20,933 --> 00:05:23,833
在程序的一种重写的这种ZZ正确

168
00:05:23,900 --> 00:05:26,366
它是拿 rust 来去重写一切

169
00:05:26,400 --> 00:05:29,966
像我们都知道的前段时间比较火的 Bun

170
00:05:30,000 --> 00:05:32,000
当然我们也上一期有聊了

171
00:05:32,033 --> 00:05:34,066
Bun 是拿 rust 来去重写的

172
00:05:34,133 --> 00:05:36,100
那效果看起来也还不错

173
00:05:36,133 --> 00:05:39,100
像更之前的一些 CLI 的系统工具里边

174
00:05:39,100 --> 00:05:43,133
有更多的拿 rust 来去写的项目

175
00:05:43,166 --> 00:05:45,333
比如说我自己比较喜欢用的 cat 

176
00:05:45,366 --> 00:05:48,933
它用 bat 来去替换这样的 rust 工具

177
00:05:48,966 --> 00:05:53,666
但为什么 typescript 拿 go 来去重写呢

178
00:05:53,733 --> 00:05:54,600
有很多采访

179
00:05:54,633 --> 00:05:56,066
有很多各种各样的想法了

180
00:05:56,133 --> 00:05:58,066
但我觉得这里我想自己

181
00:05:58,066 --> 00:06:00,133
来去尝试解读一下这个事情

182
00:06:00,166 --> 00:06:01,933
其实我自己有用 go 

183
00:06:01,966 --> 00:06:04,733
我自己写 go 大约有个七八年的经验

184
00:06:04,733 --> 00:06:06,400
如果有关注我的一些项目

185
00:06:06,466 --> 00:06:06,933
可以发现

186
00:06:06,966 --> 00:06:08,600
除了前端项目

187
00:06:08,666 --> 00:06:10,133
基本上都是拿 go 来去实现的

188
00:06:10,166 --> 00:06:13,233
无论是 CLI 还是 Web Server 

189
00:06:13,300 --> 00:06:15,200
还是说一些 Desktop 的工具

190
00:06:15,266 --> 00:06:17,033
我基本上是拿 go 来去写的

191
00:06:17,066 --> 00:06:17,900
那另一方面

192
00:06:17,933 --> 00:06:19,200
其实我也有试过 rust 

193
00:06:19,266 --> 00:06:21,966
我拿 rust 写过一些简单的 HTTP 工具

194
00:06:22,000 --> 00:06:23,366
一些 CLI 的项目

195
00:06:23,400 --> 00:06:24,500
代码量级应该不算高

196
00:06:24,566 --> 00:06:26,933
我估计大概几万行左右的样子

197
00:06:26,966 --> 00:06:28,433
对 我自己的观点

198
00:06:28,500 --> 00:06:30,733
其实是我个人更偏好于 go 

199
00:06:30,766 --> 00:06:33,966
我和 typescript 它们的想法是一样的

200
00:06:34,000 --> 00:06:36,500
如果是我来去重写 typescript 

201
00:06:36,566 --> 00:06:40,066
我相信我大概也会拿 go 来去重写

202
00:06:40,100 --> 00:06:42,833
其实我认为这是你个人的选择

203
00:06:42,866 --> 00:06:43,500
对我来说

204
00:06:43,566 --> 00:06:43,966
go 语言

205
00:06:44,000 --> 00:06:45,633
它的平衡性是做的非常好的

206
00:06:45,666 --> 00:06:47,866
那首先一点是它的一个性能

207
00:06:47,900 --> 00:06:49,266
go 的性能绝对不差

208
00:06:49,300 --> 00:06:50,900
我要和互联网上

209
00:06:50,900 --> 00:06:53,300
可能没写过代码的程序员来 battle 一下

210
00:06:53,366 --> 00:06:54,833
go 的性能绝对不算差

211
00:06:54,866 --> 00:06:56,466
Go 的性能实际上

212
00:06:56,466 --> 00:07:00,133
它就是机器的那种基本的性能

213
00:07:00,200 --> 00:07:03,066
你如果只是拿像是 sum 1+ 2 2+ 3 

214
00:07:03,066 --> 00:07:05,366
 这种简单的项目来去做对比

215
00:07:05,400 --> 00:07:06,233
我并不能同意

216
00:07:06,266 --> 00:07:07,433
你可以去拿一些项目

217
00:07:07,466 --> 00:07:08,566
一些场景来去看看

218
00:07:08,633 --> 00:07:10,233
Go 的性能绝对是不算差的

219
00:07:10,233 --> 00:07:11,666
毕竟它是一种静态语言

220
00:07:11,833 --> 00:07:14,066
静态语言的性能是不太可能差的

221
00:07:14,133 --> 00:07:15,133
它编译成机器码

222
00:07:15,166 --> 00:07:17,833
它又不需要像是 VM 这种东西

223
00:07:17,833 --> 00:07:19,400
那另一方面还是它的学习曲线

224
00:07:19,400 --> 00:07:22,466
像 go 语言它的设计是非常克制的

225
00:07:22,500 --> 00:07:25,100
 c 的指针我要说确实非常的复杂

226
00:07:25,166 --> 00:07:27,400
有各种的骚操作小技巧在

227
00:07:27,433 --> 00:07:29,466
但是 go 它就克制了非常多

228
00:07:29,533 --> 00:07:32,133
你可以看像泛型这样一个

229
00:07:32,133 --> 00:07:35,566
几乎广为人知的概念

230
00:07:35,600 --> 00:07:36,800
在 go 里边也是经过

231
00:07:36,800 --> 00:07:39,466
非常慎重的考虑它才去做的

232
00:07:39,533 --> 00:07:40,866
在 go 里边我印象非常深的

233
00:07:40,866 --> 00:07:43,733
就是它一个 error 的一个判定

234
00:07:43,733 --> 00:07:45,566
 error 的这样一个处理

235
00:07:45,600 --> 00:07:47,300
因为像我们现在普通的语言

236
00:07:47,300 --> 00:07:49,133
基本上都是拿 try catch 

237
00:07:49,133 --> 00:07:50,400
这样的方式来去做的

238
00:07:50,433 --> 00:07:51,133
它有没有好处呢

239
00:07:51,200 --> 00:07:51,466
有

240
00:07:51,533 --> 00:07:52,833
它很方便

241
00:07:52,900 --> 00:07:54,300
它会一层一层向上抛

242
00:07:54,333 --> 00:07:55,633
但它有没有另外的问题

243
00:07:55,700 --> 00:07:57,700
它最大的问题就是 surprise

244
00:07:57,700 --> 00:07:59,766
有时候你并不知道哪里会抛错

245
00:07:59,800 --> 00:08:01,166
从上层抛出来一个错

246
00:08:01,200 --> 00:08:04,466
它可能下面 200 层的一个才触发

247
00:08:04,466 --> 00:08:06,033
当然如果你的同事

248
00:08:06,033 --> 00:08:07,100
说你的 Coding agent

249
00:08:07,100 --> 00:08:08,866
写代码骚一点的话

250
00:08:08,933 --> 00:08:11,700
它甚至可以让你的系统 crash

251
00:08:11,733 --> 00:08:15,133
但是并不知道真实的 crash 原因是什么

252
00:08:15,166 --> 00:08:17,133
这是一个非常痛苦的点

253
00:08:17,166 --> 00:08:18,600
我相信只要你维护过

254
00:08:18,600 --> 00:08:20,000
一个稍微大一点的系统

255
00:08:20,066 --> 00:08:21,966
你都会理解到 try catch

256
00:08:21,966 --> 00:08:23,900
它并不是一个很好的设计

257
00:08:23,933 --> 00:08:25,900
但是 go 里边它对于

258
00:08:25,900 --> 00:08:27,733
这个的做法非常的坚持

259
00:08:27,766 --> 00:08:29,166
它要求每一个函数

260
00:08:29,166 --> 00:08:31,933
都需要去显示的去返回 error 

261
00:08:31,966 --> 00:08:33,966
这样当你在写代码的时候

262
00:08:34,000 --> 00:08:36,000
你就知道这个地方它可能会有 error 

263
00:08:36,066 --> 00:08:37,166
你要么处理一下

264
00:08:37,200 --> 00:08:39,700
或者说你非常明确的表示说我不处理

265
00:08:39,766 --> 00:08:40,266
那另一点

266
00:08:40,333 --> 00:08:41,700
我认为 go 它对于

267
00:08:41,700 --> 00:08:43,200
这个平衡性做的很好的一点

268
00:08:43,200 --> 00:08:44,733
是在于几乎所有语言

269
00:08:44,733 --> 00:08:46,700
都有的一个三目运算符

270
00:08:46,766 --> 00:08:47,800
go 里面是没有的

271
00:08:47,833 --> 00:08:49,400
你去学 go 的语法

272
00:08:49,433 --> 00:08:50,333
你会发现它是没有的

273
00:08:50,400 --> 00:08:51,266
它是一个非常简单

274
00:08:51,333 --> 00:08:53,933
你只能拿 if else 来去做这件事情

275
00:08:53,966 --> 00:08:55,000
我认为这是 go 里边

276
00:08:55,000 --> 00:08:56,800
非常勇敢的一个设计之一

277
00:08:56,833 --> 00:08:59,333
我相信你如果写过一段时间的代码

278
00:08:59,400 --> 00:09:01,133
你就知道 AI 它其实很喜欢

279
00:09:01,133 --> 00:09:02,500
写这种三目运算符

280
00:09:02,566 --> 00:09:04,233
但三目运算符有个非常大的问题

281
00:09:04,233 --> 00:09:06,966
就在于它的可读性非常差

282
00:09:07,000 --> 00:09:09,066
它每多一层的三目运算符

283
00:09:09,133 --> 00:09:12,433
它的可读性就急速下降

284
00:09:12,500 --> 00:09:14,766
我可以很确定的说

285
00:09:14,800 --> 00:09:16,200
地球上没有人能够理解

286
00:09:16,200 --> 00:09:18,433
四层的三目运算符

287
00:09:18,500 --> 00:09:19,566
因为这个三目运算符

288
00:09:19,600 --> 00:09:20,766
它一个 if else 

289
00:09:20,800 --> 00:09:21,966
它如果能叠 4 层

290
00:09:22,000 --> 00:09:23,033
它的这个可能性

291
00:09:23,033 --> 00:09:25,800
就已经变得 2 的 4 次方 是吧

292
00:09:25,833 --> 00:09:27,666
它就已经变成 16 种可能性了

293
00:09:27,733 --> 00:09:30,166
你在短短的这么几行代码里面

294
00:09:30,200 --> 00:09:31,500
你有 16 种可能性

295
00:09:31,566 --> 00:09:33,033
我不知道这个人脑的构造

296
00:09:33,033 --> 00:09:34,700
要到何等的层次

297
00:09:34,700 --> 00:09:38,333
才可以说轻易的理解这个事情

298
00:09:38,366 --> 00:09:39,400
在我看来三目运算符

299
00:09:39,400 --> 00:09:40,833
它就是一个很大的糟粕

300
00:09:40,900 --> 00:09:44,100
go 里边它就明确的说它们不支持

301
00:09:44,100 --> 00:09:46,266
像是泛型的话

302
00:09:46,266 --> 00:09:48,433
我当然是蛮喜欢泛型这个设计

303
00:09:48,466 --> 00:09:49,333
因为泛型它可以

304
00:09:49,333 --> 00:09:52,133
有一定高程度的一个抽象

305
00:09:52,200 --> 00:09:54,200
但我相信大家如果写过泛型

306
00:09:54,233 --> 00:09:56,033
你也会同意一件事情

307
00:09:56,066 --> 00:09:56,566
就是泛型

308
00:09:56,633 --> 00:09:58,600
它把很多问题变得很复杂

309
00:09:58,633 --> 00:09:59,400
当然写的好的人

310
00:09:59,400 --> 00:10:01,066
是可以拿泛型写出来花的

311
00:10:01,100 --> 00:10:03,533
写出来一个短短的几行代码

312
00:10:03,600 --> 00:10:06,666
写出来一些非常高深的一些操作

313
00:10:06,700 --> 00:10:08,100
一些技巧

314
00:10:08,133 --> 00:10:09,100
但我也要说

315
00:10:09,133 --> 00:10:11,333
大多数人并不是那种神仙

316
00:10:11,400 --> 00:10:12,733
大多数人是不会做那种 

317
00:10:12,733 --> 00:10:14,966
TS 的这种类型体操的

318
00:10:15,000 --> 00:10:16,433
同样我其实也不认为

319
00:10:16,433 --> 00:10:19,666
我们应该学习这种类型体操

320
00:10:19,700 --> 00:10:21,666
因为它不是一个正常人的思维

321
00:10:21,700 --> 00:10:22,400
同样我也不认为

322
00:10:22,400 --> 00:10:25,533
它是一个 AI 应该理解的东西

323
00:10:25,600 --> 00:10:27,633
一段逻辑它就应该简简单单

324
00:10:27,666 --> 00:10:29,566
可读性第一的前提下

325
00:10:29,633 --> 00:10:32,066
我们才可以谈其它的东西

326
00:10:32,100 --> 00:10:34,200
那我们回到另一个问题

327
00:10:34,266 --> 00:10:35,533
就是 rust 

328
00:10:35,600 --> 00:10:36,866
rust 它的性能好不好呢

329
00:10:36,900 --> 00:10:37,700
它非常的好

330
00:10:37,733 --> 00:10:40,200
它甚至能够自己控制 GC 

331
00:10:40,266 --> 00:10:43,333
因为 GC 它不可避免的是会影响性能的

332
00:10:43,400 --> 00:10:44,633
而且它也有一定的

333
00:10:44,633 --> 00:10:46,666
不可预测的性质在那里

334
00:10:46,666 --> 00:10:48,800
 rust 它就可以让你控制 GC 

335
00:10:48,833 --> 00:10:50,000
那这样你就可以去

336
00:10:50,000 --> 00:10:52,300
写一些极端的高性能的场景

337
00:10:52,333 --> 00:10:54,733
一些计算可以不用被 GC 打断

338
00:10:54,800 --> 00:10:56,666
它的好处就是极端的性能

339
00:10:56,700 --> 00:10:57,400
同样的话

340
00:10:57,466 --> 00:10:58,500
它的坏处就是

341
00:10:58,500 --> 00:11:00,533
就是你需要自己去手动控制

342
00:11:00,533 --> 00:11:01,733
rust 这个语言

343
00:11:01,733 --> 00:11:03,366
我用下来的给我的感觉就是

344
00:11:03,366 --> 00:11:05,733
我每次都要重新学习一下这个语言

345
00:11:05,800 --> 00:11:08,600
它的语言体系太复杂了

346
00:11:08,633 --> 00:11:11,033
如果说你到现在你很喜欢 rust 

347
00:11:11,066 --> 00:11:12,400
我其实建议你去搜索一下 

348
00:11:12,400 --> 00:11:15,833
 pin unpin unbox  unwrapper 这些概念

349
00:11:15,866 --> 00:11:17,700
我觉得对我来说是比较复杂的

350
00:11:17,733 --> 00:11:19,566
但是它最复杂还是一个生命周期

351
00:11:19,633 --> 00:11:20,800
因为像我前文说的

352
00:11:20,800 --> 00:11:22,466
你可以自己去控制 GC 的时候

353
00:11:22,500 --> 00:11:24,066
当然它的这个 GC 控制

354
00:11:24,066 --> 00:11:25,866
也并不像我们 c 或者 c ++

355
00:11:25,866 --> 00:11:28,933
你自己去写 malloc 或者 free 这样方法

356
00:11:29,000 --> 00:11:31,200
而是它是通过生命周期的方法

357
00:11:31,200 --> 00:11:32,966
来去做的这样一个事

358
00:11:33,000 --> 00:11:35,600
我只能说它有点太难了

359
00:11:35,666 --> 00:11:37,333
那如果说你到今天你还认为

360
00:11:37,333 --> 00:11:39,500
rust 它是一门很好的语言

361
00:11:39,533 --> 00:11:40,866
你会更倾向于

362
00:11:40,866 --> 00:11:43,033
拿 rust 来去重写 typescript 

363
00:11:43,100 --> 00:11:43,933
有没有这种可能呢

364
00:11:44,000 --> 00:11:45,233
我认为是有的

365
00:11:45,266 --> 00:11:46,700
因为毕竟 typescript 其实

366
00:11:46,700 --> 00:11:48,866
其实和 bun 是比较像的

367
00:11:48,900 --> 00:11:50,866
因为它有（相对）非常充足的测试用例

368
00:11:50,900 --> 00:11:53,333
它也有非常大的使用量

369
00:11:53,400 --> 00:11:55,433
所以我认为如果拿 AI 来去

370
00:11:55,466 --> 00:11:57,700
拿 rust 来去重写 typescript 

371
00:11:57,733 --> 00:11:59,766
应该是一个非常有可能的项目

372
00:11:59,833 --> 00:12:01,866
而且它很有可能在短短

373
00:12:01,866 --> 00:12:05,533
认为两周之内就做完这件事情

374
00:12:05,600 --> 00:12:08,633
但我想到的可能是关于可读性

375
00:12:08,666 --> 00:12:10,033
关于可拓展性

376
00:12:10,066 --> 00:12:11,833
关于将来的维护

377
00:12:11,833 --> 00:12:13,366
那我认为 go 的它可能是一门

378
00:12:13,400 --> 00:12:17,233
更加适合人类去维护的一个语言

379
00:12:17,266 --> 00:12:18,333
Rust 是吗

380
00:12:18,400 --> 00:12:19,900
它当然也是

381
00:12:19,966 --> 00:12:23,566
但是我认为它对于这种平衡的把握

382
00:12:23,600 --> 00:12:25,800
也许它更加偏向于性能一点

383
00:12:25,833 --> 00:12:27,266
如果到这里

384
00:12:27,266 --> 00:12:28,366
你还是十分不同意我的说法

385
00:12:28,400 --> 00:12:31,066
我当然欢迎你在评论区来谈谈你的看法

386
00:12:31,133 --> 00:12:32,766
但我更建议的做法就是

387
00:12:32,800 --> 00:12:34,200
我们可以尝试拿 rust 来去

388
00:12:34,200 --> 00:12:36,700
写一个大概 1万量级的一个项目

389
00:12:36,766 --> 00:12:39,666
我相信当很多人真的去拿 rust 

390
00:12:39,666 --> 00:12:41,833
 来去写过 1万行以上代码

391
00:12:41,833 --> 00:12:44,566
来去尝试 rust 的拥趸

392
00:12:44,600 --> 00:12:47,300
应该就会冷静一些

393
00:12:47,366 --> 00:12:48,233
当然你写完之后

394
00:12:48,300 --> 00:12:50,500
也欢迎在评论区来去聊一聊你的看法

395
00:12:50,533 --> 00:12:51,933
聊一聊对于 rust 这个语言

396
00:12:51,966 --> 00:12:54,266
是不是该去重写万物

397
00:12:54,333 --> 00:12:56,666
是不是说 typescript 的团队的决策

398
00:12:56,666 --> 00:12:58,166
是一个错误的行为

399
00:12:58,200 --> 00:12:58,433
OK 

400
00:12:58,500 --> 00:12:59,800
那我们今天的节目就到这里

401
00:12:59,800 --> 00:13:00,966
我们下期节目再见

402
00:13:00,966 --> 00:13:01,466
拜拜