V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  lesismal  ›  全部回复第 1 页 / 共 66 页
回复总数  1308
1  2  3  4  5  6  7  8  9  10 ... 66  
13 小时 31 分钟前
回复了 yuanyao 创建的主题 Go 编程语言 最基础的 go 并发编程题,难倒了 90%的候选人
> 2. 有的 channel 不知道由生产者关闭,直接在主程序生产者还未发送结束就关闭结果 panic ;

这种面试题用一个 chan 可以,但但就这个面试题的功能的话似乎就没必要俩协程了,不需要用俩协程也就不需要用 chan 了。
所以这种题如果出给我、只是纸面作答、我是不知道怎么答只能空着,因为需求不合理。

很多基础场景生产者不是唯一的,可能会是并发多协程会生产,所以通常是应该把用于发送的和用于关闭的分开两个 chan 、用于 close 的 chan 再配个 atomic compareandswap ,避免用单个 chan 、某个地方关闭后、其他协程还在给 chan 发数据直接就 panic 了,一些粗暴的实现直接 recover 这种 panic 虽然也问题不大但毕竟它不是个好的处理方式、比如还得纠结 panic recover 是否再给调用者一个 ErrClosed 返回,还是两个 chan 好些。

另外,如果不需要清理 chan 内遗留的数,chan 本身用完之后是不需要 close 的。
1 天前
回复了 B1ankCat 创建的主题 Linux 关于最近 R4L DMA 事件的 Linus 回应
@duty 谬赞了,谢谢🙏

@TanKuku Carbon 这个我不了解
2 天前
回复了 B1ankCat 创建的主题 Linux 关于最近 R4L DMA 事件的 Linus 回应
@iceheart 也可以多看下内存不安全的 bug 漏洞,比如谷歌的:
https://cloud.tencent.com/developer/article/2396076

摘几句:
2022 年标志着内存安全漏洞的 50 周年。自那时以来,内存安全风险变得更加明显。与其他公司一样,谷歌的内部漏洞数据和研究显示,内存安全漏洞广泛存在,并且是内存不安全代码库中漏洞的主要原因之一。这些漏洞危及最终用户、我们的行业和更广泛的社会。我们很高兴看到政府也对这个问题予以重视,比如美国国家网络主任办公室上周[3]发表了一篇关于这个主题的论文。
——注意:内存安全漏洞广泛存在,并且是内存不安全代码库中漏洞的主要原因之一。

谷歌看不到 C++ 进化为一种具有严格内存安全保证(包括时间安全)的语言的现实路径。
——注意:谷歌认为 C++在内存安全这方面现在不行、而且未来也不行,而且不只是谷歌认为 C++不行,就没听说哪家认为 C++现在或者未来能行的。C 在这点上并不比 C++强,甚至更弱。

将所有现有的 C++ 代码大规模重写为一种不同的、内存安全的语言似乎非常困难,而且很可能仍然不切实际。
谷歌认为对于新代码和特别是风险组件,补充过渡到内存安全语言是重要的。
——注意:补充过渡到内存安全语言是重要的。对于内核,C 补充过渡也是一个道理。

报告中也可以看到,谷歌有大规模的 Java 和 Go 安全代码库,而且也在加大 Rust 的投入。

如果意识不到这些,可能是我们的视野局限于自己的小而美的工作范畴、思考的高度达不到那个层次所以看不到。内核不是我的工作领域我了解不多,Rust 也不是我的工作内容我了解也不多,但即使我喜欢 C 和 Go ,也不会那么自信,自信到把自己的技术观点放到与 linus 和谷歌等最顶尖最前沿的巨擘的对立面。
2 天前
回复了 B1ankCat 创建的主题 Linux 关于最近 R4L DMA 事件的 Linus 回应
> 即使一个语言内部实现的内存引用计数,我也不认为这种东西该存在内核里边。

@iceheart 我不觉得引用计数是个问题,搜了下,引用计数在内核好像是挺常见的:
https://gist.github.com/carloscn/3f0179ecfa599969556e86eb80555266

