FrankHB 最近的时间轴更新
FrankHB

FrankHB

V2EX 第 34994 号会员,加入于 2013-02-28 10:06:28 +08:00
FrankHB 最近回复了
34 天前
回复了 qdwang 创建的主题 程序员 Rust 最神奇的地方
@TypeError 引的文章有一些事实错误。因为误导比较严重所以单独说。
这篇文章和引用的其它一些链接没有分析清楚问题这个的来源,所以还有些(至少本应是)显而易见的错误。
虽然异步编程支持这方面上确实有 specific to Rust 的特别欠揍的地方,但是所谓 function 的 colour,根本上其实来自 async 。
文章认为 async/await 是一种相对于 Scheme 式的 CPS 抽象的进步,然而这是胡扯。Scheme 提供的是 first-class continuation,就是为了允许避免显式的 CPS 而能实现类似 CPS 的效果。
所谓 smear it out into a bunch of closures 在这样的支持 first-class continuation 的情形下就是一种实现细节。
想要异步代码干净,各种不同语言的设计思路都是允许用户写 direct style 的代码,然后让语言的实现自动翻译成 CPS 或者其它形式的显式异步表示形式。
这种变换,即便照顾同步 /异步的混用,逻辑上本来只要求 call site 区分所谓的 await,不需要关心是否 async 。需要区分不同的可调用实体是不是 async 的,反而把实现细节给暴露出来了。
要求用 asnyc 标注异步代码的主要原因是不愿意让运行时承担隐藏实现细节的责任,而改为强加到代码生成的机制上的偷懒,乃至于不惜牺牲接口上的一致抽象(所以有所谓的 colour 问题)。
这和滥用类型系统类似,经常就是一种过度优化(虽然影响的实现远比类型检查更麻烦)。Rust 本来就很有滥用类型系统的嫌疑,这里更容易打架毫不出乎意料。
至于 future/promise,是一种限制性的备胎而非 first-class continuation 或同等抽象能力的基础设施的替代。在语言没有能力提供健全的特性时,实现可以使用非公开的机制提供有限的 API 适用受限的场合。这可能提升特定有限场景下原语的实现质量,但也限制了通用性。
34 天前
回复了 qdwang 创建的主题 程序员 Rust 最神奇的地方
@longkas239 反了吧,没 GC 可以自己往里面实现一个当乐趣,有 GC 还能咋地,难道管 GC 调优当乐子?
流水线作业关心的是吞吐量,你管什么延迟……真 stall 住了就是财务部门失职了,约等于他们欠你的,打报告鞭笞就行了。
C 艹屎山还指望啥查找引用,记明白标识符直接开个 cmd rg 一把梭基本上都比 clangd 靠谱,更别说什么 VS 了……
34 天前
回复了 Jooooooooo 创建的主题 程序员 Google 和 Oracle 的官司终于打完了
@hantsy C# 是 ECMA 有标准,但是标准不是唯一的规范,很久没更新了,实际进度远远落后于作为事实标准的微软规范。
尽管微软出的规范文档质量很有问题(像 ECMA 吐槽过 MS 分不清 destructor 和 finalizer 还硬要尬聊),但新版别的地方就是没有替代,新的实现的开发也是完全由微软主导,不管是否开源都没变化。所以领导权的问题上和 Java 其实类似。
34 天前
回复了 Jooooooooo 创建的主题 程序员 Google 和 Oracle 的官司终于打完了
@szq8014 CPU 指令集主要是专利保护基础上的授权限制引起的问题。
Java 相当于 ISA 的部分是 JVMS 规范的东西,这个没见专利问题。
而且实际情况是基本相反,Oracle 不爽的是偏偏 Google 还不用这套,自己另起炉灶架空了这坨,“偷”走了上层生态。告的也是上面的设施( API )雷同。
34 天前
回复了 Jooooooooo 创建的主题 程序员 Google 和 Oracle 的官司终于打完了
@AoEiuV020 具体实现是有 license 的,不可能有这种旷日持久的争议。
上面那个知乎的回答里概括了,关键问题就是山寨了一组兼容的 API (但不需要连实现一起抄)出来的问题。
事实上恰恰就是因为实际实现不一样,不完全符合原始 Java 规范( JLS 和 JVMS )的兼容性,有分裂 Java 阵营和抢夺话语权的实际影响,而搞得 Oracle 实在坐不住了。
API 的实现在这上面不存在“保护作品完整权”,又没涵盖整个 Java 的专利,所以只能强行向 API 的版权属性下手。不过靠这个独占权利本来逻辑就不通(因为这根本不是复制权,只是使用权,不归版权法管),只能欺负外行。所以就是 Oracle 法务部,这里也是死马当活马医罢了。
35 天前
回复了 Jooooooooo 创建的主题 程序员 Google 和 Oracle 的官司终于打完了
标准结局。
Public API 这种存在意义就是能拿出来给外人 use 的东西要是因为 copyrightable 就能随便加条件事后算账,那就翻天了……
羡慕个啥。
牛逼到一定程度前你会发现总是还有人比你更牛逼,你就不算个什么事儿;
等更加牛逼到不需要在乎这个的时候,就发现问题不是有没有人比你牛逼了,而是又方便自己干完的活早干完了,剩下的活尽是长期找不到足够的资源(比如能跟得上你陪你牛逼一起干活的)没法收场的;
一个人什么都得干,弃坑了又总是发现更多一个人干不完的牛逼玩意儿,反而更苦逼……
@az467 原问题是“说的不清楚……具体是什么原因呢?”光看这里,你回答一个具体实现的表现倒也算是对路。
但后面的疑问很明显是为什么允许这样做。拿实现行为就没解决问题。
关键是什么允许,直接的答案就是 JLS 里的规则。(事实上这段 JSR133 里也有。)
虽然跟你之后说的一样,最好看看整个 JMM,但直接原因是 JLS 就确定的,到这里跟 JVM 还不需要有关系。
(可能这里是该强调一下所谓编译器包括 JVM 的 JIT 而不只是 javac 。不过没看出一开始这里是不是有疑问。)
拿 JSR133 主要是说明背景。具体来说,用到的是 Chapter 13 里的第一段文字描述。
Figure 27 是一个典型的例子,有了 synchronize 都允许不让出 CPU,比这里的条件还强。(另外别忘了 happens before 在线程内就有效,不过这个和这里的问题没直接关系。)
(后面那个 Figure 28 例子是反过来限制优化的,和这里也不直接相关。)
重新回顾重点:不是“优化”(而是为什么允许优化)。实际上考虑这里仍然不需要关心“编译器怎么优化”。说白了,编译器就算不是以优化的目的变换代码,直接编译成这样按规范也没话说。
没讲清楚这条线,讲实现细节只会更混乱。
用 volatile 等避免问题也是之后的延伸话题。
(道理上 happens before 也该弄明白,但尴尬的是这个只用线程内的就能直接踩上调度问题了,又不像 C/C++ 直接有 sequence before,还不如默认知道 program order 不言自明了……)
关于   ·   帮助文档   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3614 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 11ms · UTC 03:33 · PVG 11:33 · LAX 20:33 · JFK 23:33
♥ Do have faith in what you're doing.