z****e
发帖数: 54598 | 1 所以你最后树了一个风车自己冲过去了是吧？
看什么呢？我们现在就在用
你不用还不让别人用了？
居然有这种人，强啊 |
|
g****t
发帖数: 31659 | 2 所以我说放五年后看看是不是还有人用。不要急着和我争论，那没有意义。
: 所以你最后树了一个风车自己冲过去了是吧？
: 看什么呢？我们现在就在用
: 你不用还不让别人用了？
: 居然有这种人，强啊
|
|
z****e
发帖数: 54598 | 3
我只是告诉你现在已经一堆人在用了
你是打算告诉我这一堆人5年之后都会改嘛？
笑了，那为什么一堆语言现在都闹着要加呢？
尤其是没有的语言，比如java
这好像不用等5年也能看出问题来
干嘛等5年？你怎么不等5万年？5万亿年更好
5万亿年之后地球都毁灭了，是不是什么都不重要了？ |
|
g****t
发帖数: 31659 | 4 2005年甚至更早java就有coroutine 了
类似的库不知道出现过多少
那时候也一堆人用了
你觉得有意思自己玩去吧
: 我只是告诉你现在已经一堆人在用了
: 你是打算告诉我这一堆人5年之后都会改嘛？
: 笑了，那为什么一堆语言现在都闹着要加呢？
: 尤其是没有的语言，比如java
: 这好像不用等5年也能看出问题来
: 干嘛等5年？你怎么不等5万年？5万亿年更好
: 5万亿年之后地球都毁灭了，是不是什么都不重要了？
|
|
z****e
发帖数: 54598 | 5
所以底层做硬件的不懂啊
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一样，只要能搞定单核，我们就能把性
能提升上去 |
|
z****e
发帖数: 54598 | 6 刚有个typo，是lambda
不仅仅是异步，具体点应该是带有lambda的异步api |
|
g****t
发帖数: 31659 | 7 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
发帖数: 54598 | 8 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都一样
反正性能就是上不去，线程数降下来，节省一个线程，内存stac... 阅读全帖 |
|
z****e
发帖数: 54598 | 9
你这里中间就少一个actor model
一直就没有一个减少线程，减少lock的过程
如果没有lambda，这个是很难做到的
如果没有减少lock，coroutine是没有太大价值的
java强的地方是不是system programming
我在解释实现，真正用起来的话，就跟普通的同步api一样用
所以用户只需要换一个api，就能实现性能上几十倍的提升
它为什么不用？
它要是这个时候还选择去用高阶函数，那才是闲着蛋疼呢
说了半天，你就是少了一个中间过程，所以就是看不懂
不理解为什么现在突然要把几十年前的东西给做出来
而以前不用 |
|
g****t
发帖数: 31659 | 10 我看着就是典型的假项目
难道以前那么多java coroutine 乱七八糟库就没卖点和吹点吗？非要等你lambda来了
才可以吹。
本人不claim自己正确
打算看着你能high几天
: 你这里中间就少一个actor model
: 一直就没有一个减少线程，减少lock的过程
: 如果没有lambda，这个是很难做到的
: 如果没有减少lock，coroutine是没有太大价值的
: java强的地方是不是system programming
: 我在解释实现，真正用起来的话，就跟普通的同步api一样用
: 所以用户只需要换一个api，就能实现性能上几十倍的提升
: 它为什么不用？
: 它要是这个时候还选择去用高阶函数，那才是闲着蛋疼呢
: 说了半天，你就是少了一个中间过程，所以就是看不懂
|
|
发帖数: 1 | 11 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 | 12
所以到现在你连尝试升级一下都还没去做对吧？
到底哪些有问题你试试不就知道了？ |
|
z****e
发帖数: 54598 | 13
所以你连lambda如何成就异步，异步如何成就actor model这个逻辑都没搞懂
就非要claim这个不对，那个正确
哈哈，强啊 |
|
g****t
发帖数: 31659 | 14 你需要把自己的中文弄好。我说了不claim自己的看法正确。
你觉得有价值自己去跟啊。
你这几段话也就是产品说明书或者更低的水平，找个
Application engineer都可以吹的更离谱。
想说服做过system programming 的人是不可能的。
: 所以你连lambda如何成就异步，异步如何成就actor model这个逻辑都没
搞懂
: 就非要claim这个不对，那个正确
: 哈哈，强啊
|
|
z****e
发帖数: 54598 | 15
啧啧，所以现在你连自己对不对都不敢claim了？
哇哦，人至贱则无敌啊 |
|
发帖数: 1 | 16 So you have nothing backing up your claim? |
|
z****e
发帖数: 54598 | 17
我试了啊，9出来我就升级了一大堆东西
发现kotlin可以过啊，其他都过不了
包括native compiling这些
你试了吗？你试试不就知道我说的对不对咯？ |
|
g****t
发帖数: 31659 | 18 你一边玩着去。
我灌水20年，从没过不讲理的时候。
是你能攻击的到的吗。。。 |
|
发帖数: 1 | 19 AOT in Clojure is not native compiling even for Java 8.
So what is broken in Java 9 exactly? |
|
|
|
a*****e
发帖数: 1700 | 22 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 | 23 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库都
将烟消云散。 |
|
s***o
发帖数: 2191 | 24 就是说golang 5年后就没了？这个不可能啊 |
|
w***g
发帖数: 5958 | 25 "所有的coroutine库"不包括golang。
特指java和C++的。原帖已改。
我觉得golang不是因为支持用户态线程而牛x，
node.js也不是因为异步I/O牛x。这两个都是因为
填补了别的方面的空缺而牛x的。其中golang主要
因为g推得厉害。不过这个没法验证。
我再做个预测，过几年javascript会出来
thread库来取代异步I/O。到时候人们又会激动得
上窜下跳。 |
|
|
w***g
发帖数: 5958 | 27 这版上几个老哥显然已经过了要刷题跳槽的人生阶段。 |
|
m****o
发帖数: 182 | 28 说句公道话，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都不会太喜欢。用不好还会出现死锁。 |
|
g****t
发帖数: 31659 | 29 scheduler etc很多知识点都是EE的，学了穷三代.
另外别说java这种了。Go这个项目本身说不定也是Rob Pike弄个假项目玩玩。
毕竟所说的 multi－core优势还没有稳定的展现。现在它家核心的scheduler
还在改个不停。只有专家才能知道有多少坑。 |
|
a*****e
发帖数: 1700 | 30 GHC 的 M:N 轻线程调度比 goroutine 早很多年 |
|
g****t
发帖数: 31659 | 31 我没看过，但是我猜rust肯定有。小语言，新的容易实现。 |
|
z****e
发帖数: 54598 | 32
你还是没有看懂人家说的coroutine的目的啊
coroutine是语法糖
主要目的是从高阶函数中解放程序猿
因为高阶函数太多人搞不明白
所以用coroutine或者叫简化的coroutine来解放程序猿
把我的例子认真看一遍
看看coroutine是怎么把程序猿从高阶函数中解放出来的
这个才是目的
说了半天，你们根本就不懂其他人在干嘛
老是用底层那些东西来思考问题
少了一层东西，然后就是死活理解不了
累不累？感觉鸡同鸭讲了 |
|
z****e
发帖数: 54598 | 33
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下面一大堆人在睡觉，哈欠连天
这... 阅读全帖 |
|
i******l
发帖数: 270 | 34 我觉得他想说的是，你在一个核上整，很容易，根本就没有 lock
但是要充分用上多核，这事儿在工程上难度很高。还要搞个自己的
scheduler，work steal，各种走钢丝。目前 golang 搞成了。但
据说它的 channel 性能就不够高。 |
|
s********k
发帖数: 6180 | 35 wdong，如果把golang的程序放到container里面你这个优势就整不出来？还是用user
thread？ |
|
w***g
发帖数: 5958 | 36 container跟performance没啥关系, 只不过是在一群os process外加了isolation. |
|
z****e
发帖数: 54598 | 37
我们先找一个共识
就是在一个core上做
很容易，因为没有lock
对吧？这个是所有人都认可的
然后在这个基础之上，我们有两条路可以走
一种是直接上coroutine，要求coroutine解决多核环境下调度的问题
这就是go走的这条路，我相信这条路不好走
也需要“牛得不得了的人”才能搞定，很有可能
另外一条路是这样，你先放下这个问题，我们继续往前走
看看有没有其他的路，找啊找
诶，突然发现，有一条路叫做actor model
可以通过eventloop这种方式，把原来一大票线程给降下来
为什么呢？原理很简单，原先io的时候，同步api无论如何
要占用一个线程，给我等着
异步api的好处就是可以马上释放调用线程
这样我们可以复用同一个线程，然后对于我们常见的场景
也就是那些大量crud的业务场景
基本上都是io bound的场景，所以可以通过少量线程就能host住大量的请求
比如原来用tomcat，要几千个线程的线程池
现在只需要20多个就行了，甚至用1core 1g的机器，也就是2个eventloop，记住这个关
键字
以后你会经常遇到，spring都开始eventloop，spr... 阅读全帖 |
|
k**n
发帖数: 3989 | 38 应该还没写过复杂的project。。。
象我们这样从java， c#开始往node与client javascript做的， ts就是神器啊。
javascript 用上ts 后， bug少多了， redactor效率高, 不易出错., 加上unittest,
如虎添翼啊. |
|
k**n
发帖数: 3989 | 39 还有fp 与oop 之争真是无聊透顶.
两者完全可以结合一起用.. |
|
z****e
发帖数: 54598 | 40 遇到callback hell的时候
就有道路的分歧了
fp说用高阶函数
oop说让它暂停
目前看，显然是后者占了上风
绝大多数语言都在尝试着做暂停
你说的bug多，那是js的锅，js背，js设计得不好，所以容易写出bug来
所以一堆人想着换语法 |
|
g****t
发帖数: 31659 | 41 没几个本科学过数据结构，操作系统什么的。当然，我也忘差不多了。
: 还有fp 与oop 之争真是无聊透顶.
: 两者完全可以结合一起用..
|
|
N********n
发帖数: 8363 | 42
不喜欢TYPE的都是糙快猛小程序风格，规模一大就傻眼。新版JS也要上ASYNC了，
想做SERVER端的语言都要加ASYNC/AWAIT。 |
|
s*****l
发帖数: 7106 | 43 也不一定
一个糙快猛的prototype
就notepad++里写js就完了 |
|
|
|
n******7
发帖数: 12463 | 46 typescript 用来写新project? 基于node.js? |
|
l******n
发帖数: 9344 | 47 是很久了，这里好像没啥人用
现在有个app是ember做的，要fix一些东西，赶鸭子上架现学现卖
感觉这种基于node的纯js的比typescript的上手快，learning curve更flat，tools也
不少，不过只能用的handlebars，感觉不够灵活 |
|
|
|
f******2
发帖数: 2455 | 50 这年头干活儿上来说性能就是刷流氓。
现在大家care的是developer的cost，没人care机器的cost。
当然，对于cpu intensive的task js是不行，这是js短板。但是大部分的后台就是连连
数据库这类的io型任务，nodejs这个是专长。
: 你是说node.js?
: 性能堪忧啊
|
|