c++的问题可比引用计数恶心得多,智能指针涉及引用计数的部分反倒是相对简单的,更大的容易产生隐含问题的在于容器和各种构造函数的结合,复制构造赋值构造拷贝构造,c++11 之后还有各种复杂的语法语义、左值右值还有 std::move 之类的,一不小心一个 size 比较大的容器触发了个什么复杂的拷贝就可能性能瓶颈或者深浅拷贝的问题,即使老鸟、面对这些复杂语法语义也可能拿不准、需要认真再认真才能确认。

rust 虽然也不简单,但比 c++好很多。

> 所以我的观点是有 c 就够了,保持简洁,不要增加阅读者的心智负担

我也喜欢 c ,但我前面楼也说过,c 越来越后继无人了,而且不安全的问题也没法解决。
至于简洁,c 简洁?小段代码、小项目代码,c 确实可以很简洁,但就内核来说,c 的一层层宏已经让人头疼了,不是难度大,而是记不住,想入门内核,先要硬拼一段时间记忆力才行。而这一点上,可阅读和可维护性上,rust 也是优于 c 的。

前面说的语言复杂性导致的 bug 或者副作用,c++可能造成更多、rust 也不能保证 100%避免,但 c++不只是复杂本身,更重要的是复杂背后可能造成的副作用本身。rust 也有背后的机制、但远未如 c++这般容易带来副作用,不只是背后机制的副作用,而且写代码的人对语言本身的理解就是很大门槛、由于过于复杂的 c++而导致更大概率搞出带有副作用的代码。

而且请你注意,别人引入 rust 的最大侧重点好像是内存安全,rust 在复杂性问题上远远优于 c++、甚至在这种超过临界阈值的大工程里 rust 简洁性也优于 c 、在内存安全上完胜 c 和 c++。

所以复杂性问题,对于 rust 可以忽略,因为复杂性不大而且并没有因为复杂而带来更多副作用、而是用这点复杂去更大程度上解决内存安全等问题,你说的点是不太成立的
2 天前
回复了 B1ankCat 创建的主题 Linux 关于最近 R4L DMA 事件的 Linus 回应
> rust 自动内存管理不是该更令人担忧吗?

@iceheart rust 的和自带 runtime 和 gc 的自动内存管理完全是两码事;如果跟 c++比,rust 更内存安全而且也不像 c++那么复杂没那么多隐藏的黑魔法,现在和以后都应该不会有比 c++更复杂了。

c++老鸟就更不要提了,最该反对的就是那些所谓的 c++老鸟搞出一大坨 c++11 之后的所谓现代 c++代码,老鸟是 happy 了,让后来人怎么玩?语言本身比要做的东西还复杂,整天把心智浪费在语法语义的讨论上,隔三差五一个 issue 讨论这个语法/语义这样用有没有问题?
现代 c++最大的毛病就是十年不出门,出门也是恶心人。

linus 拒绝 c++进内核不能更赞了。
2 天前
回复了 B1ankCat 创建的主题 Linux 关于最近 R4L DMA 事件的 Linus 回应
> 反正等着这群老 B 死就行了,反正内核开发几乎没有新血.

@chenqh 你行你上,你去搞个能直接替代 linux 都可以。如果现在的 Rust 人能直接搞个新的我也是支持,但问题是目前也没哪个 Rust 团队能搞得定这么重要庞大的基础设施、而且最关键的是已有的社区依赖,全世界多少设备在上面跑着呢,不是过家家说换就换了。

前人栽树,后人纳凉,应该懂得感恩,而不是一边纳凉,一边骂娘,这种骂娘并不能显得自己高明,更不能显得自己高尚。
2 天前
回复了 B1ankCat 创建的主题 Linux 关于最近 R4L DMA 事件的 Linus 回应
@iceheart #17 c 和 c++只是部份相近,但几乎完全是两种工程风格,实际工程中并不相近。而且 c++背后的隐含的小动作太多了,即使是老鸟也要谨小慎微,内核这种吹毛求疵的场景、用 c++一不小心就搞出大事、还不如 c 更加安全可控。而 c++相比于 c 的便利几乎不值一提,尤其是,c++并没有解决 rust 能够解决的内存安全问题。
2 天前
回复了 B1ankCat 创建的主题 Linux 关于最近 R4L DMA 事件的 Linus 回应
> linus 虽然前段时间因为封杀俄罗斯的事情,有点败人品。

