s*****w
发帖数: 1527 | 1 Typescript 主打OOP, 这难道不是跟functional programming对着干吗？ |
s*****w
发帖数: 1527 | 2 https://medium.com/javascript-scene/you-might-not-need-typescript-or-static-
types-aa7cb670a77b
TypeScript won't reduce the number of bugs.
TypeScript does suffer from added complexity for generics. Take a look at
this generic identity function in standard JavaScript:
const identity = arg => arg;
Compare that to the much noisier statically typed function in TypeScript:
function identity(arg: T): T {
return arg;
} |
z****e
发帖数: 54598 | 3 coroutine之后，所有的语言都在跟fp对着干
高阶函数太难用了，map，flatmap，reduce之类的没几个能搞懂的
immutable能搞懂就谢天谢地了
最简单的future和promise那种写法已经有很多人搞不定了
就是用java一样看挂掉很多人
最后还是coroutine，async，await这种同步的，oop的写法会prevail
其实能把io的同步转异步解决，这事就解决了99%
榨取机器性能的目的就已经达到了
fp没戏，当初记得谁说过
fp这一波，也就是知道一下
什么是lambda，什么是1st class citizen，什么是immutable
就行了，剩下的monad，currying这些，不用纠结
果不其然，没有coroutine，为了对付callback hell，木有办法，只能上高阶函数
有了coroutine，那就不需要了，原来同步怎么写就怎么写
可以开开心心用循环而不是诡异的递归了
否则每次loop都要写成递归，好诡异啊
一大堆人问，callback里面怎么return啊？
其实脚本这种东西举了个fp的大旗往前冲本身就是很诡异的一件事
写个脚本天天嘴里忽悠着各种酷炫的名词让人觉得有种沐猴为冠的感觉
脚本本身就应该是一个简化的，易于使用的，最好是外行都能写的一种编程语言
如果这种语言本身还引发了一大堆专业人士都不太容易搞懂的专业名词
那岂不是跟最初的目的相悖？ |
s*****w
发帖数: 1527 | 4 我擦，老赵你回来啦，让我想想怎么反驳
【在 z****e 的大作中提到】
: coroutine之后，所有的语言都在跟fp对着干
: 高阶函数太难用了，map，flatmap，reduce之类的没几个能搞懂的
: immutable能搞懂就谢天谢地了
: 最简单的future和promise那种写法已经有很多人搞不定了
: 就是用java一样看挂掉很多人
: 最后还是coroutine，async，await这种同步的，oop的写法会prevail
: 其实能把io的同步转异步解决，这事就解决了99%
: 榨取机器性能的目的就已经达到了
: fp没戏，当初记得谁说过
: fp这一波，也就是知道一下
|
m******r
发帖数: 1033 | 5 老赵写作水平明显提高一档次啊。
最后一段我还是很赞同的。 |
z****e
发帖数: 54598 | 6
给你看一下对比
当前暂没有coroutine的java的高阶函数的写法
Future.>future(f ->
vertx.eventBus().send("address1", "message", f)
).compose((msg) ->
Future.>future(f ->
vertx.eventBus().send("address2", msg.body(), f)
)
).compose((msg) ->
Future.>future(f ->
vertx.eventBus().send("address3", msg.body(), f)
)
).setHandler((res) -> {
if (res.failed()) {
//deal with exception
return;
}
//deal with the result
});
嗯，不是太好看懂，这里有几个语法糖和简写，当前没有coroutine，就暂时只能这样
除非用javaagent
kotlin的coroutine的写法：
val vertxContextDispatcher = VertxContextDispatcher(context, Thread.
currentThread())
launch(vertxContextDispatcher){
val result3 = vertx.eventBus().send(Worker::class.java.name, "
message")
println(result3)
val result4 = vertx.eventBus().send(Worker::class.java.name, "
message")
println(result4)
println(Thread.currentThread())
val result5 = vertx.createHttpClient().getNow(443, "www.bing.com", "/
search?q=vert.x")
println(result5.toString())
}
方法的改造，异步回调api改造成suspend方法
suspend open fun EventBus.send(address: String, message: Any): T =
suspendCoroutine { cont ->
vertx.eventBus().send(address, message) { ar: AsyncResult<
Message> ->
if (ar.succeeded()) cont.resume(ar.result().body())
else cont.resumeWithException(ar.cause())
}
}
可以看出来，coroutine的写法无论是代码的简洁，工整程度还是可读性上说，都要强
于fp的高阶函数的使用
性能会略有所下降，3%-5%，但是处于可以接受的范围之内
【在 s*****w 的大作中提到】
: 我擦，老赵你回来啦，让我想想怎么反驳
|
n***p
发帖数: 110 | 7 you don't need oop to do coroutine.
http://github.com/nodename/async-plgd/blob/master/src/hoare/coroutines.clj
【在 z****e 的大作中提到】
: coroutine之后，所有的语言都在跟fp对着干
: 高阶函数太难用了，map，flatmap，reduce之类的没几个能搞懂的
: immutable能搞懂就谢天谢地了
: 最简单的future和promise那种写法已经有很多人搞不定了
: 就是用java一样看挂掉很多人
: 最后还是coroutine，async，await这种同步的，oop的写法会prevail
: 其实能把io的同步转异步解决，这事就解决了99%
: 榨取机器性能的目的就已经达到了
: fp没戏，当初记得谁说过
: fp这一波，也就是知道一下
|
N********n
发帖数: 8363 | 8
5年前我就说C# async/await是王道，比linq还重要。什么future，immutable
之类都是花拳绣腿。现在的新语言设计纷纷开始抄袭async/await了，程序可读
性甩CALLBACK那种几条街。
【在 z****e 的大作中提到】
:
: 给你看一下对比
: 当前暂没有coroutine的java的高阶函数的写法
: Future.>future(f ->
: vertx.eventBus().send("address1", "message", f)
: ).compose((msg) ->
: Future.>future(f ->
: vertx.eventBus().send("address2", msg.body(), f)
: )
: ).compose((msg) ->
|
g****t
发帖数: 31659 | 9 你的基础知识不够否定FP
所以还是不要做原理性讨论
简单说，范畴论不是必须的
lisp发明的时候范畴论还没流行
这和后来的很多FP吸收的东西不是一波的
不如就是一句话，
什么流行用什么
: coroutine之后，所有的语言都在跟fp对着干
: 高阶函数太难用了，map，flatmap，reduce之类的没几个能搞懂的
: immutable能搞懂就谢天谢地了
: 最简单的future和promise那种写法已经有很多人搞不定了
: 就是用java一样看挂掉很多人
: 最后还是coroutine，async，await这种同步的，oop的写法会prevail
: 其实能把io的同步转异步解决，这事就解决了99%
: 榨取机器性能的目的就已经达到了
: fp没戏，当初记得谁说过
: fp这一波，也就是知道一下
【在 z****e 的大作中提到】
:
: 给你看一下对比
: 当前暂没有coroutine的java的高阶函数的写法
: Future.>future(f ->
: vertx.eventBus().send("address1", "message", f)
: ).compose((msg) ->
: Future.>future(f ->
: vertx.eventBus().send("address2", msg.body(), f)
: )
: ).compose((msg) ->
|
g****t
发帖数: 31659 | 10 java 的coroutine多半是没戏的
你找个用c,c 写过硬件相关code的问问就明白了
或者放5年看看
Java应该早点搞定多维数组
本身是往上走的好语言往下走管毛用
: coroutine之后，所有的语言都在跟fp对着干
: 高阶函数太难用了，map，flatmap，reduce之类的没几个能搞懂的
: immutable能搞懂就谢天谢地了
: 最简单的future和promise那种写法已经有很多人搞不定了
: 就是用java一样看挂掉很多人
: 最后还是coroutine，async，await这种同步的，oop的写法会prevail
: 其实能把io的同步转异步解决，这事就解决了99%
: 榨取机器性能的目的就已经达到了
: fp没戏，当初记得谁说过
: fp这一波，也就是知道一下
【在 z****e 的大作中提到】
:
: 给你看一下对比
: 当前暂没有coroutine的java的高阶函数的写法
: Future.>future(f ->
: vertx.eventBus().send("address1", "message", f)
: ).compose((msg) ->
: Future.>future(f ->
: vertx.eventBus().send("address2", msg.body(), f)
: )
: ).compose((msg) ->
|
|
|
g****t
发帖数: 31659 | 11 FP份额在过去几年肯定是增加的
当然，也可能过几年就回来了
: 5年前我就说C# async/await是王道，比linq还重要。什么future，immutable
: 之类都是花拳绣腿。现在的新语言设计纷纷开始抄袭async/await了，程序可读
: 性甩CALLBACK那种几条街。
【在 N********n 的大作中提到】
:
: 5年前我就说C# async/await是王道，比linq还重要。什么future，immutable
: 之类都是花拳绣腿。现在的新语言设计纷纷开始抄袭async/await了，程序可读
: 性甩CALLBACK那种几条街。
|
g****t
发帖数: 31659 | |
z****e
发帖数: 54598 | 13
java 9出来了
clojure升级了么？
没发现用不了么？
clojure还在用sun的那些不安全的包
jigsaw影响比较大的jvm语言就是clojure，其他都还好
kotlin已经升级到9了，最快的一个，不算java和js(nashorn)的话
这两个是oracle官方支持的，这不能算
其他的估计clojure会成为最慢的一个，就看jython是不是会更慢
用一个东西呢，是有前提的
以前用高阶函数，是没有办法
现在有了coroutine，选择多了一个
就不需要高阶函数来帮忙解决callback问题了
那自然就挑容易的搞了
应该这么说，coroutine提供了高阶函数以外的一种选择
让我们可以不需要用高阶函数了
偶尔用一用，比如
button.action = lambda{|now|
canvas.clear()
canvas.image(image, 0, 0)
}
这种可以接受，但是大量出现高阶函数
那个写起来，呵呵
【在 n***p 的大作中提到】
: you don't need oop to do coroutine.
: http://github.com/nodename/async-plgd/blob/master/src/hoare/coroutines.clj
|
z****e
发帖数: 54598 | 14
有没有戏看现在一大堆语言都在干嘛不就知道了
eclipse的ceylon都闹着要加上去
用c和用硬件的关其他人什么事？
我们用一个feature是用来解决问题的
不是用来装逼卖弄的
偶尔写一两个lambda，能够接受
但是要求全部人都开始flatmap，monad，那我只能祝你好运
这个feature能够解决io时候blocking的问题
这是最基本的出发点
能解决这个问题，在保证性能的同时又能保证代码的可读性
就可以了
java的coroutine肯定会做出来，事实上已经有了
只不过不想用javaagent，现在做到语言层面去
不是你想要的那种coroutine
一天到晚搞些虚的没用的东西无聊不？
【在 g****t 的大作中提到】
: java 的coroutine多半是没戏的
: 你找个用c,c 写过硬件相关code的问问就明白了
: 或者放5年看看
: Java应该早点搞定多维数组
: 本身是往上走的好语言往下走管毛用
:
:
: coroutine之后，所有的语言都在跟fp对着干
:
: 高阶函数太难用了，map，flatmap，reduce之类的没几个能搞懂的
:
: immutable能搞懂就谢天谢地了
:
: 最简单的future和promise那种写法已经有很多人搞不定了
|
g****t
发帖数: 31659 | 15 你写过yield,内存快照，状态机之类的东西吗？
我的话你等着放5年看好了。我的看法很简单，java coroutine做出来也没用，不会有
多少人用。没什么前途。不值一提。Java还是早点搞定
多维数组是王道。
FP的话，
Lambda calculus和范畴论是两个年代的事情。对实用来说，
我现在看到最要紧的是要不要reference transpancy.
: 有没有戏看现在一大堆语言都在干嘛不就知道了
: eclipse的ceylon都闹着要加上去
: 用c和用硬件的关其他人什么事？
: 我们用一个feature是用来解决问题的
: 不是用来装逼卖弄的
: 偶尔写一两个lambda，能够接受
: 但是要求全部人都开始flatmap，monad，那我只能祝你好运
: 这个feature能够解决io时候blocking的问题
: 这是最基本的出发点
: 能解决这个问题，在保证性能的同时又能保证代码的可读性
【在 z****e 的大作中提到】
:
: 有没有戏看现在一大堆语言都在干嘛不就知道了
: eclipse的ceylon都闹着要加上去
: 用c和用硬件的关其他人什么事？
: 我们用一个feature是用来解决问题的
: 不是用来装逼卖弄的
: 偶尔写一两个lambda，能够接受
: 但是要求全部人都开始flatmap，monad，那我只能祝你好运
: 这个feature能够解决io时候blocking的问题
: 这是最基本的出发点
|
z****e
发帖数: 54598 | 16 你要看什么？
不用等5年
现在已经有了
早就有了
http://vertx.io/docs/vertx-sync/java/
https://github.com/puniverse/quasar
你说java做不出来？现有的东西出不来？
现在一大票语言都开始async／await，coroutine什么都出来了
你想等5年之后？等什么？等这些语言一个个做出来嘛？
现在已经有好几个了，比如kotlin，你是说这个东西不存在？
说了，不是你想的那种coroutine，你被wdong绕进去了
wdong说的那种coroutine不是我们需要的coroutine或者说不是那么复杂的东西
我们只需要其中一小部分，就能满足要求了
用工具的目的是用来解决问题的，不是用来探索真理的
你要探索宇宙的真相，大可以去物理学上咕哝上半天
反正买买提每次讨论物理都很热闹
我们要处理的是怎么榨取机器性能，同时保证可读性不要下降
【在 g****t 的大作中提到】
: 你写过yield,内存快照，状态机之类的东西吗？
: 我的话你等着放5年看好了。我的看法很简单，java coroutine做出来也没用，不会有
: 多少人用。没什么前途。不值一提。Java还是早点搞定
: 多维数组是王道。
: FP的话，
: Lambda calculus和范畴论是两个年代的事情。对实用来说，
: 我现在看到最要紧的是要不要reference transpancy.
:
:
: 有没有戏看现在一大堆语言都在干嘛不就知道了
:
: eclipse的ceylon都闹着要加上去
|
g****t
发帖数: 31659 | 17 Coroutine就是goto lable,有什么做不出来的。
我的看法很简单：java 这种语言做coroutine没什么用，
没什么价值，不值一提。
: 你要看什么？
: 不用等5年
: 现在已经有了
: 早就有了
: http://vertx.io/docs/vertx-sync/java/
: https://github.com/puniverse/quasar
: 你说java做不出来？现有的东西出不来？
: 现在一大票语言都开始async／await，coroutine什么都出来了
: 你想等5年之后？等什么？等这些语言一个个做出来嘛？
: 现在已经有好几个了，比如kotlin，你是说这个东西不存在？
【在 z****e 的大作中提到】
: 你要看什么？
: 不用等5年
: 现在已经有了
: 早就有了
: http://vertx.io/docs/vertx-sync/java/
: https://github.com/puniverse/quasar
: 你说java做不出来？现有的东西出不来？
: 现在一大票语言都开始async／await，coroutine什么都出来了
: 你想等5年之后？等什么？等这些语言一个个做出来嘛？
: 现在已经有好几个了，比如kotlin，你是说这个东西不存在？
|
z****e
发帖数: 54598 | 18 所以你最后树了一个风车自己冲过去了是吧？
看什么呢？我们现在就在用
你不用还不让别人用了？
居然有这种人，强啊
【在 g****t 的大作中提到】
: Coroutine就是goto lable,有什么做不出来的。
: 我的看法很简单：java 这种语言做coroutine没什么用，
: 没什么价值，不值一提。
:
:
: 你要看什么？
:
: 不用等5年
:
: 现在已经有了
:
: 早就有了
:
: http://vertx.io/docs/vertx-sync/java/
:
: https://github.com/puniverse/quasar
|
g****t
发帖数: 31659 | 19 所以我说放五年后看看是不是还有人用。不要急着和我争论，那没有意义。
: 所以你最后树了一个风车自己冲过去了是吧？
: 看什么呢？我们现在就在用
: 你不用还不让别人用了？
: 居然有这种人，强啊
【在 z****e 的大作中提到】
: 所以你最后树了一个风车自己冲过去了是吧？
: 看什么呢？我们现在就在用
: 你不用还不让别人用了？
: 居然有这种人，强啊
|
z****e
发帖数: 54598 | 20
我只是告诉你现在已经一堆人在用了
你是打算告诉我这一堆人5年之后都会改嘛？
笑了，那为什么一堆语言现在都闹着要加呢？
尤其是没有的语言，比如java
这好像不用等5年也能看出问题来
干嘛等5年？你怎么不等5万年？5万亿年更好
5万亿年之后地球都毁灭了，是不是什么都不重要了？
【在 g****t 的大作中提到】
: 所以我说放五年后看看是不是还有人用。不要急着和我争论，那没有意义。
:
:
: 所以你最后树了一个风车自己冲过去了是吧？
:
: 看什么呢？我们现在就在用
:
: 你不用还不让别人用了？
:
: 居然有这种人，强啊
:
|
|
|
g****t
发帖数: 31659 | 21 2005年甚至更早java就有coroutine 了
类似的库不知道出现过多少
那时候也一堆人用了
你觉得有意思自己玩去吧
: 我只是告诉你现在已经一堆人在用了
: 你是打算告诉我这一堆人5年之后都会改嘛？
: 笑了，那为什么一堆语言现在都闹着要加呢？
: 尤其是没有的语言，比如java
: 这好像不用等5年也能看出问题来
: 干嘛等5年？你怎么不等5万年？5万亿年更好
: 5万亿年之后地球都毁灭了，是不是什么都不重要了？
【在 z****e 的大作中提到】
:
: 我只是告诉你现在已经一堆人在用了
: 你是打算告诉我这一堆人5年之后都会改嘛？
: 笑了，那为什么一堆语言现在都闹着要加呢？
: 尤其是没有的语言，比如java
: 这好像不用等5年也能看出问题来
: 干嘛等5年？你怎么不等5万年？5万亿年更好
: 5万亿年之后地球都毁灭了，是不是什么都不重要了？
|
z****e
发帖数: 54598 | 22
所以底层做硬件的不懂啊
java05年的时候没有lambda的api，不存在callback hell的问题
java的lambda是什么时候有的呢？
来来来，回答一下这个最基本的入门级问题
别告诉我05年时候就有了哦
green thread最早60年代就有了
actor model也是80年代就有了
但是java没有lambda，这个时候只能开线程，不管这个线程是不是虚拟的
都会造成lock过多的问题，lock一多，性能就下来了
有了lambad之后，actor model才能真正成形
然后才能把这些lock数量减下来
从而对于coroutine的要求就变成了：像node.js一样，只要能搞定单核，我们就能把性
能提升上去
【在 g****t 的大作中提到】
: 2005年甚至更早java就有coroutine 了
: 类似的库不知道出现过多少
: 那时候也一堆人用了
: 你觉得有意思自己玩去吧
:
:
: 我只是告诉你现在已经一堆人在用了
:
: 你是打算告诉我这一堆人5年之后都会改嘛？
:
: 笑了，那为什么一堆语言现在都闹着要加呢？
:
: 尤其是没有的语言，比如java
:
: 这好像不用等5年也能看出问题来
|
z****e
发帖数: 54598 | 23 刚有个typo，是lambda
不仅仅是异步，具体点应该是带有lambda的异步api |
g****t
发帖数: 31659 | 24 10年总有了吧？我跟你说这些东西都是goto lable
配上一些似是而非的应用trade off上下文
很多都是公司里闲的蛋疼的人开的为了让自己能
瞎忙的假项目
Java强点不是system programming
弄这些不是不可以
但是有啥好high的？
你能high几天
: 所以底层做硬件的不懂啊
: java05年的时候没有异步的api，不存在callback hell的问题
: java的异步是什么时候有的呢？
: 来来来，回答一下这个最基本的入门级问题
: 别告诉我05年时候就有了哦
: green thread最早60年代就有了
: actor model也是80年代就有了
: 但是java没有lambda，这个时候只能开线程，不管这个线程是不是虚拟的
: 都会造成lock过多的问题，lock一多，性能就下来了
: 有了lambad之后，actor model才能真正成形
【在 z****e 的大作中提到】
: 刚有个typo，是lambda
: 不仅仅是异步，具体点应该是带有lambda的异步api
|
z****e
发帖数: 54598 | 25 lambda是java8的东西
java8第一个版本在2014年
实际上在java之前，scala先做出了jvm上的lambda
所以有了akka，先于java的vert.x之前好多年做出来
然后java有了lambda，消化吸收了node.js和akka之后才有了vert.x
有了vert.x我们才能把线程数降下来，减少lock
从而对coroutine的要求就简化成了node.js对于coroutine那种的要求
不需要考虑多核，不需要考虑lock，actor model解决了这个问题
所以这个时候coroutine只要很简单的能够暂停，能够恢复
就够用了，这样就能解决callback带来的恶心的书写问题
而在此之前，因为lock满天飞，所以即便能够暂停，能够恢复
也很难提升性能，但是当前提改变了
要求降低了之后，coroutine的作用就体现出来了
所以这个时候一堆语言才开始搞coroutine
这里有一个lambda和actor model成熟的前提
如果线程数降不下来，lock一大堆，用不用coroutine都一样
反正性能就是上不去，线程数降下来，节省一个线程，内存stack就是1m
1000个就是1g，1万个就是10g，更不要说cpu浪费在线程的调度上的各种资源了
这是前提，艹，回答了这么多，你丫欠我1000个伪b培训费
【在 g****t 的大作中提到】
: 10年总有了吧？我跟你说这些东西都是goto lable
: 配上一些似是而非的应用trade off上下文
: 很多都是公司里闲的蛋疼的人开的为了让自己能
: 瞎忙的假项目
: Java强点不是system programming
: 弄这些不是不可以
: 但是有啥好high的？
: 你能high几天
:
:
: 所以底层做硬件的不懂啊
|
z****e
发帖数: 54598 | 26
你这里中间就少一个actor model
一直就没有一个减少线程，减少lock的过程
如果没有lambda，这个是很难做到的
如果没有减少lock，coroutine是没有太大价值的
java强的地方是不是system programming
我在解释实现，真正用起来的话，就跟普通的同步api一样用
所以用户只需要换一个api，就能实现性能上几十倍的提升
它为什么不用？
它要是这个时候还选择去用高阶函数，那才是闲着蛋疼呢
说了半天，你就是少了一个中间过程，所以就是看不懂
不理解为什么现在突然要把几十年前的东西给做出来
而以前不用
【在 g****t 的大作中提到】
: 10年总有了吧？我跟你说这些东西都是goto lable
: 配上一些似是而非的应用trade off上下文
: 很多都是公司里闲的蛋疼的人开的为了让自己能
: 瞎忙的假项目
: Java强点不是system programming
: 弄这些不是不可以
: 但是有啥好high的？
: 你能high几天
:
:
: 所以底层做硬件的不懂啊
|
g****t
发帖数: 31659 | 27 我看着就是典型的假项目
难道以前那么多java coroutine 乱七八糟库就没卖点和吹点吗？非要等你lambda来了
才可以吹。
本人不claim自己正确
打算看着你能high几天
: 你这里中间就少一个actor model
: 一直就没有一个减少线程，减少lock的过程
: 如果没有lambda，这个是很难做到的
: 如果没有减少lock，coroutine是没有太大价值的
: java强的地方是不是system programming
: 我在解释实现，真正用起来的话，就跟普通的同步api一样用
: 所以用户只需要换一个api，就能实现性能上几十倍的提升
: 它为什么不用？
: 它要是这个时候还选择去用高阶函数，那才是闲着蛋疼呢
: 说了半天，你就是少了一个中间过程，所以就是看不懂
【在 z****e 的大作中提到】
:
: 你这里中间就少一个actor model
: 一直就没有一个减少线程，减少lock的过程
: 如果没有lambda，这个是很难做到的
: 如果没有减少lock，coroutine是没有太大价值的
: java强的地方是不是system programming
: 我在解释实现，真正用起来的话，就跟普通的同步api一样用
: 所以用户只需要换一个api，就能实现性能上几十倍的提升
: 它为什么不用？
: 它要是这个时候还选择去用高阶函数，那才是闲着蛋疼呢
|
n***p
发帖数: 110 | 28 which sun不安全的包 clojure is using?
java 9 has very little impact to clojure. jigsaw may improve clojure start
up time, which most people don't even care now.
For lisp programmers, first class function and lambda are natural, not
forced upon.
http://www.mitbbs.org/article_t/Programming/31504537.html
【在 z****e 的大作中提到】
:
: 你这里中间就少一个actor model
: 一直就没有一个减少线程，减少lock的过程
: 如果没有lambda，这个是很难做到的
: 如果没有减少lock，coroutine是没有太大价值的
: java强的地方是不是system programming
: 我在解释实现，真正用起来的话，就跟普通的同步api一样用
: 所以用户只需要换一个api，就能实现性能上几十倍的提升
: 它为什么不用？
: 它要是这个时候还选择去用高阶函数，那才是闲着蛋疼呢
|
z****e
发帖数: 54598 | 29
所以到现在你连尝试升级一下都还没去做对吧？
到底哪些有问题你试试不就知道了？
【在 n***p 的大作中提到】
: which sun不安全的包 clojure is using?
: java 9 has very little impact to clojure. jigsaw may improve clojure start
: up time, which most people don't even care now.
: For lisp programmers, first class function and lambda are natural, not
: forced upon.
: http://www.mitbbs.org/article_t/Programming/31504537.html
|
z****e
发帖数: 54598 | 30
所以你连lambda如何成就异步，异步如何成就actor model这个逻辑都没搞懂
就非要claim这个不对，那个正确
哈哈，强啊
【在 g****t 的大作中提到】
: 我看着就是典型的假项目
: 难道以前那么多java coroutine 乱七八糟库就没卖点和吹点吗？非要等你lambda来了
: 才可以吹。
: 本人不claim自己正确
: 打算看着你能high几天
:
:
: 你这里中间就少一个actor model
:
: 一直就没有一个减少线程，减少lock的过程
:
: 如果没有lambda，这个是很难做到的
:
: 如果没有减少lock，coroutine是没有太大价值的
|
|
|
g****t
发帖数: 31659 | 31 你需要把自己的中文弄好。我说了不claim自己的看法正确。
你觉得有价值自己去跟啊。
你这几段话也就是产品说明书或者更低的水平，找个
Application engineer都可以吹的更离谱。
想说服做过system programming 的人是不可能的。
: 所以你连lambda如何成就异步，异步如何成就actor model这个逻辑都没
搞懂
: 就非要claim这个不对，那个正确
: 哈哈，强啊
【在 z****e 的大作中提到】
:
: 所以你连lambda如何成就异步，异步如何成就actor model这个逻辑都没搞懂
: 就非要claim这个不对，那个正确
: 哈哈，强啊
|
z****e
发帖数: 54598 | 32
啧啧，所以现在你连自己对不对都不敢claim了？
哇哦，人至贱则无敌啊
【在 g****t 的大作中提到】
: 你需要把自己的中文弄好。我说了不claim自己的看法正确。
: 你觉得有价值自己去跟啊。
: 你这几段话也就是产品说明书或者更低的水平，找个
: Application engineer都可以吹的更离谱。
: 想说服做过system programming 的人是不可能的。
:
:
: 所以你连lambda如何成就异步，异步如何成就actor model这个逻辑都没
: 搞懂
:
: 就非要claim这个不对，那个正确
:
: 哈哈，强啊
|
n***p
发帖数: 110 | 33 So you have nothing backing up your claim?
【在 z****e 的大作中提到】
:
: 啧啧，所以现在你连自己对不对都不敢claim了？
: 哇哦，人至贱则无敌啊
|
z****e
发帖数: 54598 | 34
我试了啊，9出来我就升级了一大堆东西
发现kotlin可以过啊，其他都过不了
包括native compiling这些
你试了吗？你试试不就知道我说的对不对咯？
【在 n***p 的大作中提到】
: So you have nothing backing up your claim?
|
g****t
发帖数: 31659 | 35 你一边玩着去。
我灌水20年，从没过不讲理的时候。
是你能攻击的到的吗。。。
【在 z****e 的大作中提到】
:
: 我试了啊，9出来我就升级了一大堆东西
: 发现kotlin可以过啊，其他都过不了
: 包括native compiling这些
: 你试了吗？你试试不就知道我说的对不对咯？
|
n***p
发帖数: 110 | 36 AOT in Clojure is not native compiling even for Java 8.
So what is broken in Java 9 exactly?
【在 z****e 的大作中提到】
:
: 我试了啊，9出来我就升级了一大堆东西
: 发现kotlin可以过啊，其他都过不了
: 包括native compiling这些
: 你试了吗？你试试不就知道我说的对不对咯？
|
z****e
发帖数: 54598 | 37
这样下去浪费时间，行，你赢了
【在 n***p 的大作中提到】
: AOT in Clojure is not native compiling even for Java 8.
: So what is broken in Java 9 exactly?
|
s***o
发帖数: 2191 | |
a*****e
发帖数: 1700 | 39 FP 对 coroutine 的研究早很多年，而且里面其实也没有什么好说的，一句
话可以总结：cooperative threading 和 event driven 可以等价转换。下面这篇论文
是 99 年的，而且只是 functional pearl，也就是说，其实不够 paper 的级别。
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.39.8039
什么 async/await（或者 fork/join）用 callcc （或者 continuation monad）几句
话就实现了，不需要任何语言层面的支持。
这些年也就是 nodejs 把路带歪了去弄 callback，正统的 FP 语言没一个尿这壶的。
所以不要以为 写个 callback 或者 lambda 就等于写 FP 了。
一个 coroutine 能弄这么 high，也是叹为观止。 |
w***g
发帖数: 5958 | 40 java我不熟。不过C++的用户态线程库基本上没戏。
一般会点汇编语言的花上三五天就能自己搞一个出来。
但几乎所有人见了multi-core都认怂了。据我所知
能在multi-core上调度大量用户态线程的，只有go
一个。这就是贝尔实验室那批人牛B的地方。
非要比，node.js就支持不了multi-core调度。
Multi-core的调度其实一般做过点system的人也都能
吹一下。多年前我去oracle面试时就面的这个multi-
core的问题，不过假设的是被调度的是一致的task，
不是generic threads。一般能力上了这一层的，也就能
理解了这个问题实战有多难，不会轻易去折腾个
轮子玩了。
现在cpu核越来越多，除I/O外CPU计算负载越来越大的情
况下，搞用户态线程就是逆历史潮流而动。
本身用"coroutine"这个词的，就是操统没学好概念分
不清。像楼上这种明白的，会用"cooperative threading"
这个词。过五年回来看，所有java和C++的coroutine库都
将烟消云散。
【在 g****t 的大作中提到】
: 我看着就是典型的假项目
: 难道以前那么多java coroutine 乱七八糟库就没卖点和吹点吗？非要等你lambda来了
: 才可以吹。
: 本人不claim自己正确
: 打算看着你能high几天
:
:
: 你这里中间就少一个actor model
:
: 一直就没有一个减少线程，减少lock的过程
:
: 如果没有lambda，这个是很难做到的
:
: 如果没有减少lock，coroutine是没有太大价值的
|
|
|
s***o
发帖数: 2191 | 41 就是说golang 5年后就没了？这个不可能啊
【在 w***g 的大作中提到】
: java我不熟。不过C++的用户态线程库基本上没戏。
: 一般会点汇编语言的花上三五天就能自己搞一个出来。
: 但几乎所有人见了multi-core都认怂了。据我所知
: 能在multi-core上调度大量用户态线程的，只有go
: 一个。这就是贝尔实验室那批人牛B的地方。
: 非要比，node.js就支持不了multi-core调度。
: Multi-core的调度其实一般做过点system的人也都能
: 吹一下。多年前我去oracle面试时就面的这个multi-
: core的问题，不过假设的是被调度的是一致的task，
: 不是generic threads。一般能力上了这一层的，也就能
|
w***g
发帖数: 5958 | 42 "所有的coroutine库"不包括golang。
特指java和C++的。原帖已改。
我觉得golang不是因为支持用户态线程而牛x，
node.js也不是因为异步I/O牛x。这两个都是因为
填补了别的方面的空缺而牛x的。其中golang主要
因为g推得厉害。不过这个没法验证。
我再做个预测，过几年javascript会出来
thread库来取代异步I/O。到时候人们又会激动得
上窜下跳。
【在 s***o 的大作中提到】
: 就是说golang 5年后就没了？这个不可能啊
|
l**********n
发帖数: 8443 | |
w***g
发帖数: 5958 | 44 这版上几个老哥显然已经过了要刷题跳槽的人生阶段。
【在 l**********n 的大作中提到】
: 有时间在这儿码字，不如多刷题，多写程序。
|
m****o
发帖数: 182 | 45 说句公道话，SAM type出现以前，Scala的lambda其实就是java object，从Function0
到Function22。至于system programming我不熟悉，但是JVM上解决callback hell在不
touch system fundamentals的前提下最好的途径是reactive stream programming。
callback hell被转化成了stream，再依仗fp，这些stream还可以被transform和
compose，大大增强了程序本身能够表达的能力。
actor model我个人认为最大的问题是处境很尴尬。不管是OO programmer还是FP
programmer都不会太喜欢。用不好还会出现死锁。
【在 z****e 的大作中提到】
: lambda是java8的东西
: java8第一个版本在2014年
: 实际上在java之前，scala先做出了jvm上的lambda
: 所以有了akka，先于java的vert.x之前好多年做出来
: 然后java有了lambda，消化吸收了node.js和akka之后才有了vert.x
: 有了vert.x我们才能把线程数降下来，减少lock
: 从而对coroutine的要求就简化成了node.js对于coroutine那种的要求
: 不需要考虑多核，不需要考虑lock，actor model解决了这个问题
: 所以这个时候coroutine只要很简单的能够暂停，能够恢复
: 就够用了，这样就能解决callback带来的恶心的书写问题
|
g****t
发帖数: 31659 | 46 scheduler etc很多知识点都是EE的，学了穷三代.
另外别说java这种了。Go这个项目本身说不定也是Rob Pike弄个假项目玩玩。
毕竟所说的 multi－core优势还没有稳定的展现。现在它家核心的scheduler
还在改个不停。只有专家才能知道有多少坑。
【在 w***g 的大作中提到】
: java我不熟。不过C++的用户态线程库基本上没戏。
: 一般会点汇编语言的花上三五天就能自己搞一个出来。
: 但几乎所有人见了multi-core都认怂了。据我所知
: 能在multi-core上调度大量用户态线程的，只有go
: 一个。这就是贝尔实验室那批人牛B的地方。
: 非要比，node.js就支持不了multi-core调度。
: Multi-core的调度其实一般做过点system的人也都能
: 吹一下。多年前我去oracle面试时就面的这个multi-
: core的问题，不过假设的是被调度的是一致的task，
: 不是generic threads。一般能力上了这一层的，也就能
|
a*****e
发帖数: 1700 | 47 GHC 的 M:N 轻线程调度比 goroutine 早很多年
【在 w***g 的大作中提到】
: java我不熟。不过C++的用户态线程库基本上没戏。
: 一般会点汇编语言的花上三五天就能自己搞一个出来。
: 但几乎所有人见了multi-core都认怂了。据我所知
: 能在multi-core上调度大量用户态线程的，只有go
: 一个。这就是贝尔实验室那批人牛B的地方。
: 非要比，node.js就支持不了multi-core调度。
: Multi-core的调度其实一般做过点system的人也都能
: 吹一下。多年前我去oracle面试时就面的这个multi-
: core的问题，不过假设的是被调度的是一致的task，
: 不是generic threads。一般能力上了这一层的，也就能
|
g****t
发帖数: 31659 | 48 我没看过，但是我猜rust肯定有。小语言，新的容易实现。
【在 a*****e 的大作中提到】
: GHC 的 M:N 轻线程调度比 goroutine 早很多年
|
z****e
发帖数: 54598 | 49
你还是没有看懂人家说的coroutine的目的啊
coroutine是语法糖
主要目的是从高阶函数中解放程序猿
因为高阶函数太多人搞不明白
所以用coroutine或者叫简化的coroutine来解放程序猿
把我的例子认真看一遍
看看coroutine是怎么把程序猿从高阶函数中解放出来的
这个才是目的
说了半天，你们根本就不懂其他人在干嘛
老是用底层那些东西来思考问题
少了一层东西，然后就是死活理解不了
累不累？感觉鸡同鸭讲了
【在 w***g 的大作中提到】
: java我不熟。不过C++的用户态线程库基本上没戏。
: 一般会点汇编语言的花上三五天就能自己搞一个出来。
: 但几乎所有人见了multi-core都认怂了。据我所知
: 能在multi-core上调度大量用户态线程的，只有go
: 一个。这就是贝尔实验室那批人牛B的地方。
: 非要比，node.js就支持不了multi-core调度。
: Multi-core的调度其实一般做过点system的人也都能
: 吹一下。多年前我去oracle面试时就面的这个multi-
: core的问题，不过假设的是被调度的是一致的task，
: 不是generic threads。一般能力上了这一层的，也就能
|
z****e
发帖数: 54598 | 50
Function0
停停停
你没有用过vert.x
所以鸡同鸭讲
我给你一个建议，去看看vert.x的设计
然后再来谈
死锁？
都lock free了，死锁什么哟？
都用这么久，遇到过搞不定高阶函数的
还真没遇到过死锁的
vert.x一直就是reactive programming
正是在实践中遇到了问题
所以我们才会寻找答案
而现在说的coroutine
正是我们找到的答案
之前搞reactive programming
最大的麻烦就是普通程序猿掌握不了高阶函数的使用
map, flatmap，副作用，绕晕了，搞不定我去
后来情愿换成kotlin，coroutine白菜化异步api
然后就ok啦
还是那句话，你们没有经验，看不懂
我当然知道高阶函数，reactive是一种解决方案
但是很麻烦，一般程序猿搞不定
思维上的改造不是那么容易的
这就是为什么一大堆语言都在搞coroutine/async/await的主因
fp那些，主流不感兴趣，因为搞不懂嘛
没有coroutine之前，我们推广reactive，多恶心你知道嘛？
一说副作用，无状态函数，fp下面一大堆人在睡觉，哈欠连天
这些东西只有书呆子喜欢
wdong还在纠结什么主流说的coroutine跟他说的coroutine不是一回事
哎哟我的妈呀，这呆子
【在 m****o 的大作中提到】
: 说句公道话，SAM type出现以前，Scala的lambda其实就是java object，从Function0
: 到Function22。至于system programming我不熟悉，但是JVM上解决callback hell在不
: touch system fundamentals的前提下最好的途径是reactive stream programming。
: callback hell被转化成了stream，再依仗fp，这些stream还可以被transform和
: compose，大大增强了程序本身能够表达的能力。
: actor model我个人认为最大的问题是处境很尴尬。不管是OO programmer还是FP
: programmer都不会太喜欢。用不好还会出现死锁。
|
|
|
i******l
发帖数: 270 | 51 我觉得他想说的是，你在一个核上整，很容易，根本就没有 lock
但是要充分用上多核，这事儿在工程上难度很高。还要搞个自己的
scheduler，work steal，各种走钢丝。目前 golang 搞成了。但
据说它的 channel 性能就不够高。
【在 z****e 的大作中提到】
:
: Function0
: 停停停
: 你没有用过vert.x
: 所以鸡同鸭讲
: 我给你一个建议，去看看vert.x的设计
: 然后再来谈
: 死锁？
: 都lock free了，死锁什么哟？
: 都用这么久，遇到过搞不定高阶函数的
|
s********k
发帖数: 6180 | 52 wdong，如果把golang的程序放到container里面你这个优势就整不出来？还是用user
thread？
【在 w***g 的大作中提到】
: java我不熟。不过C++的用户态线程库基本上没戏。
: 一般会点汇编语言的花上三五天就能自己搞一个出来。
: 但几乎所有人见了multi-core都认怂了。据我所知
: 能在multi-core上调度大量用户态线程的，只有go
: 一个。这就是贝尔实验室那批人牛B的地方。
: 非要比，node.js就支持不了multi-core调度。
: Multi-core的调度其实一般做过点system的人也都能
: 吹一下。多年前我去oracle面试时就面的这个multi-
: core的问题，不过假设的是被调度的是一致的task，
: 不是generic threads。一般能力上了这一层的，也就能
|
w***g
发帖数: 5958 | 53 container跟performance没啥关系, 只不过是在一群os process外加了isolation.
【在 s********k 的大作中提到】
: wdong，如果把golang的程序放到container里面你这个优势就整不出来？还是用user
: thread？
|
z****e
发帖数: 54598 | 54
我们先找一个共识
就是在一个core上做
很容易，因为没有lock
对吧？这个是所有人都认可的
然后在这个基础之上，我们有两条路可以走
一种是直接上coroutine，要求coroutine解决多核环境下调度的问题
这就是go走的这条路，我相信这条路不好走
也需要“牛得不得了的人”才能搞定，很有可能
另外一条路是这样，你先放下这个问题，我们继续往前走
看看有没有其他的路，找啊找
诶，突然发现，有一条路叫做actor model
可以通过eventloop这种方式，把原来一大票线程给降下来
为什么呢？原理很简单，原先io的时候，同步api无论如何
要占用一个线程，给我等着
异步api的好处就是可以马上释放调用线程
这样我们可以复用同一个线程，然后对于我们常见的场景
也就是那些大量crud的业务场景
基本上都是io bound的场景，所以可以通过少量线程就能host住大量的请求
比如原来用tomcat，要几千个线程的线程池
现在只需要20多个就行了，甚至用1core 1g的机器，也就是2个eventloop，记住这个关
键字
以后你会经常遇到，spring都开始eventloop，spring为了搞eventloop，不惜把
servlet一脚踢开
没关注spring等java框架的twitter吗？
扯远，在线程数降下来之后，我们再通过immutable message
把eventloop之间的并发彻底干掉，这样整个系统就lock free啦
这是一个非常大的进步，不仅仅是vert.x，什么akka，node.js都在做同样的事
好，在这个前提下
看清楚，在这个前提下
我们再回头去找coroutine，这个时候事情就简单了
多核调度，lock free，都搞定了
这个时候再找到coroutine，就只有一件事要做了
能做到暂停恢复，就ok啦
而我们既然都认为，在lock free的前提下，这事很容易
那就解决了啊，皆大欢喜
所以这事一定能做成
就不需要什么“牛得不得了的人”来做，一样成
这个时候再回头看go在那边死磕就觉得，好累啊
其实做不到我们一样用，但是为什么需要它呢？
因为这个是一个语法糖
有了这个，我们就不需要再去写恶心的高阶函数啦
这就是别人说的高阶函数白菜化
或者具体一点，异步io api白菜化
可以像写同步一样继续写我们的代码了
异步出现的时候，callback，很恶心啊
还记得dumbcoder转的那个《去你妈的纯函数》吗？
说明大众或者说至少有一部分人对于fp是不认可的，分分钟想去他妈
callback hell怎么办？没有coroutine之前，只能用future/promise啊，或者
reactivex这些
其实都不好用，无非一堆高阶函数，很多人看都看不懂
所以一堆fp的用户出来秀智商了，无非就是，你看我多聪明，我能看懂你个傻缺看不懂诶
但是coroutine出现之后，我们可以让线程（协程）暂停了
那用的时候，无非调用一个suspend，回来之后再resume一下，这事就结束了
这个时候就不再需要用什么高阶函数，我的妈呀，高阶函数用起来太难受了
我只想发一个请求，然后收到请求之后再继续就行了，这事其实就是一个暂停恢复就
over的事
你整一大堆什么高阶函数，什么mapreduce，什么flatmap，人家会觉得这个是神经病
所以虽然这是一个解决方案，但是下面的人听了哈欠连天，听了想睡觉啊
听不懂嘛，有多少人对fp这种东西感兴趣呢？书呆子差不多
书呆子连游戏都不会玩，举个例子，你妹的街霸，当然不否认街霸是一个精品
让我想起一个笑话，说，学什么c，学了一个学期，最后还在解数独，哎
java那边随便一下就开始各种小工具就出来了，虽然很丑，swing写的，但是至少比解
数独有趣啊
对吧？书呆子举例子，都是很boring，tedious的东西
当然我不否认这后面数学道行很高啊，blablabla，但是别人还是会睡过去
因为这个人很无趣啊，生活很单调啊，很多人学编程是为了做星际的，不是为了搞fp的
所以有了这么一个简单的api，那所有人都可以很快速滴解决问题
然后该干嘛干嘛去，这种小事情就不要搞太fancy了，白菜化合情合理
所以go搞没搞成，不重要，重要的是我们有了go以外的另外一条路
而且go做得似乎也不怎样，但是其他语言已经做成了
如果你不信，没有关系，我有一个建议，你自己可以跑一下，看看效果
1）vert.x马上要出3.5，等几天就有，我刚去看了下，在升级java9，应该很快了，3.5
里面会有kotlin的coroutine支持，你用vert.x-kotlin做一个benchmark
2）你用spring mvc做一个benchmark，用它的同步api
3）你用go做一个benchmark
然后对比一下
1）是异步，actor model+coroutine
2）是同步，线程池
3）native coroutine吧，就这么叫吧
你自己看一下哪个效果最好
1&3吊打2没有任何问题，这也是为什么spring现在也着急了，最新搞了webflux，也开
始搞eventloop了
1超过3应该问题也不大，你可以试试，techempower上1还没有，但是你可以找到vert.x
&java的评测结果
基本上盖过3是ok的，但是vert.x+kotlin+coroutine的性能会略比vert.x+java+
callback的方式有所下降
但是差距应该在毫厘之间，3%-5%按照官方的说法
但是vert.x超过go是基本上没啥问题的
所以这就是你说的最后一句话，go在需要“牛得不得了的人”上去死磕，结果并不好
但是我们不需要死磕一样能搞定问题，其实就是一个绕道
就是最简单的，遇到问题解决问题，不要秀智商，这事就天然简单
这就是corotuine带给我们真正的含义
所以缺了这一步，我们就不在一个维度上讨论问题
说的coroutine都不是一个东西，就会鸡同鸭讲
【在 i******l 的大作中提到】
: 我觉得他想说的是，你在一个核上整，很容易，根本就没有 lock
: 但是要充分用上多核，这事儿在工程上难度很高。还要搞个自己的
: scheduler，work steal，各种走钢丝。目前 golang 搞成了。但
: 据说它的 channel 性能就不够高。
|