@TuxcraFt 人在江湖,在那个位置,总会有很多牵扯,没必要用平民事不关己看客的身份去吹毛求疵大佬们的这些无奈之举

> 这一次不管是 Linus 还是 Christoph 表现都令人失望。

@namaketa 所以只要观点正确,随便去社交网络发小作文是好事情、linus 应该大力支持并且也跟着去发作文大力支持?
但凡仇恨、反对、阻挠 Rust ,linus 当初直接就拒绝 rust 了,还用得着给你演这么多?


> R4L 的维护者改用 C 是更妥当的解决方案,看不出一定非要 RUST 的理由

@wwhc 虽然推进 Rust 主要原因是内存安全,但我个人觉得更重要的是,C 越来越后继无人了
3 天前
回复了 Joker123456789 创建的主题 Java 微服务是不是一种错误的方向?
多数人都不懂的一切从实际出发,即使背会了八股、实际工程中还是不擅长运用。
微服务只是一种架构设计和工程实践方案,关键是适不适合用、怎么用、用的对不对。

2015 年左右微服务刚开始要兴起的时候,我在好多技术群里喷那些无脑微服务的人,注意,是喷那些无脑微服务的人而不是喷微服务本身。
早年没有微服务的时候就有分布式,是更广义的概念,微服务被 web 领域的人把分布式更加领域细分并且搞了一大坨以 web 领域为主的基础设施。但其实游戏行业大型游戏系统很早就用分布式,只是游戏技术没有 web http 这些相对统一的协议和技术栈、而多是一家公司一套框架,所以游戏行业的技术相对 web 领域而言像是一盘散沙,也难成固定流派,开源的游戏服务器架构没几个好用的。

整天在那纠结这个概念那个概念,从来没去思考下这个方案与实际工程结合是否合理,你们 95-99%的人都错了。

好的现象是,一些大厂团队和一些老鸟逐渐开始清醒,但也是局限于实践中的那些好坏的点才后知后觉,但如果懂得思考,这些很多坑都是可以提前预见的。
软件工程领域,绝大多数所谓的架构师最大缺点,就是没有像土木建筑数学等领域,去做更详细的建模、图纸设计之类的,只知道 tmd 跟风只知道画点漂亮的所谓架构图甚至 ppt 忽悠老板,但凡知道思考实际的事情、这些大多问题、不是指所有问题,而是排除掉高精尖难度大的那部分,因为现实工程中绝大部份问题都是普通问题,其实都是可以像幼儿园搭积木一样,提前摆弄摆弄就清晰了。

只背八股,不思考工程实践,写再多文章都是误人误己。
四项基本原则:
1. 自己不要抽烟
2. 自己不要买烟
3. 自己不要送烟
4. 自己不要发烟

抽烟的都是敌人,十六字诀:
1. 敌抽我躲:敌人抽烟离我近,我躲开避难
2. 敌送我拒:敌人送烟做礼品,我拒绝收受
3. 敌发我声:敌人发烟一块抽,我声明不喜
4. 敌病我劝:敌人呼吸道生病,我劝他戒烟
5 天前
回复了 onlyApple 创建的主题 iPhone 16e 是什么电子辣鸡?
库克库存大师不是白叫的,你以为是电子垃圾,但其实是心理学,大家骂 16E 就对了,这样就会有更多人忍不住去给 16 去库存了。
厨子心里美滋滋
7 天前
回复了 thisisgpy 创建的主题 程序员 golang 老鸟快快显圣
@yiqiao go 的代码没像 java 那么臃肿,这种审美问题,符合团队的标准和自己的喜好不影响效率就行。如果已经在用并且习惯了,不改也没问题,实用主义
7 天前
回复了 thisisgpy 创建的主题 程序员 golang 老鸟快快显圣
> 是的是的 孩子 你是对的

@laikick 其实如果自己不会好好说中文的话,可以完全去混非中文圈,看到过别人喷你、这不是糟蹋自己嘛,何必呢
7 天前
回复了 thisisgpy 创建的主题 程序员 golang 老鸟快快显圣
@laikick golang-standards/project-layout 这个根本不算是好的结构:

而且这个 repo 作者可以算是 go 社区里最不要脸的了,我都不敢用“最不要脸的之一”来描述他、怕“之一”不准确:
https://github.com/golang-standards/project-layout/issues/117

请做个好人,不要再向别人推荐这个带来更多误导。
7 天前
回复了 cj323 创建的主题 Go 编程语言 Go 为什么有这么多 Websocket 库...
@liaohongxing 看了下提交日志,这个应该就是 gorilla 那个 fork 过来之后改了改的。不论哪个库,主流都是 http upgrade 到 ws 的,这个过程中的 hijack 后 ws 库就接管了 conn 。fasthttp 这个基于 gorilla 那个、后续改了多少内容我就没关注了,应该都差不多。我上面说的很多人使用 gorilla 有问题是指自己封装的部分的问题比如僵尸连接、协程泄漏,不是说 gorilla 本身有问题、它的定位是实现协议并提供基础接口。
8 天前
回复了 cj323 创建的主题 Go 编程语言 Go 为什么有这么多 Websocket 库...
@voidmnwzp 是的、当初好像是 archive 了一段时间,然后 fasthttp 和字节家都 fork 了分支,但后来 gorilla 又活了
8 天前
回复了 cj323 创建的主题 Go 编程语言 Go 为什么有这么多 Websocket 库...
BTW ,gorilla 被用的最广,但涉及到广播的,仍然需要自己封装,要注意避免循环中的阻塞,这通常需要自己封装额外的写协程,就是这个地方,我见过很多人实现的有问题,比如实现的不好导致僵尸连接
8 天前
回复了 cj323 创建的主题 Go 编程语言 Go 为什么有这么多 Websocket 库...
按照协议分层来讲,其他是实现 websocket 协议,melody 是基于 gorilla 之上的对 websocket 的封装,使用上方便些。

按照为了解决的问题分类,gobwas/ws 和 nbio 是为了海量连接数的场景,为了解决标准库方案在高承载量场景下的内存 OOM 和 GC STW 问题、节约更多硬件成本、让服务更稳定。
但 gobwas/ws 本身的设计和实现是存在缺陷的,因为它的 IO 接口仍然是阻塞的,所以 IO 循环中如果有 1 个或多个慢连接就会导致其他连接也跟着排队,个别欧洲团队用它做内网还凑合、因为内网爆这种问题少,但公网没那么稳定,所以非常不适合用于公网商业项目、属于冒险行为。nbio 没这个问题。

coder/websocket 号称很多优化很快,但实测、跟其他基于标准库连接的方案相比,算是性能最拉垮的了

相关内容和测试:
https://www.v2ex.com/t/945827
https://github.com/lesismal/go-websocket-benchmark
两人都是大神, 各有对错, linus 的立场是非常正确的, 项目中有这种路线冲突之类的问题很正常, 应该沟通寻求各方都能接受的方案.
项目内的事情没必要发作文, 他们两个争论什么其实不是重点, 写作文才是导致问题爆发的点, 写作文才是真的搞政治的魔怔行为, 完全意识不到自己的问题而且随便去发作文说明他本身就心智不咋地.
强烈支持 linus !

对于 rust, 至少我见到的有足够基础的人都是赞美, 几乎没有人贬损 rust, 最多就是觉得它难度大不好学.
反 go 的那帮人的言论, 才是真的魔怔.
12 天前
回复了 codists 创建的主题 Python Python 3.14 采用新型解释器,速度提高-3%~30%
300%也还是慢...
1  2  3  4  5  6  7  8  9  10 ... 66  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1344 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 26ms · UTC 23:50 · PVG 07:50 · LAX 15:50 · JFK 18:50
Developed with CodeLauncher
♥ Do have faith in what you're doing.