z****e
发帖数: 54598 | 1 会依次对比node.js, fp, spring, ejb和vert.x的解决方案，然后自己看哪个最好
从最基本的说起，所有语言都一定会有两个东西
一个是变量，我们用var(variable)来表示
另外一个是方法/函数，用func(function)表示
假设有一个函数和一个变量
var var1;
func func1(){
var1 = 0;
return var1+1;//应该是1
}
那现在如果有多个线程并发
那结果会怎样？
那在func1执行完var1 = 0;之后
就有可能有其他线程插入，把var1改成其他值
比如改成var1 = 2; 或者var1 = "goodbug乱入";
那瞬间func1返回值不再是1了，那这个显然是不可接受的
那怎么办？
第一种是fp的做法，fp说，把变量做成immutable
也就是var -> val(value)，把var1改成
val1 = 0;
return val1+1;//就一定是1鸟
但是这样为了多线程把所有的参数都搞成immutable鸟
然后你写代码时候，需要时刻提醒自己
常量啊，常量啊，常量啊……
第二种是node.js等脚本的做法，node说，不要多线程了
单线程就好了，这样就没有其他的线程来修改这个var的值了
嗯，但是这样的话，一旦并发多的话岂不是无法发挥全部机能？
然后就很麻烦，要多process而不是多thread
而且一旦这个thread被长时间blocked，后果将会是灾难性的
而thread又相对容易被blocked，对比一般的多线程，因为总有些操作需要时间
为了解决这个问题，搞出了异步，还弄了callback，做了worker
结果callback很容易导致函数嵌套，变成疯狂缩进的金字塔
代码可读性下降不说，同时这样一搞
使得原本很容易的同步操作，变得麻烦起来，因为不得不用异步去包装
比如db，就不好用了，所以很多都选择了mongo
再加上原先很多api都是同步的，整个修改起来使得开发成本上升
tradeoff很快就出现了
第三种是spring的做法，spring说，把函数写成这样
func1(var var2){
var2 = 0;
return var2+1;//就是1鸟
}
嗯，蛮好，但是这样做的话，我就不能用函数外面的变量了
如果在函数外定义var的话，你一定要小心，spring默认是singleton的
也就是所有的线程共享外面那个var1，那其实还是有并发的问题
类似的，java里面static变量也有类似的问题，所以用spring时候不要乱用static
确保你知道你自己在干嘛，那自由度还是受限呀，因为你时刻要提醒自己
外面那个var1不能用，不能用，不能用……
第四种是ejb的做法，ejb说，表闹了，你把这个包装成一个object
object EJB{//如果是java，class EJB{...
var var1;
func func1(){
var1=0;
return var1+1;
}
}
然后保证ejb container，每次只用一个线程访问这个object的instance
用java的话说就是每次只用一个线程访问这个class的object
如果有并发，给每个thread分配一个instance
这样你就可以自由滴使用那个var1鸟
嗯，很不错，但是有几个问题，一个最凸显的问题就是ejb仅限于java
而当时的java不支持lambda，而没有lambda比较难实现异步，要用反射，就很麻烦
其他语言甚至都不强行要求包装成object，所以也就无法强制实现这个代码片
那要么全换成fp，全换成fp就会出现前面说的限制，以及其他的问题
比如层层嵌套带来的金字塔
第五种就是vert.x的方式
vert.x其实就是把上面这个代码片，包装成一个verticle
然后确保这个verticle的每个instance一次只会被一个thread所执行，o啦
然后把ejb的理念灌输到verticle里面去，实现同样的目的，简化并提升效率
然后你就可以不受限制地使用func以外的变量鸟
大概是酱紫：
verticle{//这个声明不用明确写出来，对于非oop来说，一个main函数的文件就是一个
verticle
//如果是oop，则可以写多个verticles在一个文件里，比如java和ceylon
var var1;
func func1(){
var1 = 0;
return var1+1;//1，什么都没变，如果是脚本，连改都不用改
}
}
基本上啥都没变，也没有要求你注意单线程，immutable
你zip打完包插入就能用，多好
当然vert.x有着跟node.js一样的线程被blocked的问题
虽然相对好一点，因为本身就是多线程的，一个被彻底blocked了，其它还可以用
但是毕竟问题还是存在，所以引入worker，这个其实node.js也有，libuv
另外前面也说了，java以前要想做到异步，需要反射，麻烦
所以java8引入了lambda，这就使得反射的类包装不再必需，写起来就简洁了不少
同时有了rxjava，扁平化处理，这样就搞定了层层嵌套的ugly金字塔
基本上到这里问题都解决得差不多了
然后verticle间的通信可以通过msg在bus上传递
或者使用公用的map来搞掂
vert.x的bus，polyglot什么更是利器，真管用
最喜欢vert.x一点就是，什么都可以有，什么都可以拆掉
而其它的东西总是少这个少那个，然后塞给我一堆东西，各种限制，巨恶心
什么单线程，immutable
理解了这些概念的本质之后你会觉得这种设计是灰常滑稽可笑的
应该说要像单线程一样编程，但是把框架整个就做成单线程的
那就是因噎废食了，全搞成immutable更是糟糕透顶
当然你说这样做可以不可以，也许可以，我也可以这样做
但是我有更好的办法把他们做得更简单，这对于所有人都有好处
所以作为编程师，找工作时候也多了一点讨价还价的资本 |
l******t
发帖数: 55733 | |
z****e
发帖数: 54598 | 3 变量涵盖了常量
人生比较完整
【在 l******t 的大作中提到】
: 只会用“变”量的算不算缺陷啊
|
p*****2
发帖数: 21240 | 4 大牛java以外的经验还是稍微少了点
immutable其实挺好的 应该是作为缺省
【在 z****e 的大作中提到】
: 会依次对比node.js, fp, spring, ejb和vert.x的解决方案，然后自己看哪个最好
: 从最基本的说起，所有语言都一定会有两个东西
: 一个是变量，我们用var(variable)来表示
: 另外一个是方法/函数，用func(function)表示
: 假设有一个函数和一个变量
: var var1;
: func func1(){
: var1 = 0;
: return var1+1;//应该是1
: }
|
l**********n
发帖数: 8443 | 5 fp is about expressing programs in expressions, as much as possible, to
promote code reusability. in order to do that, function has to be first
class citizen. in scala, everything is object. scala has statement/
expression dichotomy. so scala is not fp.
【在 p*****2 的大作中提到】
: 大牛java以外的经验还是稍微少了点
: immutable其实挺好的 应该是作为缺省
|
l**********n
发帖数: 8443 | 6 这么说吧，当你写scala的时候，不可避免的滑向oop的深渊。scala程序员一用var就露
馅了。
【在 l**********n 的大作中提到】
: fp is about expressing programs in expressions, as much as possible, to
: promote code reusability. in order to do that, function has to be first
: class citizen. in scala, everything is object. scala has statement/
: expression dichotomy. so scala is not fp.
|
l******t
发帖数: 55733 | 7 真的可以不用var。
【在 l**********n 的大作中提到】
: 这么说吧，当你写scala的时候，不可避免的滑向oop的深渊。scala程序员一用var就露
: 馅了。
|
c*******9
发帖数: 9032 | 8 变量只适合描述只有量变没有质变的事物，这种变化往往是虚假的，是人用执着观念看
世界导致的。
【在 z****e 的大作中提到】
: 变量涵盖了常量
: 人生比较完整
|
|
O***b
发帖数: 104 | 9 Clojure 的 STM 解决方案跟这几种都不一样吧，把 transaction 方式加进去就比较全
了。
【在 z****e 的大作中提到】
: 会依次对比node.js, fp, spring, ejb和vert.x的解决方案，然后自己看哪个最好
: 从最基本的说起，所有语言都一定会有两个东西
: 一个是变量，我们用var(variable)来表示
: 另外一个是方法/函数，用func(function)表示
: 假设有一个函数和一个变量
: var var1;
: func func1(){
: var1 = 0;
: return var1+1;//应该是1
: }
|
j******f
发帖数: 825 | 10 Node callback很容易被误用，学会应用之后其实最容易效率也最高。api基本都有不要
自己写，并发的问题其实
是个ipc的问题，任何语言都需要解决这个问题。对于io来说node是不二选择。 |
|
|
p*****2
发帖数: 21240 | 11
支持
【在 j******f 的大作中提到】
: Node callback很容易被误用，学会应用之后其实最容易效率也最高。api基本都有不要
: 自己写，并发的问题其实
: 是个ipc的问题，任何语言都需要解决这个问题。对于io来说node是不二选择。
|
l**********n
发帖数: 8443 | 12 fp和immutubility不是一回事，fp is about function composition, currying. fp的
no side effect是说不改变外部变量。没说不能有private变量。
【在 z****e 的大作中提到】
: 会依次对比node.js, fp, spring, ejb和vert.x的解决方案，然后自己看哪个最好
: 从最基本的说起，所有语言都一定会有两个东西
: 一个是变量，我们用var(variable)来表示
: 另外一个是方法/函数，用func(function)表示
: 假设有一个函数和一个变量
: var var1;
: func func1(){
: var1 = 0;
: return var1+1;//应该是1
: }
|
p*****2
发帖数: 21240 | 13
pure fp应该没有private var吧？
【在 l**********n 的大作中提到】
: fp和immutubility不是一回事，fp is about function composition, currying. fp的
: no side effect是说不改变外部变量。没说不能有private变量。
|
l**********n
发帖数: 8443 | 14 单线程用不着immutubility
【在 p*****2 的大作中提到】
:
: pure fp应该没有private var吧？
|
c*********e
发帖数: 16335 | 15 create 一个 thread很昂贵的。为了速度快，是用multi-threading,还是用一个thread
,在这个thread里面asyn呢？据说后一种更快些。有经验的大虾说说，哪种办法更快？
哪种更好？
【在 z****e 的大作中提到】
: 会依次对比node.js, fp, spring, ejb和vert.x的解决方案，然后自己看哪个最好
: 从最基本的说起，所有语言都一定会有两个东西
: 一个是变量，我们用var(variable)来表示
: 另外一个是方法/函数，用func(function)表示
: 假设有一个函数和一个变量
: var var1;
: func func1(){
: var1 = 0;
: return var1+1;//应该是1
: }
|
p*****2
发帖数: 21240 | 16 肯定后一种了
但是multi threads也可以async
thread
？
【在 c*********e 的大作中提到】
: create 一个 thread很昂贵的。为了速度快，是用multi-threading,还是用一个thread
: ,在这个thread里面asyn呢？据说后一种更快些。有经验的大虾说说，哪种办法更快？
: 哪种更好？
|
c*********e
发帖数: 16335 | 17 既然一个thread里面async更快，为什么会用multi-threading呢？
【在 p*****2 的大作中提到】
: 肯定后一种了
: 但是multi threads也可以async
:
: thread
: ？
|
p*****2
发帖数: 21240 | 18 可以更好利用multi core
【在 c*********e 的大作中提到】
: 既然一个thread里面async更快，为什么会用multi-threading呢？
|
c*********e
发帖数: 16335 | 19 你的意思是，只有一个cpu的时候，single thread + async 比 multi-threading 更好？
【在 p*****2 的大作中提到】
: 可以更好利用multi core
|
b*******s
发帖数: 5216 | |
|
|
o**2
发帖数: 168 | 21 帮顶一下
【在 z****e 的大作中提到】
: 会依次对比node.js, fp, spring, ejb和vert.x的解决方案，然后自己看哪个最好
: 从最基本的说起，所有语言都一定会有两个东西
: 一个是变量，我们用var(variable)来表示
: 另外一个是方法/函数，用func(function)表示
: 假设有一个函数和一个变量
: var var1;
: func func1(){
: var1 = 0;
: return var1+1;//应该是1
: }
|
d****e
发帖数: 839 | 22 没看懂，LZ是要把变量当local的用，那为什么要把它定义为global的？如果要当
global的用，在多线程下，难道不应该用mutex之类的把它保护起来吗？我是写C/C++的
，可能没完全搞懂LZ的意图。 |
b*******s
发帖数: 5216 | 23 he only knows something very basic about concurrency
【在 d****e 的大作中提到】
: 没看懂，LZ是要把变量当local的用，那为什么要把它定义为global的？如果要当
: global的用，在多线程下，难道不应该用mutex之类的把它保护起来吗？我是写C/C++的
: ，可能没完全搞懂LZ的意图。
|
g*****g
发帖数: 34805 | 24 他就是举个大家容易理解的例子，这里转行的太多。spring, ejb都是很规范的框架，
什么东西怎么写都是有无数范例的。写错了code review绝对过不了。
【在 d****e 的大作中提到】
: 没看懂，LZ是要把变量当local的用，那为什么要把它定义为global的？如果要当
: global的用，在多线程下，难道不应该用mutex之类的把它保护起来吗？我是写C/C++的
: ，可能没完全搞懂LZ的意图。
|
p*****2
发帖数: 21240 | 25
好？
是。
【在 c*********e 的大作中提到】
: 你的意思是，只有一个cpu的时候，single thread + async 比 multi-threading 更好？
|
z****e
发帖数: 54598 | 26 多线程直接上框架，还写啥呀
没事找事，只有很少情况才会不得不去处理多线程的并发
【在 d****e 的大作中提到】
: 没看懂，LZ是要把变量当local的用，那为什么要把它定义为global的？如果要当
: global的用，在多线程下，难道不应该用mutex之类的把它保护起来吗？我是写C/C++的
: ，可能没完全搞懂LZ的意图。
|
z****e
发帖数: 54598 | 27 这个不重要，get things done最重要
其它都是次要的，太过于理论抽象的东西，不应该在语言层面enforce
抽象成数学命题比较合适，hand over给物理等专业去讨论
【在 c*******9 的大作中提到】
: 变量只适合描述只有量变没有质变的事物，这种变化往往是虚假的，是人用执着观念看
: 世界导致的。
|
z****e
发帖数: 54598 | 28 fp涵盖了var
只是不推荐使用var
否则会在并发的时候用上大量的lock
会让你的程序变得难以维护
这一点上说，无论什么多线程的框架
其本意都是为了让用户不再使用lock
像单线程一样编程是目的
这个其实无论啥都是一样的
但是实现的手段截然不同，而且效果也很明显有差异
【在 l**********n 的大作中提到】
: 这么说吧，当你写scala的时候，不可避免的滑向oop的深渊。scala程序员一用var就露
: 馅了。
|
z****e
发帖数: 54598 | 29 transaction如果展开的话，还有额外一堆的讨论
其实就是lock，上面说的至少在用户层面都是lock free滴
需要lock的话，那就太原始了，因为本身很难以维护
最终不会变简单，会变得很痛苦，上面说的只是用户层面的东西
就不涉及具体的框架怎么实现，其中当然有可能用到lock和transaction这些
但是那种一般用不到，就跟楼上那个c/c++说的差不多
【在 O***b 的大作中提到】
: Clojure 的 STM 解决方案跟这几种都不一样吧，把 transaction 方式加进去就比较全
: 了。
|
z****e
发帖数: 54598 | 30 是被滥用
你还是木有尝试vert.x
我不跟你argue，因为你缺少vert.x实际动手经验
等你试过之后再说，看看vert.x是怎么解决callback hell的
当然这你需要看rxjava，小马过河，你与其在这里为node做广告
不如自己动手试试看，vert.x从node那边抄袭了很多东西
好不好，我说了不算，你说了也不算，试过的人自己会有判断
【在 j******f 的大作中提到】
: Node callback很容易被误用，学会应用之后其实最容易效率也最高。api基本都有不要
: 自己写，并发的问题其实
: 是个ipc的问题，任何语言都需要解决这个问题。对于io来说node是不二选择。
|
|
|
z****e
发帖数: 54598 | 31 什么年代的事了
那是90年代create一个object很消耗内存啥的
现在，一s给我10^4方个对象，你觉得慢吗？
后来主要问题是gc会有停顿，所以主要是通过pool来解决这个问题
thread
？
【在 c*********e 的大作中提到】
: create 一个 thread很昂贵的。为了速度快，是用multi-threading,还是用一个thread
: ,在这个thread里面asyn呢？据说后一种更快些。有经验的大虾说说，哪种办法更快？
: 哪种更好？
|
z****e
发帖数: 54598 | 32 不错
只有1st class func需要immu来配合
否则很容易escape
【在 l**********n 的大作中提到】
: 单线程用不着immutubility
|
z****e
发帖数: 54598 | 33 是不是一回事，currying跟immutable也不是一回事
把fp拆成个体之后，有选择性吸收，这里说的是如何用这些多线程的框架
fp都是1st class citizen，你当然不能随便改变外部变量
否则全局变量被修改，side effect大了，一堆人骂娘
private是object的概念，func private啥，local var吧
【在 l**********n 的大作中提到】
: fp和immutubility不是一回事，fp is about function composition, currying. fp的
: no side effect是说不改变外部变量。没说不能有private变量。
|
z****e
发帖数: 54598 | 34 which is vert.x
【在 p*****2 的大作中提到】
: 肯定后一种了
: 但是multi threads也可以async
:
: thread
: ？
|
z****e
发帖数: 54598 | 35 另外，只有node才需要ipc
其它框架都是itc
这就是为啥node很傻逼
像单线程一样编程是目的
但是你真把所有东西都做成单线程的话
那个thread挂了咋办捏？
哪怕是一个不小心，被阿三程序员写段代码blocked了
你不一样很苦逼？
当然这个问题哪怕是弄成itc一样存在
但是至少至少，其它启动的threads会在一定程度上抵消这个问题
我猜测这就是为啥在大多数报告里面，node总是会有丢包的问题
可能就是那个线程出了问题，把所有鸡蛋全部放在一个篮子里
自然会出问题，vert.x说，我按照cpu有多少个core来建threads
一个dual core的cpu，vert.x就启两个threads，如果是两个这种cpus
就起2*2=4个threads，这样万一其中一个thread被blocked，一样不会挂，对不对？
当然blocked在异步编程中是错误的，而且同一个process下处理communication
比起多个processes下处理，那是要强太多了，不同process之间做c，那很苦逼的好不好
得调用第三方工具，各种狗血问题，所以你还是用node的思维来看其他多线程框架
被node给局限了，哪怕你看看fp也好，看看akka和play
【在 j******f 的大作中提到】
: Node callback很容易被误用，学会应用之后其实最容易效率也最高。api基本都有不要
: 自己写，并发的问题其实
: 是个ipc的问题，任何语言都需要解决这个问题。对于io来说node是不二选择。
|
z****e
发帖数: 54598 | 36 你写游戏就会用了
对var不感兴趣的人对世界缺乏探索精神
常量真滴很无趣，死的东西
var才是活物，人就是一个var
表被fp教徒给骗了，fp说变量不需要是谎言
凡事过犹不及
【在 l******t 的大作中提到】
: 真的可以不用var。
|
z****e
发帖数: 54598 | 37 比起你自己动手去用各种lock，那是要强太多
但是比起其他多线程的框架来说，比如fp那种
就未必了，其实本质没啥大不了的
无非就是隔离嘛，mutable的var容易导致冲突
那如何解决，就是这些框架要解决的问题
解决手段有很多，最终实现的程度也不一样
显然vert.x最爽，你不需要成天惦记着什么single thread, immutable这些东西
当然synchronized这些就更不需要了，vert.x下我可以肆无忌惮滴重用代码
只需要记住一个basic rule，任何时候，一个verticle只会被一个thread所访问，o啦
剩下的是vert.x的事，其他的都做不到，要你记这个要你记那个，烦死
嗯，ejb勉强可以，但是繁琐了点，要配置，当然vert.x也不是完美的
还是需要自己对付异步问题，虽然比起node已经好很多了
那现在不就是一堆人涌过去解决这个问题嘛
把以前老的同步api全部弄成异步的，当然rxjava解决的callback金字塔也是一个成果
好？
【在 c*********e 的大作中提到】
: 你的意思是，只有一个cpu的时候，single thread + async 比 multi-threading 更好？
|
p*****2
发帖数: 21240 | 38 我觉得vert.x主要是成熟度的问题
node确实有局限性 但是做web基本也够用了
【在 z****e 的大作中提到】
: 另外，只有node才需要ipc
: 其它框架都是itc
: 这就是为啥node很傻逼
: 像单线程一样编程是目的
: 但是你真把所有东西都做成单线程的话
: 那个thread挂了咋办捏？
: 哪怕是一个不小心，被阿三程序员写段代码blocked了
: 你不一样很苦逼？
: 当然这个问题哪怕是弄成itc一样存在
: 但是至少至少，其它启动的threads会在一定程度上抵消这个问题
|
p*****2
发帖数: 21240 | 39 fp涵盖var是什么意思？
【在 z****e 的大作中提到】
: fp涵盖了var
: 只是不推荐使用var
: 否则会在并发的时候用上大量的lock
: 会让你的程序变得难以维护
: 这一点上说，无论什么多线程的框架
: 其本意都是为了让用户不再使用lock
: 像单线程一样编程是目的
: 这个其实无论啥都是一样的
: 但是实现的手段截然不同，而且效果也很明显有差异
|
j******f
发帖数: 825 | 40 解决了IPC问题，NODE就解决了多机并发问题，也解决了一个线程挂掉的问题。
而对于其他语言，首先要解决IPC的问题，然后还要解决ITC问题，然后还要面临一大堆
concurrency问题。
对于IO来说，NODE的速度秒杀其他synchronous语言。
【在 z****e 的大作中提到】
: 另外，只有node才需要ipc
: 其它框架都是itc
: 这就是为啥node很傻逼
: 像单线程一样编程是目的
: 但是你真把所有东西都做成单线程的话
: 那个thread挂了咋办捏？
: 哪怕是一个不小心，被阿三程序员写段代码blocked了
: 你不一样很苦逼？
: 当然这个问题哪怕是弄成itc一样存在
: 但是至少至少，其它启动的threads会在一定程度上抵消这个问题
|
|
|
j******f
发帖数: 825 | 41 vert.x我在几年以前看过，主要问题我不喜欢heavy的框架, 还有它很难scale。
callback不难解决，eventemitter + queue 即可。
【在 z****e 的大作中提到】
: 是被滥用
: 你还是木有尝试vert.x
: 我不跟你argue，因为你缺少vert.x实际动手经验
: 等你试过之后再说，看看vert.x是怎么解决callback hell的
: 当然这你需要看rxjava，小马过河，你与其在这里为node做广告
: 不如自己动手试试看，vert.x从node那边抄袭了很多东西
: 好不好，我说了不算，你说了也不算，试过的人自己会有判断
|
z****e
发帖数: 54598 | 42 vert.x heavy在哪里？总共就10多m的一个东西
为啥很难scale？
只要做到stateless，scale都很容易，几乎都是线性scale
哪怕ejb都可以很容易做到线性scale
vert.x天生就是stateless的东西
所谓scale难都是一些无聊的人为了吹嘘自己的本领而编造出来的
做过以后就不以为然的
【在 j******f 的大作中提到】
: vert.x我在几年以前看过，主要问题我不喜欢heavy的框架, 还有它很难scale。
: callback不难解决，eventemitter + queue 即可。
|
z****e
发帖数: 54598 | 43 其他框架根本不需要多process，去哪里来的ipc问题？
node的ipc放在其他框架就是itc，而且vert.x天生就有一个bus予以解决
node还要自己倒腾第三方工具予以解决，只有node需要倒腾第三方工具解决并发问题
其他都不用，哪怕是akka都是自己搞定，所谓ipc就是一个集成的问题
单机系统还需要集成的只有单线程，其他都不用，自己能搞定
这个完全是一个名词上的混淆，根本不是什么优势，是大大滴劣势
至于io快，纯粹胡说八道，vert.x vs node.js的报告到处都是
自己试试就知道node有多烂了，你还是没试过，凭想象来指责其他框架的问题
【在 j******f 的大作中提到】
: 解决了IPC问题，NODE就解决了多机并发问题，也解决了一个线程挂掉的问题。
: 而对于其他语言，首先要解决IPC的问题，然后还要解决ITC问题，然后还要面临一大堆
: concurrency问题。
: 对于IO来说，NODE的速度秒杀其他synchronous语言。
|
z****e
发帖数: 54598 | 44 0.x的版本都敢用，连丢包都不在乎，内存上1g都出问题，都敢下放生产
vert.x比起来，要nice太多，node不稳定早就有人说过了
做hello world的确是够用，php都够，这些说法深入了解之后都觉得是人想象出来的东西
总有人坚持自己的想象
【在 p*****2 的大作中提到】
: 我觉得vert.x主要是成熟度的问题
: node确实有局限性 但是做web基本也够用了
|
z****e
发帖数: 54598 | 45 应该说fp不反对var
反对var是为了多线程编造出来的谎言
因为pure fp解决不了多线程带来的var冲突
所以只好immutable鸟
这完全没有必要，就跟单线程一样
纯粹浪费
【在 p*****2 的大作中提到】
: fp涵盖var是什么意思？
|
p*****2
发帖数: 21240 | 46 貌似你理解还不太够
纯fp应该是没有var的 是state monad
【在 z****e 的大作中提到】
: 应该说fp不反对var
: 反对var是为了多线程编造出来的谎言
: 因为pure fp解决不了多线程带来的var冲突
: 所以只好immutable鸟
: 这完全没有必要，就跟单线程一样
: 纯粹浪费
|
j******f
发帖数: 825 | 47 要说scale很容易，我只能说你没碰过复杂的情况。
【在 z****e 的大作中提到】
: vert.x heavy在哪里？总共就10多m的一个东西
: 为啥很难scale？
: 只要做到stateless，scale都很容易，几乎都是线性scale
: 哪怕ejb都可以很容易做到线性scale
: vert.x天生就是stateless的东西
: 所谓scale难都是一些无聊的人为了吹嘘自己的本领而编造出来的
: 做过以后就不以为然的
|
z****e
发帖数: 54598 | 48 我没说很容易
如果用node就不那么容易，尤其是当process多了之后
就很恶心
用vert.x就相对简单，因为这种情况在预料之中，有现成的文档予以解决
而且不同情况不一样
有些场景比如游戏就很难
但是大多数尤其是web，就相对简单很多
node在单机上的多process都需要第三方软件介入
这是非常滑稽可笑的，就是对这些东西了解了之后
才会觉得它烂，而不是像宗教一样，除了说好和坏以外，连一个合理的理由都说不出来
估计你没搞过其他的框架，我怀疑你甚至连vert.x可以直接用js都不知道
当然灌水嘛，不用太认真
【在 j******f 的大作中提到】
: 要说scale很容易，我只能说你没碰过复杂的情况。
|
z****e
发帖数: 54598 | 49 纯粹的fp没有意义
【在 p*****2 的大作中提到】
: 貌似你理解还不太够
: 纯fp应该是没有var的 是state monad
|
j******f
发帖数: 825 | 50 用框架还是自己搭，看你喜好。我是能自己做就不要用框架。自己做代码小，自由效率
高。用框架可能容易点，但受限制。请问你用node做是不是搞砸了所以如此痛恨它
【在 z****e 的大作中提到】
: 我没说很容易
: 如果用node就不那么容易，尤其是当process多了之后
: 就很恶心
: 用vert.x就相对简单，因为这种情况在预料之中，有现成的文档予以解决
: 而且不同情况不一样
: 有些场景比如游戏就很难
: 但是大多数尤其是web，就相对简单很多
: node在单机上的多process都需要第三方软件介入
: 这是非常滑稽可笑的，就是对这些东西了解了之后
: 才会觉得它烂，而不是像宗教一样，除了说好和坏以外，连一个合理的理由都说不出来
|
|
|
z****e
发帖数: 54598 | 51 你搞错了吧
node才是最大的限制
单线程怎么做都是束手束脚的
vertx的限制是最少的
我没搞砸，两个我都看明白了
所以才会告诉你单线程sucks
而你根本没看懂vert.x在做啥
【在 j******f 的大作中提到】
: 用框架还是自己搭，看你喜好。我是能自己做就不要用框架。自己做代码小，自由效率
: 高。用框架可能容易点，但受限制。请问你用node做是不是搞砸了所以如此痛恨它
|
z****e
发帖数: 54598 | 52
另外，什么自己做代码小，自由效率高
这句话我给你换个说法
你其他的东西没做过
看来我猜对了
【在 j******f 的大作中提到】
: 用框架还是自己搭，看你喜好。我是能自己做就不要用框架。自己做代码小，自由效率
: 高。用框架可能容易点，但受限制。请问你用node做是不是搞砸了所以如此痛恨它
|
j******f
发帖数: 825 | 53 要意淫你随便，另外要回复想好再说省得我还得回两个帖子，看来你连修改帖子功能都
不会。
【在 z****e 的大作中提到】
:
: 另外，什么自己做代码小，自由效率高
: 这句话我给你换个说法
: 你其他的东西没做过
: 看来我猜对了
|
z****e
发帖数: 54598 | 54 lol
不用羞恼成怒
你有没有经验，是骗不了人的，这点应该整个行业都是共识
面试多面几次就知道了，你是懂还是不懂，装是没有用的
撒谎最麻烦的一点就是要不停滴编造更多谎言，去掩饰你不知道的真相
我直接回帖多方便，为什么要修改啊？
还要额外点回去
【在 j******f 的大作中提到】
: 要意淫你随便，另外要回复想好再说省得我还得回两个帖子，看来你连修改帖子功能都
: 不会。
|
j******f
发帖数: 825 | 55 看看你回的每个帖子就是不停的说别人不懂你懂，你懂的话node都搞不明白，让人笑掉
大牙。
还需要面试吗，不管你懂不懂，你已经没面试机会了。
【在 z****e 的大作中提到】
: lol
: 不用羞恼成怒
: 你有没有经验，是骗不了人的，这点应该整个行业都是共识
: 面试多面几次就知道了，你是懂还是不懂，装是没有用的
: 撒谎最麻烦的一点就是要不停滴编造更多谎言，去掩饰你不知道的真相
: 我直接回帖多方便，为什么要修改啊？
: 还要额外点回去
|
z****e
发帖数: 54598 | 56 lol
这里说的是你不懂vert.x的结构
你自己不都承认了吗？
还狡辩社么？
【在 j******f 的大作中提到】
: 看看你回的每个帖子就是不停的说别人不懂你懂，你懂的话node都搞不明白，让人笑掉
: 大牙。
: 还需要面试吗，不管你懂不懂，你已经没面试机会了。
|
j******f
发帖数: 825 | 57 说的是你不懂node，你自己说搞不定的。
vert.x用js我都要笑弯腰了，你用js不用node，绕了一大圈去通过vert.x来用js？恰恰
证明你根本不懂node，需要用vert.x来帮助你解决你的问题。
其实用vert.x没什么，没啥不好意识的，水平差点借助一下vert.x也没啥，别想太多，
只要能干活啥都行。
【在 z****e 的大作中提到】
: lol
: 这里说的是你不懂vert.x的结构
: 你自己不都承认了吗？
: 还狡辩社么？
|
z****e
发帖数: 54598 | 58 搞得定啊
问题是太麻烦啊
显然process是一个更为恶心的存在
对比thread来说
我们说的是你没有用过
你说你用过，还记得吗？
还“研究”过，就在这一页的最上面
一看那句话就是胡扯蛋，显然是你以为只有你那种方式才搞得定
事实是，你那种方式是非常糟糕的，其他方式你一概不知道
你才会做出那种判断，所以我就给你设了个套
刺激你一下，看看你是不是真的知道
看下去，果然是不知道，无意之中说漏了嘴
难道不是吗？
你个骗子
【在 j******f 的大作中提到】
: 说的是你不懂node，你自己说搞不定的。
: vert.x用js我都要笑弯腰了，你用js不用node，绕了一大圈去通过vert.x来用js？恰恰
: 证明你根本不懂node，需要用vert.x来帮助你解决你的问题。
: 其实用vert.x没什么，没啥不好意识的，水平差点借助一下vert.x也没啥，别想太多，
: 只要能干活啥都行。
|
z****e
发帖数: 54598 | 59 你知道vert.x才多大吗？
还几年前，哈哈
我都懒得说你，别装了同学
【在 j******f 的大作中提到】
: 说的是你不懂node，你自己说搞不定的。
: vert.x用js我都要笑弯腰了，你用js不用node，绕了一大圈去通过vert.x来用js？恰恰
: 证明你根本不懂node，需要用vert.x来帮助你解决你的问题。
: 其实用vert.x没什么，没啥不好意识的，水平差点借助一下vert.x也没啥，别想太多，
: 只要能干活啥都行。
|
j******f
发帖数: 825 | 60 搞得定但是太麻烦？ 还是搞不定。
【在 z****e 的大作中提到】
: 搞得定啊
: 问题是太麻烦啊
: 显然process是一个更为恶心的存在
: 对比thread来说
: 我们说的是你没有用过
: 你说你用过，还记得吗？
: 还“研究”过，就在这一页的最上面
: 一看那句话就是胡扯蛋，显然是你以为只有你那种方式才搞得定
: 事实是，你那种方式是非常糟糕的，其他方式你一概不知道
: 你才会做出那种判断，所以我就给你设了个套
|
|
|
z****e
发帖数: 54598 | 61 太麻烦是觉得恶心
就像我不会走路去北京一样
这叫太麻烦，而你一说出来你会自己造轮子我就笑了
你就忽悠吧，多process一样会动用其他轮子，哪怕你用的是node
你造个p轮子，你就骗吧
【在 j******f 的大作中提到】
: 搞得定但是太麻烦？ 还是搞不定。
|
j******f
发帖数: 825 | 62 行了你就用vert.x吧，够你用的了，挺好
【在 z****e 的大作中提到】
: 太麻烦是觉得恶心
: 就像我不会走路去北京一样
: 这叫太麻烦，而你一说出来你会自己造轮子我就笑了
: 你就忽悠吧，多process一样会动用其他轮子，哪怕你用的是node
: 你造个p轮子，你就骗吧
|
z****e
发帖数: 54598 | 63 基本上这个版面敢说自己是造轮子的
都可以归为骗子一类
深入问下去，多数都会有马脚
这个世界上不是没有造轮子的
但是写个hello world就出来忽悠自己是造轮子的
那还是很多的
【在 j******f 的大作中提到】
: 搞得定但是太麻烦？ 还是搞不定。
|
z****e
发帖数: 54598 | 64 lol
你自己查查几年前vert.x还在什么状态吧
骗子的马脚很容易露出
只要稍微了解一点历史
你就是一个骗子～！
【在 j******f 的大作中提到】
: 行了你就用vert.x吧，够你用的了，挺好
|
j******f
发帖数: 825 | 65 我也就能骗你，骗不了别人
【在 z****e 的大作中提到】
: lol
: 你自己查查几年前vert.x还在什么状态吧
: 骗子的马脚很容易露出
: 只要稍微了解一点历史
: 你就是一个骗子～！
|
z****e
发帖数: 54598 | 66 lol
不用满地打滚了
骗子你好
【在 j******f 的大作中提到】
: 我也就能骗你，骗不了别人
|
p*****2
发帖数: 21240 | 67 为什么node scale不容易
为什么需要第三方呀
【在 z****e 的大作中提到】
: 我没说很容易
: 如果用node就不那么容易，尤其是当process多了之后
: 就很恶心
: 用vert.x就相对简单，因为这种情况在预料之中，有现成的文档予以解决
: 而且不同情况不一样
: 有些场景比如游戏就很难
: 但是大多数尤其是web，就相对简单很多
: node在单机上的多process都需要第三方软件介入
: 这是非常滑稽可笑的，就是对这些东西了解了之后
: 才会觉得它烂，而不是像宗教一样，除了说好和坏以外，连一个合理的理由都说不出来
|
z****e
发帖数: 54598 | 68 相对不容易
其实总体而言都很容易
但是有骗子说vert.x scale会有问题嘛
这个一看就是胡扯蛋，那既然要比较难易度
那显然是vert.x容易scale啊
最简单的，我把cpu从一个core弄成多个cores，vert.x不用做任何修改
全部自动搞定，node就需要自己弄了
而且同样能够handle async的情况，前面我说js能够直接用在vert.x上就是告诉某些骗子
async其实跟语言无关，甚至跟运行环境都没有太大关系
换个语言一样用async，哪怕是python, ruby都可以做到
甚至perl，可惜骗子领悟能力太低，看不懂
其实immutable跟语言本身也是无关的
把context看完整
【在 p*****2 的大作中提到】
: 为什么node scale不容易
: 为什么需要第三方呀
|
z****e
发帖数: 54598 | 69 需要第三方因为捆绑一个process只有一个thread
这个显然是错误的，具体例子可以看这个
http://blog.carbonfive.com/2014/02/28/taking-advantage-of-multi
只是一个idea，很明显，放弃多线程并不是一个明智的选择
显然应该想办法对付多线程，而不是直接上多进程
当然跟immutable一样，问能不能这样搞，可以
但是这样搞不够聪明，不够好，就这么简单
不像是一个solution，更像是一个回避，相比之下，其它框架都是通过threads来搞定
很优雅啊，也没有导致其他问题产生
一般只有多个虚拟机结点出现的时候才会用cluster
但是node在多个core时候就会启动这个模式，甚至load balancing, 这真是wtf啊
这个显然是错误的，本来应该是itc的问题变成了ipc
这个太奇芭了，其他框架都不需要这么做
当你有多个虚拟机nodes时候才需要用cluster
其他框架在cpu的更换的时候都不需要怎么弄，全自动的
唯独node要自己写代码予以配合
这是不是很奇芭？搞cluster等于是把框架应该解决的问题丢给了用户去解决
这框架太不负责了，换句话说，node也能叫做多线程框架？不行吧
一旦丢给了用户，用户又会面对着一样的问题，那就是资源的争抢
lock等以前在多线程中遇到的问题，因为压根node就没解决嘛
【在 p*****2 的大作中提到】
: 为什么node scale不容易
: 为什么需要第三方呀
|
z****e
发帖数: 54598 | 70 btw，我机器上启动一个process要30ms,而启动一个thread只要不到1ms,平均只有.1ms,
process带来的overhead实在是太高了，300倍的差距，而几乎所有的worker无论node
还是vert都需要额外启动process/thread,30ms实在是太慢了！足够我10g的内存做20次
左右的大gc了，小gc就更多了，有兴趣的自己在电脑上试试，你好容易用异步省下来的
时间就都被process的包装给消耗掉了 |
|
|
z****e
发帖数: 54598 | 71 用多线程搞异步，就是用ejb方式折腾worker都可以，完全可以对每一个worker实例单
独启
动一个thread, 但是如果是process, 就没戏了，很容易就出问题了 |
p*****2
发帖数: 21240 | 72 vert.x async 库不全吧？所以不能做到完全async。
骗子
【在 z****e 的大作中提到】
: 相对不容易
: 其实总体而言都很容易
: 但是有骗子说vert.x scale会有问题嘛
: 这个一看就是胡扯蛋，那既然要比较难易度
: 那显然是vert.x容易scale啊
: 最简单的，我把cpu从一个core弄成多个cores，vert.x不用做任何修改
: 全部自动搞定，node就需要自己弄了
: 而且同样能够handle async的情况，前面我说js能够直接用在vert.x上就是告诉某些骗子
: async其实跟语言无关，甚至跟运行环境都没有太大关系
: 换个语言一样用async，哪怕是python, ruby都可以做到
|
p*****2
发帖数: 21240 | 73 你去看看python ruby怎么搞的
node跟java比本来意思就不大
web这块动态语言比较有优势
1ms,
node
【在 z****e 的大作中提到】
: btw，我机器上启动一个process要30ms,而启动一个thread只要不到1ms,平均只有.1ms,
: process带来的overhead实在是太高了，300倍的差距，而几乎所有的worker无论node
: 还是vert都需要额外启动process/thread,30ms实在是太慢了！足够我10g的内存做20次
: 左右的大gc了，小gc就更多了，有兴趣的自己在电脑上试试，你好容易用异步省下来的
: 时间就都被process的包装给消耗掉了
|
j******f
发帖数: 825 | 74 现在比速度都拿node比，都想证明比node快，这本身就证明了node在IO上的巨大优势，
已经成为标杆了。 |
o**2
发帖数: 168 | 75 我也算版面上的了吧，你这样说，我没法不对号入座啊，我可是号称做programming
paradigm的，比做轮子可严重多了，嘿嘿
【在 z****e 的大作中提到】
: 基本上这个版面敢说自己是造轮子的
: 都可以归为骗子一类
: 深入问下去，多数都会有马脚
: 这个世界上不是没有造轮子的
: 但是写个hello world就出来忽悠自己是造轮子的
: 那还是很多的
|
z****e
发帖数: 54598 | 76 async还要库？
只要有lambda，什么都可以轻易做到async
为什么要库？
即便没有lambda，reflection也同样可以做到完全的async
话说async完全不完全其实就是看你有没有block thread
只要你能让你的组件不block thread，你就能做到完全的async
而且对于多线程来说，一个最最最简单的做到async的方法
就是对于某些特别耗时的step，额外启动独立的线程就好了
所谓worker只是增加了callback func进去而已
如果不需要callback的话，直接new thread().start()，搞定
这个就是最简单的async
【在 p*****2 的大作中提到】
: vert.x async 库不全吧？所以不能做到完全async。
:
: 骗子
|
z****e
发帖数: 54598 | 77 动态类型无法真正启用ide的优势
所以swift和dart都已经抛弃了动态类型
把静态类型作为首选，动态类型维护起来是一个巨大的烦恼
很容易都不知道别人在干嘛
async不需要啥整，压根不是js所独有的
本来node就是抄袭eventmachine这些设计的prototype
【在 p*****2 的大作中提到】
: 你去看看python ruby怎么搞的
: node跟java比本来意思就不大
: web这块动态语言比较有优势
:
: 1ms,
: node
|
z****e
发帖数: 54598 | 78 io优势你说的是async吧
你根本没弄明白async到底啥意思吧？
node本身就是抄袭eventmachine的产物这个知道吗？
node慢又不是什么新闻，随便找个benchmark都可以告诉你结果
https://www.techempower.com/benchmarks/
无数人贴过很多遍的东西了
异步本身可以带来效率上的提升，但是这个跟node没半毛钱关系
也只有你这种半吊子才会以为这个东西是某个语言独有的
丢人现眼
【在 j******f 的大作中提到】
: 现在比速度都拿node比，都想证明比node快，这本身就证明了node在IO上的巨大优势，
: 已经成为标杆了。
|
z****e
发帖数: 54598 | 79 nah
是否是真的做轮子的，看产品就知道了
半海说他有一个开源的project，它跑出来说我是做轮子的，我信
你也有产品，你说你是做轮子的，我也信
真正做轮子的人，不需要把做轮子挂嘴边
直接说产品就好了，你有自己的产品，所以说的都是具体的产品
而非什么做轮子这么general的说法，而且产品本身是竞争的
说这么general的话，会给竞争对手以机会，所以一般都不会说什么轮子
就直接告诉你，我是做a项目的，比如我是做vert.x的
我不会说我是做轮子的，因为这没有意义，所以上来就说自己是造轮子的
不是没有经验，就是纯粹忽悠
【在 o**2 的大作中提到】
: 我也算版面上的了吧，你这样说，我没法不对号入座啊，我可是号称做programming
: paradigm的，比做轮子可严重多了，嘿嘿
|
j******f
发帖数: 825 | 80 靠你抄袭了我那么多还好意识在这喷？
【在 z****e 的大作中提到】
: io优势你说的是async吧
: 你根本没弄明白async到底啥意思吧？
: node本身就是抄袭eventmachine的产物这个知道吗？
: node慢又不是什么新闻，随便找个benchmark都可以告诉你结果
: https://www.techempower.com/benchmarks/
: 无数人贴过很多遍的东西了
: 异步本身可以带来效率上的提升，但是这个跟node没半毛钱关系
: 也只有你这种半吊子才会以为这个东西是某个语言独有的
: 丢人现眼
|
|
|
z****e
发帖数: 54598 | 81 瞎扯，谁抄谁啊？
node抄了eventmachine，就不允许别人用了？
【在 j******f 的大作中提到】
: 靠你抄袭了我那么多还好意识在这喷？
|
p*****2
发帖数: 21240 | 82
你的理解真的是有问题了。我建议你好好学学Node，就知道Node的强大了。
【在 z****e 的大作中提到】
: async还要库？
: 只要有lambda，什么都可以轻易做到async
: 为什么要库？
: 即便没有lambda，reflection也同样可以做到完全的async
: 话说async完全不完全其实就是看你有没有block thread
: 只要你能让你的组件不block thread，你就能做到完全的async
: 而且对于多线程来说，一个最最最简单的做到async的方法
: 就是对于某些特别耗时的step，额外启动独立的线程就好了
: 所谓worker只是增加了callback func进去而已
: 如果不需要callback的话，直接new thread().start()，搞定
|
z****e
发帖数: 54598 | 83 我知道node怎么搞的呀
问题是node无法像vert一样自由创造threads
这个就是一大限制
只要保证threads之间独立，异步很容易搞
有了lambda该有的就都有了，完全不需要屈从worker其实
自己写也就是分分钟的事
【在 p*****2 的大作中提到】
:
: 你的理解真的是有问题了。我建议你好好学学Node，就知道Node的强大了。
|
p*****2
发帖数: 21240 | 84
异步跟thread没啥关系，其实。
【在 z****e 的大作中提到】
: 我知道node怎么搞的呀
: 问题是node无法像vert一样自由创造threads
: 这个就是一大限制
: 只要保证threads之间独立，异步很容易搞
: 有了lambda该有的就都有了，完全不需要屈从worker其实
: 自己写也就是分分钟的事
|
z****e
发帖数: 54598 | 85 因为node只考虑一个thread，所以造成了这种误解
当多个threads出现之后，哪怕是worker出现了之后
thread就卷进来了，因为node没办法自行启动thread
所以这种解决方案永远都不会出现在node里面
其实vert.x就是把node用process做的全部改成用thread完成
以节省资源，就这么简单
而且因为具体一个thread本身占用资源很少
所以很多时候我可以很随意地使用thread，但是如果是process
那就没办法了，稍微多一点就会出问题，我laptop上chrome最喜欢乱起process
【在 p*****2 的大作中提到】
:
: 异步跟thread没啥关系，其实。
|
z****e
发帖数: 54598 | 86 会依次对比node.js, fp, spring, ejb和vert.x的解决方案，然后自己看哪个最好
从最基本的说起，所有语言都一定会有两个东西
一个是变量，我们用var(variable)来表示
另外一个是方法/函数，用func(function)表示
假设有一个函数和一个变量
var var1;
func func1(){
var1 = 0;
return var1+1;//应该是1
}
那现在如果有多个线程并发
那结果会怎样？
那在func1执行完var1 = 0;之后
就有可能有其他线程插入，把var1改成其他值
比如改成var1 = 2; 或者var1 = "goodbug乱入";
那瞬间func1返回值不再是1了，那这个显然是不可接受的
那怎么办？
第一种是fp的做法，fp说，把变量做成immutable
也就是var -> val(value)，把var1改成
val1 = 0;
return val1+1;//就一定是1鸟
但是这样为了多线程把所有的参数都搞成immutable鸟
然后你写代码时候，需要时刻提醒自己
常量啊，常量啊，常量啊……
第二种是node.js等脚本的做法，node说，不要多线程了
单线程就好了，这样就没有其他的线程来修改这个var的值了
嗯，但是这样的话，一旦并发多的话岂不是无法发挥全部机能？
然后就很麻烦，要多process而不是多thread
而且一旦这个thread被长时间blocked，后果将会是灾难性的
而thread又相对容易被blocked，对比一般的多线程，因为总有些操作需要时间
为了解决这个问题，搞出了异步，还弄了callback，做了worker
结果callback很容易导致函数嵌套，变成疯狂缩进的金字塔
代码可读性下降不说，同时这样一搞
使得原本很容易的同步操作，变得麻烦起来，因为不得不用异步去包装
比如db，就不好用了，所以很多都选择了mongo
再加上原先很多api都是同步的，整个修改起来使得开发成本上升
tradeoff很快就出现了
第三种是spring的做法，spring说，把函数写成这样
func1(var var2){
var2 = 0;
return var2+1;//就是1鸟
}
嗯，蛮好，但是这样做的话，我就不能用函数外面的变量了
如果在函数外定义var的话，你一定要小心，spring默认是singleton的
也就是所有的线程共享外面那个var1，那其实还是有并发的问题
类似的，java里面static变量也有类似的问题，所以用spring时候不要乱用static
确保你知道你自己在干嘛，那自由度还是受限呀，因为你时刻要提醒自己
外面那个var1不能用，不能用，不能用……
第四种是ejb的做法，ejb说，表闹了，你把这个包装成一个object
object EJB{//如果是java，class EJB{...
var var1;
func func1(){
var1=0;
return var1+1;
}
}
然后保证ejb container，每次只用一个线程访问这个object的instance
用java的话说就是每次只用一个线程访问这个class的object
如果有并发，给每个thread分配一个instance
这样你就可以自由滴使用那个var1鸟
嗯，很不错，但是有几个问题，一个最凸显的问题就是ejb仅限于java
而当时的java不支持lambda，而没有lambda比较难实现异步，要用反射，就很麻烦
其他语言甚至都不强行要求包装成object，所以也就无法强制实现这个代码片
那要么全换成fp，全换成fp就会出现前面说的限制，以及其他的问题
比如层层嵌套带来的金字塔
第五种就是vert.x的方式
vert.x其实就是把上面这个代码片，包装成一个verticle
然后确保这个verticle的每个instance一次只会被一个thread所执行，o啦
然后把ejb的理念灌输到verticle里面去，实现同样的目的，简化并提升效率
然后你就可以不受限制地使用func以外的变量鸟
大概是酱紫：
verticle{//这个声明不用明确写出来，对于非oop来说，一个main函数的文件就是一个
verticle
//如果是oop，则可以写多个verticles在一个文件里，比如java和ceylon
var var1;
func func1(){
var1 = 0;
return var1+1;//1，什么都没变，如果是脚本，连改都不用改
}
}
基本上啥都没变，也没有要求你注意单线程，immutable
你zip打完包插入就能用，多好
当然vert.x有着跟node.js一样的线程被blocked的问题
虽然相对好一点，因为本身就是多线程的，一个被彻底blocked了，其它还可以用
但是毕竟问题还是存在，所以引入worker，这个其实node.js也有，libuv
另外前面也说了，java以前要想做到异步，需要反射，麻烦
所以java8引入了lambda，这就使得反射的类包装不再必需，写起来就简洁了不少
同时有了rxjava，扁平化处理，这样就搞定了层层嵌套的ugly金字塔
基本上到这里问题都解决得差不多了
然后verticle间的通信可以通过msg在bus上传递
或者使用公用的map来搞掂
vert.x的bus，polyglot什么更是利器，真管用
最喜欢vert.x一点就是，什么都可以有，什么都可以拆掉
而其它的东西总是少这个少那个，然后塞给我一堆东西，各种限制，巨恶心
什么单线程，immutable
理解了这些概念的本质之后你会觉得这种设计是灰常滑稽可笑的
应该说要像单线程一样编程，但是把框架整个就做成单线程的
那就是因噎废食了，全搞成immutable更是糟糕透顶
当然你说这样做可以不可以，也许可以，我也可以这样做
但是我有更好的办法把他们做得更简单，这对于所有人都有好处
所以作为编程师，找工作时候也多了一点讨价还价的资本 |
l******t
发帖数: 55733 | |
z****e
发帖数: 54598 | 88 变量涵盖了常量
人生比较完整
【在 l******t 的大作中提到】
: 只会用“变”量的算不算缺陷啊
|
p*****2
发帖数: 21240 | 89 大牛java以外的经验还是稍微少了点
immutable其实挺好的 应该是作为缺省
【在 z****e 的大作中提到】
: 会依次对比node.js, fp, spring, ejb和vert.x的解决方案，然后自己看哪个最好
: 从最基本的说起，所有语言都一定会有两个东西
: 一个是变量，我们用var(variable)来表示
: 另外一个是方法/函数，用func(function)表示
: 假设有一个函数和一个变量
: var var1;
: func func1(){
: var1 = 0;
: return var1+1;//应该是1
: }
|
l**********n
发帖数: 8443 | 90 fp is about expressing programs in expressions, as much as possible, to
promote code reusability. in order to do that, function has to be first
class citizen. in scala, everything is object. scala has statement/
expression dichotomy. so scala is not fp.
【在 p*****2 的大作中提到】
: 大牛java以外的经验还是稍微少了点
: immutable其实挺好的 应该是作为缺省
|
|
|
l**********n
发帖数: 8443 | 91 这么说吧，当你写scala的时候，不可避免的滑向oop的深渊。scala程序员一用var就露
馅了。
【在 l**********n 的大作中提到】
: fp is about expressing programs in expressions, as much as possible, to
: promote code reusability. in order to do that, function has to be first
: class citizen. in scala, everything is object. scala has statement/
: expression dichotomy. so scala is not fp.
|
l******t
发帖数: 55733 | 92 真的可以不用var。
【在 l**********n 的大作中提到】
: 这么说吧，当你写scala的时候，不可避免的滑向oop的深渊。scala程序员一用var就露
: 馅了。
|
c*******9
发帖数: 9032 | 93 变量只适合描述只有量变没有质变的事物，这种变化往往是虚假的，是人用执着观念看
世界导致的。
【在 z****e 的大作中提到】
: 变量涵盖了常量
: 人生比较完整
|
O***b
发帖数: 104 | 94 Clojure 的 STM 解决方案跟这几种都不一样吧，把 transaction 方式加进去就比较全
了。
【在 z****e 的大作中提到】
: 会依次对比node.js, fp, spring, ejb和vert.x的解决方案，然后自己看哪个最好
: 从最基本的说起，所有语言都一定会有两个东西
: 一个是变量，我们用var(variable)来表示
: 另外一个是方法/函数，用func(function)表示
: 假设有一个函数和一个变量
: var var1;
: func func1(){
: var1 = 0;
: return var1+1;//应该是1
: }
|
j******f
发帖数: 825 | 95 Node callback很容易被误用，学会应用之后其实最容易效率也最高。api基本都有不要
自己写，并发的问题其实
是个ipc的问题，任何语言都需要解决这个问题。对于io来说node是不二选择。 |
p*****2
发帖数: 21240 | 96
支持
【在 j******f 的大作中提到】
: Node callback很容易被误用，学会应用之后其实最容易效率也最高。api基本都有不要
: 自己写，并发的问题其实
: 是个ipc的问题，任何语言都需要解决这个问题。对于io来说node是不二选择。
|
l**********n
发帖数: 8443 | 97 fp和immutubility不是一回事，fp is about function composition, currying. fp的
no side effect是说不改变外部变量。没说不能有private变量。
【在 z****e 的大作中提到】
: 会依次对比node.js, fp, spring, ejb和vert.x的解决方案，然后自己看哪个最好
: 从最基本的说起，所有语言都一定会有两个东西
: 一个是变量，我们用var(variable)来表示
: 另外一个是方法/函数，用func(function)表示
: 假设有一个函数和一个变量
: var var1;
: func func1(){
: var1 = 0;
: return var1+1;//应该是1
: }
|
p*****2
发帖数: 21240 | 98
pure fp应该没有private var吧？
【在 l**********n 的大作中提到】
: fp和immutubility不是一回事，fp is about function composition, currying. fp的
: no side effect是说不改变外部变量。没说不能有private变量。
|
l**********n
发帖数: 8443 | 99 单线程用不着immutubility
【在 p*****2 的大作中提到】
:
: pure fp应该没有private var吧？
|
c*********e
发帖数: 16335 | 100 create 一个 thread很昂贵的。为了速度快，是用multi-threading,还是用一个thread
,在这个thread里面asyn呢？据说后一种更快些。有经验的大虾说说，哪种办法更快？
哪种更好？
【在 z****e 的大作中提到】
: 会依次对比node.js, fp, spring, ejb和vert.x的解决方案，然后自己看哪个最好
: 从最基本的说起，所有语言都一定会有两个东西
: 一个是变量，我们用var(variable)来表示
: 另外一个是方法/函数，用func(function)表示
: 假设有一个函数和一个变量
: var var1;
: func func1(){
: var1 = 0;
: return var1+1;//应该是1
: }
|
|
|
p*****2
发帖数: 21240 | 101 肯定后一种了
但是multi threads也可以async
thread
？
【在 c*********e 的大作中提到】
: create 一个 thread很昂贵的。为了速度快，是用multi-threading,还是用一个thread
: ,在这个thread里面asyn呢？据说后一种更快些。有经验的大虾说说，哪种办法更快？
: 哪种更好？
|
c*********e
发帖数: 16335 | 102 既然一个thread里面async更快，为什么会用multi-threading呢？
【在 p*****2 的大作中提到】
: 肯定后一种了
: 但是multi threads也可以async
:
: thread
: ？
|
p*****2
发帖数: 21240 | 103 可以更好利用multi core
【在 c*********e 的大作中提到】
: 既然一个thread里面async更快，为什么会用multi-threading呢？
|
c*********e
发帖数: 16335 | 104 你的意思是，只有一个cpu的时候，single thread + async 比 multi-threading 更好？
【在 p*****2 的大作中提到】
: 可以更好利用multi core
|
b*******s
发帖数: 5216 | |
o**2
发帖数: 168 | 106 帮顶一下
【在 z****e 的大作中提到】
: 会依次对比node.js, fp, spring, ejb和vert.x的解决方案，然后自己看哪个最好
: 从最基本的说起，所有语言都一定会有两个东西
: 一个是变量，我们用var(variable)来表示
: 另外一个是方法/函数，用func(function)表示
: 假设有一个函数和一个变量
: var var1;
: func func1(){
: var1 = 0;
: return var1+1;//应该是1
: }
|
d****e
发帖数: 839 | 107 没看懂，LZ是要把变量当local的用，那为什么要把它定义为global的？如果要当
global的用，在多线程下，难道不应该用mutex之类的把它保护起来吗？我是写C/C++的
，可能没完全搞懂LZ的意图。 |
b*******s
发帖数: 5216 | 108 he only knows something very basic about concurrency
【在 d****e 的大作中提到】
: 没看懂，LZ是要把变量当local的用，那为什么要把它定义为global的？如果要当
: global的用，在多线程下，难道不应该用mutex之类的把它保护起来吗？我是写C/C++的
: ，可能没完全搞懂LZ的意图。
|
g*****g
发帖数: 34805 | 109 他就是举个大家容易理解的例子，这里转行的太多。spring, ejb都是很规范的框架，
什么东西怎么写都是有无数范例的。写错了code review绝对过不了。
【在 d****e 的大作中提到】
: 没看懂，LZ是要把变量当local的用，那为什么要把它定义为global的？如果要当
: global的用，在多线程下，难道不应该用mutex之类的把它保护起来吗？我是写C/C++的
: ，可能没完全搞懂LZ的意图。
|
p*****2
发帖数: 21240 | 110
好？
是。
【在 c*********e 的大作中提到】
: 你的意思是，只有一个cpu的时候，single thread + async 比 multi-threading 更好？
|
|
|
z****e
发帖数: 54598 | 111 多线程直接上框架，还写啥呀
没事找事，只有很少情况才会不得不去处理多线程的并发
【在 d****e 的大作中提到】
: 没看懂，LZ是要把变量当local的用，那为什么要把它定义为global的？如果要当
: global的用，在多线程下，难道不应该用mutex之类的把它保护起来吗？我是写C/C++的
: ，可能没完全搞懂LZ的意图。
|
z****e
发帖数: 54598 | 112 这个不重要，get things done最重要
其它都是次要的，太过于理论抽象的东西，不应该在语言层面enforce
抽象成数学命题比较合适，hand over给物理等专业去讨论
【在 c*******9 的大作中提到】
: 变量只适合描述只有量变没有质变的事物，这种变化往往是虚假的，是人用执着观念看
: 世界导致的。
|
z****e
发帖数: 54598 | 113 fp涵盖了var
只是不推荐使用var
否则会在并发的时候用上大量的lock
会让你的程序变得难以维护
这一点上说，无论什么多线程的框架
其本意都是为了让用户不再使用lock
像单线程一样编程是目的
这个其实无论啥都是一样的
但是实现的手段截然不同，而且效果也很明显有差异
【在 l**********n 的大作中提到】
: 这么说吧，当你写scala的时候，不可避免的滑向oop的深渊。scala程序员一用var就露
: 馅了。
|
z****e
发帖数: 54598 | 114 transaction如果展开的话，还有额外一堆的讨论
其实就是lock，上面说的至少在用户层面都是lock free滴
需要lock的话，那就太原始了，因为本身很难以维护
最终不会变简单，会变得很痛苦，上面说的只是用户层面的东西
就不涉及具体的框架怎么实现，其中当然有可能用到lock和transaction这些
但是那种一般用不到，就跟楼上那个c/c++说的差不多
【在 O***b 的大作中提到】
: Clojure 的 STM 解决方案跟这几种都不一样吧，把 transaction 方式加进去就比较全
: 了。
|
z****e
发帖数: 54598 | 115 是被滥用
你还是木有尝试vert.x
我不跟你argue，因为你缺少vert.x实际动手经验
等你试过之后再说，看看vert.x是怎么解决callback hell的
当然这你需要看rxjava，小马过河，你与其在这里为node做广告
不如自己动手试试看，vert.x从node那边抄袭了很多东西
好不好，我说了不算，你说了也不算，试过的人自己会有判断
【在 j******f 的大作中提到】
: Node callback很容易被误用，学会应用之后其实最容易效率也最高。api基本都有不要
: 自己写，并发的问题其实
: 是个ipc的问题，任何语言都需要解决这个问题。对于io来说node是不二选择。
|
z****e
发帖数: 54598 | 116 什么年代的事了
那是90年代create一个object很消耗内存啥的
现在，一s给我10^4方个对象，你觉得慢吗？
后来主要问题是gc会有停顿，所以主要是通过pool来解决这个问题
thread
？
【在 c*********e 的大作中提到】
: create 一个 thread很昂贵的。为了速度快，是用multi-threading,还是用一个thread
: ,在这个thread里面asyn呢？据说后一种更快些。有经验的大虾说说，哪种办法更快？
: 哪种更好？
|
z****e
发帖数: 54598 | 117 不错
只有1st class func需要immu来配合
否则很容易escape
【在 l**********n 的大作中提到】
: 单线程用不着immutubility
|
z****e
发帖数: 54598 | 118 是不是一回事，currying跟immutable也不是一回事
把fp拆成个体之后，有选择性吸收，这里说的是如何用这些多线程的框架
fp都是1st class citizen，你当然不能随便改变外部变量
否则全局变量被修改，side effect大了，一堆人骂娘
private是object的概念，func private啥，local var吧
【在 l**********n 的大作中提到】
: fp和immutubility不是一回事，fp is about function composition, currying. fp的
: no side effect是说不改变外部变量。没说不能有private变量。
|
z****e
发帖数: 54598 | 119 which is vert.x
【在 p*****2 的大作中提到】
: 肯定后一种了
: 但是multi threads也可以async
:
: thread
: ？
|
z****e
发帖数: 54598 | 120 另外，只有node才需要ipc
其它框架都是itc
这就是为啥node很傻逼
像单线程一样编程是目的
但是你真把所有东西都做成单线程的话
那个thread挂了咋办捏？
哪怕是一个不小心，被阿三程序员写段代码blocked了
你不一样很苦逼？
当然这个问题哪怕是弄成itc一样存在
但是至少至少，其它启动的threads会在一定程度上抵消这个问题
我猜测这就是为啥在大多数报告里面，node总是会有丢包的问题
可能就是那个线程出了问题，把所有鸡蛋全部放在一个篮子里
自然会出问题，vert.x说，我按照cpu有多少个core来建threads
一个dual core的cpu，vert.x就启两个threads，如果是两个这种cpus
就起2*2=4个threads，这样万一其中一个thread被blocked，一样不会挂，对不对？
当然blocked在异步编程中是错误的，而且同一个process下处理communication
比起多个processes下处理，那是要强太多了，不同process之间做c，那很苦逼的好不好
得调用第三方工具，各种狗血问题，所以你还是用node的思维来看其他多线程框架
被node给局限了，哪怕你看看fp也好，看看akka和play
【在 j******f 的大作中提到】
: Node callback很容易被误用，学会应用之后其实最容易效率也最高。api基本都有不要
: 自己写，并发的问题其实
: 是个ipc的问题，任何语言都需要解决这个问题。对于io来说node是不二选择。
|
|
|
z****e
发帖数: 54598 | 121 你写游戏就会用了
对var不感兴趣的人对世界缺乏探索精神
常量真滴很无趣，死的东西
var才是活物，人就是一个var
表被fp教徒给骗了，fp说变量不需要是谎言
凡事过犹不及
【在 l******t 的大作中提到】
: 真的可以不用var。
|
z****e
发帖数: 54598 | 122 比起你自己动手去用各种lock，那是要强太多
但是比起其他多线程的框架来说，比如fp那种
就未必了，其实本质没啥大不了的
无非就是隔离嘛，mutable的var容易导致冲突
那如何解决，就是这些框架要解决的问题
解决手段有很多，最终实现的程度也不一样
显然vert.x最爽，你不需要成天惦记着什么single thread, immutable这些东西
当然synchronized这些就更不需要了，vert.x下我可以肆无忌惮滴重用代码
只需要记住一个basic rule，任何时候，一个verticle只会被一个thread所访问，o啦
剩下的是vert.x的事，其他的都做不到，要你记这个要你记那个，烦死
嗯，ejb勉强可以，但是繁琐了点，要配置，当然vert.x也不是完美的
还是需要自己对付异步问题，虽然比起node已经好很多了
那现在不就是一堆人涌过去解决这个问题嘛
把以前老的同步api全部弄成异步的，当然rxjava解决的callback金字塔也是一个成果
好？
【在 c*********e 的大作中提到】
: 你的意思是，只有一个cpu的时候，single thread + async 比 multi-threading 更好？
|
p*****2
发帖数: 21240 | 123 我觉得vert.x主要是成熟度的问题
node确实有局限性 但是做web基本也够用了
【在 z****e 的大作中提到】
: 另外，只有node才需要ipc
: 其它框架都是itc
: 这就是为啥node很傻逼
: 像单线程一样编程是目的
: 但是你真把所有东西都做成单线程的话
: 那个thread挂了咋办捏？
: 哪怕是一个不小心，被阿三程序员写段代码blocked了
: 你不一样很苦逼？
: 当然这个问题哪怕是弄成itc一样存在
: 但是至少至少，其它启动的threads会在一定程度上抵消这个问题
|
p*****2
发帖数: 21240 | 124 fp涵盖var是什么意思？
【在 z****e 的大作中提到】
: fp涵盖了var
: 只是不推荐使用var
: 否则会在并发的时候用上大量的lock
: 会让你的程序变得难以维护
: 这一点上说，无论什么多线程的框架
: 其本意都是为了让用户不再使用lock
: 像单线程一样编程是目的
: 这个其实无论啥都是一样的
: 但是实现的手段截然不同，而且效果也很明显有差异
|
j******f
发帖数: 825 | 125 解决了IPC问题，NODE就解决了多机并发问题，也解决了一个线程挂掉的问题。
而对于其他语言，首先要解决IPC的问题，然后还要解决ITC问题，然后还要面临一大堆
concurrency问题。
对于IO来说，NODE的速度秒杀其他synchronous语言。
【在 z****e 的大作中提到】
: 另外，只有node才需要ipc
: 其它框架都是itc
: 这就是为啥node很傻逼
: 像单线程一样编程是目的
: 但是你真把所有东西都做成单线程的话
: 那个thread挂了咋办捏？
: 哪怕是一个不小心，被阿三程序员写段代码blocked了
: 你不一样很苦逼？
: 当然这个问题哪怕是弄成itc一样存在
: 但是至少至少，其它启动的threads会在一定程度上抵消这个问题
|
j******f
发帖数: 825 | 126 vert.x我在几年以前看过，主要问题我不喜欢heavy的框架, 还有它很难scale。
callback不难解决，eventemitter + queue 即可。
【在 z****e 的大作中提到】
: 是被滥用
: 你还是木有尝试vert.x
: 我不跟你argue，因为你缺少vert.x实际动手经验
: 等你试过之后再说，看看vert.x是怎么解决callback hell的
: 当然这你需要看rxjava，小马过河，你与其在这里为node做广告
: 不如自己动手试试看，vert.x从node那边抄袭了很多东西
: 好不好，我说了不算，你说了也不算，试过的人自己会有判断
|
z****e
发帖数: 54598 | 127 vert.x heavy在哪里？总共就10多m的一个东西
为啥很难scale？
只要做到stateless，scale都很容易，几乎都是线性scale
哪怕ejb都可以很容易做到线性scale
vert.x天生就是stateless的东西
所谓scale难都是一些无聊的人为了吹嘘自己的本领而编造出来的
做过以后就不以为然的
【在 j******f 的大作中提到】
: vert.x我在几年以前看过，主要问题我不喜欢heavy的框架, 还有它很难scale。
: callback不难解决，eventemitter + queue 即可。
|
z****e
发帖数: 54598 | 128 其他框架根本不需要多process，去哪里来的ipc问题？
node的ipc放在其他框架就是itc，而且vert.x天生就有一个bus予以解决
node还要自己倒腾第三方工具予以解决，只有node需要倒腾第三方工具解决并发问题
其他都不用，哪怕是akka都是自己搞定，所谓ipc就是一个集成的问题
单机系统还需要集成的只有单线程，其他都不用，自己能搞定
这个完全是一个名词上的混淆，根本不是什么优势，是大大滴劣势
至于io快，纯粹胡说八道，vert.x vs node.js的报告到处都是
自己试试就知道node有多烂了，你还是没试过，凭想象来指责其他框架的问题
【在 j******f 的大作中提到】
: 解决了IPC问题，NODE就解决了多机并发问题，也解决了一个线程挂掉的问题。
: 而对于其他语言，首先要解决IPC的问题，然后还要解决ITC问题，然后还要面临一大堆
: concurrency问题。
: 对于IO来说，NODE的速度秒杀其他synchronous语言。
|
z****e
发帖数: 54598 | 129 0.x的版本都敢用，连丢包都不在乎，内存上1g都出问题，都敢下放生产
vert.x比起来，要nice太多，node不稳定早就有人说过了
做hello world的确是够用，php都够，这些说法深入了解之后都觉得是人想象出来的东西
总有人坚持自己的想象
【在 p*****2 的大作中提到】
: 我觉得vert.x主要是成熟度的问题
: node确实有局限性 但是做web基本也够用了
|
z****e
发帖数: 54598 | 130 应该说fp不反对var
反对var是为了多线程编造出来的谎言
因为pure fp解决不了多线程带来的var冲突
所以只好immutable鸟
这完全没有必要，就跟单线程一样
纯粹浪费
【在 p*****2 的大作中提到】
: fp涵盖var是什么意思？
|
|
|
p*****2
发帖数: 21240 | 131 貌似你理解还不太够
纯fp应该是没有var的 是state monad
【在 z****e 的大作中提到】
: 应该说fp不反对var
: 反对var是为了多线程编造出来的谎言
: 因为pure fp解决不了多线程带来的var冲突
: 所以只好immutable鸟
: 这完全没有必要，就跟单线程一样
: 纯粹浪费
|
j******f
发帖数: 825 | 132 要说scale很容易，我只能说你没碰过复杂的情况。
【在 z****e 的大作中提到】
: vert.x heavy在哪里？总共就10多m的一个东西
: 为啥很难scale？
: 只要做到stateless，scale都很容易，几乎都是线性scale
: 哪怕ejb都可以很容易做到线性scale
: vert.x天生就是stateless的东西
: 所谓scale难都是一些无聊的人为了吹嘘自己的本领而编造出来的
: 做过以后就不以为然的
|
z****e
发帖数: 54598 | 133 我没说很容易
如果用node就不那么容易，尤其是当process多了之后
就很恶心
用vert.x就相对简单，因为这种情况在预料之中，有现成的文档予以解决
而且不同情况不一样
有些场景比如游戏就很难
但是大多数尤其是web，就相对简单很多
node在单机上的多process都需要第三方软件介入
这是非常滑稽可笑的，就是对这些东西了解了之后
才会觉得它烂，而不是像宗教一样，除了说好和坏以外，连一个合理的理由都说不出来
估计你没搞过其他的框架，我怀疑你甚至连vert.x可以直接用js都不知道
当然灌水嘛，不用太认真
【在 j******f 的大作中提到】
: 要说scale很容易，我只能说你没碰过复杂的情况。
|
z****e
发帖数: 54598 | 134 纯粹的fp没有意义
【在 p*****2 的大作中提到】
: 貌似你理解还不太够
: 纯fp应该是没有var的 是state monad
|
j******f
发帖数: 825 | 135 用框架还是自己搭，看你喜好。我是能自己做就不要用框架。自己做代码小，自由效率
高。用框架可能容易点，但受限制。请问你用node做是不是搞砸了所以如此痛恨它
【在 z****e 的大作中提到】
: 我没说很容易
: 如果用node就不那么容易，尤其是当process多了之后
: 就很恶心
: 用vert.x就相对简单，因为这种情况在预料之中，有现成的文档予以解决
: 而且不同情况不一样
: 有些场景比如游戏就很难
: 但是大多数尤其是web，就相对简单很多
: node在单机上的多process都需要第三方软件介入
: 这是非常滑稽可笑的，就是对这些东西了解了之后
: 才会觉得它烂，而不是像宗教一样，除了说好和坏以外，连一个合理的理由都说不出来
|
z****e
发帖数: 54598 | 136 你搞错了吧
node才是最大的限制
单线程怎么做都是束手束脚的
vertx的限制是最少的
我没搞砸，两个我都看明白了
所以才会告诉你单线程sucks
而你根本没看懂vert.x在做啥
【在 j******f 的大作中提到】
: 用框架还是自己搭，看你喜好。我是能自己做就不要用框架。自己做代码小，自由效率
: 高。用框架可能容易点，但受限制。请问你用node做是不是搞砸了所以如此痛恨它
|
z****e
发帖数: 54598 | 137
另外，什么自己做代码小，自由效率高
这句话我给你换个说法
你其他的东西没做过
看来我猜对了
【在 j******f 的大作中提到】
: 用框架还是自己搭，看你喜好。我是能自己做就不要用框架。自己做代码小，自由效率
: 高。用框架可能容易点，但受限制。请问你用node做是不是搞砸了所以如此痛恨它
|
j******f
发帖数: 825 | 138 要意淫你随便，另外要回复想好再说省得我还得回两个帖子，看来你连修改帖子功能都
不会。
【在 z****e 的大作中提到】
:
: 另外，什么自己做代码小，自由效率高
: 这句话我给你换个说法
: 你其他的东西没做过
: 看来我猜对了
|
z****e
发帖数: 54598 | 139 lol
不用羞恼成怒
你有没有经验，是骗不了人的，这点应该整个行业都是共识
面试多面几次就知道了，你是懂还是不懂，装是没有用的
撒谎最麻烦的一点就是要不停滴编造更多谎言，去掩饰你不知道的真相
我直接回帖多方便，为什么要修改啊？
还要额外点回去
【在 j******f 的大作中提到】
: 要意淫你随便，另外要回复想好再说省得我还得回两个帖子，看来你连修改帖子功能都
: 不会。
|
j******f
发帖数: 825 | 140 看看你回的每个帖子就是不停的说别人不懂你懂，你懂的话node都搞不明白，让人笑掉
大牙。
还需要面试吗，不管你懂不懂，你已经没面试机会了。
【在 z****e 的大作中提到】
: lol
: 不用羞恼成怒
: 你有没有经验，是骗不了人的，这点应该整个行业都是共识
: 面试多面几次就知道了，你是懂还是不懂，装是没有用的
: 撒谎最麻烦的一点就是要不停滴编造更多谎言，去掩饰你不知道的真相
: 我直接回帖多方便，为什么要修改啊？
: 还要额外点回去
|
|
|
z****e
发帖数: 54598 | 141 lol
这里说的是你不懂vert.x的结构
你自己不都承认了吗？
还狡辩社么？
【在 j******f 的大作中提到】
: 看看你回的每个帖子就是不停的说别人不懂你懂，你懂的话node都搞不明白，让人笑掉
: 大牙。
: 还需要面试吗，不管你懂不懂，你已经没面试机会了。
|
j******f
发帖数: 825 | 142 说的是你不懂node，你自己说搞不定的。
vert.x用js我都要笑弯腰了，你用js不用node，绕了一大圈去通过vert.x来用js？恰恰
证明你根本不懂node，需要用vert.x来帮助你解决你的问题。
其实用vert.x没什么，没啥不好意识的，水平差点借助一下vert.x也没啥，别想太多，
只要能干活啥都行。
【在 z****e 的大作中提到】
: lol
: 这里说的是你不懂vert.x的结构
: 你自己不都承认了吗？
: 还狡辩社么？
|
z****e
发帖数: 54598 | 143 搞得定啊
问题是太麻烦啊
显然process是一个更为恶心的存在
对比thread来说
我们说的是你没有用过
你说你用过，还记得吗？
还“研究”过，就在这一页的最上面
一看那句话就是胡扯蛋，显然是你以为只有你那种方式才搞得定
事实是，你那种方式是非常糟糕的，其他方式你一概不知道
你才会做出那种判断，所以我就给你设了个套
刺激你一下，看看你是不是真的知道
看下去，果然是不知道，无意之中说漏了嘴
难道不是吗？
你个骗子
【在 j******f 的大作中提到】
: 说的是你不懂node，你自己说搞不定的。
: vert.x用js我都要笑弯腰了，你用js不用node，绕了一大圈去通过vert.x来用js？恰恰
: 证明你根本不懂node，需要用vert.x来帮助你解决你的问题。
: 其实用vert.x没什么，没啥不好意识的，水平差点借助一下vert.x也没啥，别想太多，
: 只要能干活啥都行。
|
z****e
发帖数: 54598 | 144 你知道vert.x才多大吗？
还几年前，哈哈
我都懒得说你，别装了同学
【在 j******f 的大作中提到】
: 说的是你不懂node，你自己说搞不定的。
: vert.x用js我都要笑弯腰了，你用js不用node，绕了一大圈去通过vert.x来用js？恰恰
: 证明你根本不懂node，需要用vert.x来帮助你解决你的问题。
: 其实用vert.x没什么，没啥不好意识的，水平差点借助一下vert.x也没啥，别想太多，
: 只要能干活啥都行。
|
j******f
发帖数: 825 | 145 搞得定但是太麻烦？ 还是搞不定。
【在 z****e 的大作中提到】
: 搞得定啊
: 问题是太麻烦啊
: 显然process是一个更为恶心的存在
: 对比thread来说
: 我们说的是你没有用过
: 你说你用过，还记得吗？
: 还“研究”过，就在这一页的最上面
: 一看那句话就是胡扯蛋，显然是你以为只有你那种方式才搞得定
: 事实是，你那种方式是非常糟糕的，其他方式你一概不知道
: 你才会做出那种判断，所以我就给你设了个套
|
z****e
发帖数: 54598 | 146 太麻烦是觉得恶心
就像我不会走路去北京一样
这叫太麻烦，而你一说出来你会自己造轮子我就笑了
你就忽悠吧，多process一样会动用其他轮子，哪怕你用的是node
你造个p轮子，你就骗吧
【在 j******f 的大作中提到】
: 搞得定但是太麻烦？ 还是搞不定。
|
j******f
发帖数: 825 | 147 行了你就用vert.x吧，够你用的了，挺好
【在 z****e 的大作中提到】
: 太麻烦是觉得恶心
: 就像我不会走路去北京一样
: 这叫太麻烦，而你一说出来你会自己造轮子我就笑了
: 你就忽悠吧，多process一样会动用其他轮子，哪怕你用的是node
: 你造个p轮子，你就骗吧
|
z****e
发帖数: 54598 | 148 基本上这个版面敢说自己是造轮子的
都可以归为骗子一类
深入问下去，多数都会有马脚
这个世界上不是没有造轮子的
但是写个hello world就出来忽悠自己是造轮子的
那还是很多的
【在 j******f 的大作中提到】
: 搞得定但是太麻烦？ 还是搞不定。
|
z****e
发帖数: 54598 | 149 lol
你自己查查几年前vert.x还在什么状态吧
骗子的马脚很容易露出
只要稍微了解一点历史
你就是一个骗子～！
【在 j******f 的大作中提到】
: 行了你就用vert.x吧，够你用的了，挺好
|
j******f
发帖数: 825 | 150 我也就能骗你，骗不了别人
【在 z****e 的大作中提到】
: lol
: 你自己查查几年前vert.x还在什么状态吧
: 骗子的马脚很容易露出
: 只要稍微了解一点历史
: 你就是一个骗子～！
|
|
|
z****e
发帖数: 54598 | 151 lol
不用满地打滚了
骗子你好
【在 j******f 的大作中提到】
: 我也就能骗你，骗不了别人
|
p*****2
发帖数: 21240 | 152 为什么node scale不容易
为什么需要第三方呀
【在 z****e 的大作中提到】
: 我没说很容易
: 如果用node就不那么容易，尤其是当process多了之后
: 就很恶心
: 用vert.x就相对简单，因为这种情况在预料之中，有现成的文档予以解决
: 而且不同情况不一样
: 有些场景比如游戏就很难
: 但是大多数尤其是web，就相对简单很多
: node在单机上的多process都需要第三方软件介入
: 这是非常滑稽可笑的，就是对这些东西了解了之后
: 才会觉得它烂，而不是像宗教一样，除了说好和坏以外，连一个合理的理由都说不出来
|
z****e
发帖数: 54598 | 153 相对不容易
其实总体而言都很容易
但是有骗子说vert.x scale会有问题嘛
这个一看就是胡扯蛋，那既然要比较难易度
那显然是vert.x容易scale啊
最简单的，我把cpu从一个core弄成多个cores，vert.x不用做任何修改
全部自动搞定，node就需要自己弄了
而且同样能够handle async的情况，前面我说js能够直接用在vert.x上就是告诉某些骗子
async其实跟语言无关，甚至跟运行环境都没有太大关系
换个语言一样用async，哪怕是python, ruby都可以做到
甚至perl，可惜骗子领悟能力太低，看不懂
其实immutable跟语言本身也是无关的
把context看完整
【在 p*****2 的大作中提到】
: 为什么node scale不容易
: 为什么需要第三方呀
|
z****e
发帖数: 54598 | 154 需要第三方因为捆绑一个process只有一个thread
这个显然是错误的，具体例子可以看这个
http://blog.carbonfive.com/2014/02/28/taking-advantage-of-multi
只是一个idea，很明显，放弃多线程并不是一个明智的选择
显然应该想办法对付多线程，而不是直接上多进程
当然跟immutable一样，问能不能这样搞，可以
但是这样搞不够聪明，不够好，就这么简单
不像是一个solution，更像是一个回避，相比之下，其它框架都是通过threads来搞定
很优雅啊，也没有导致其他问题产生
一般只有多个虚拟机结点出现的时候才会用cluster
但是node在多个core时候就会启动这个模式，甚至load balancing, 这真是wtf啊
这个显然是错误的，本来应该是itc的问题变成了ipc
这个太奇芭了，其他框架都不需要这么做
当你有多个虚拟机nodes时候才需要用cluster
其他框架在cpu的更换的时候都不需要怎么弄，全自动的
唯独node要自己写代码予以配合
这是不是很奇芭？搞cluster等于是把框架应该解决的问题丢给了用户去解决
这框架太不负责了，换句话说，node也能叫做多线程框架？不行吧
一旦丢给了用户，用户又会面对着一样的问题，那就是资源的争抢
lock等以前在多线程中遇到的问题，因为压根node就没解决嘛
【在 p*****2 的大作中提到】
: 为什么node scale不容易
: 为什么需要第三方呀
|
z****e
发帖数: 54598 | 155 btw，我机器上启动一个process要30ms,而启动一个thread只要不到1ms,平均只有.1ms,
process带来的overhead实在是太高了，300倍的差距，而几乎所有的worker无论node
还是vert都需要额外启动process/thread,30ms实在是太慢了！足够我10g的内存做20次
左右的大gc了，小gc就更多了，有兴趣的自己在电脑上试试，你好容易用异步省下来的
时间就都被process的包装给消耗掉了 |
z****e
发帖数: 54598 | 156 用多线程搞异步，就是用ejb方式折腾worker都可以，完全可以对每一个worker实例单
独启
动一个thread, 但是如果是process, 就没戏了，很容易就出问题了 |
p*****2
发帖数: 21240 | 157 vert.x async 库不全吧？所以不能做到完全async。
骗子
【在 z****e 的大作中提到】
: 相对不容易
: 其实总体而言都很容易
: 但是有骗子说vert.x scale会有问题嘛
: 这个一看就是胡扯蛋，那既然要比较难易度
: 那显然是vert.x容易scale啊
: 最简单的，我把cpu从一个core弄成多个cores，vert.x不用做任何修改
: 全部自动搞定，node就需要自己弄了
: 而且同样能够handle async的情况，前面我说js能够直接用在vert.x上就是告诉某些骗子
: async其实跟语言无关，甚至跟运行环境都没有太大关系
: 换个语言一样用async，哪怕是python, ruby都可以做到
|
p*****2
发帖数: 21240 | 158 你去看看python ruby怎么搞的
node跟java比本来意思就不大
web这块动态语言比较有优势
1ms,
node
【在 z****e 的大作中提到】
: btw，我机器上启动一个process要30ms,而启动一个thread只要不到1ms,平均只有.1ms,
: process带来的overhead实在是太高了，300倍的差距，而几乎所有的worker无论node
: 还是vert都需要额外启动process/thread,30ms实在是太慢了！足够我10g的内存做20次
: 左右的大gc了，小gc就更多了，有兴趣的自己在电脑上试试，你好容易用异步省下来的
: 时间就都被process的包装给消耗掉了
|
j******f
发帖数: 825 | 159 现在比速度都拿node比，都想证明比node快，这本身就证明了node在IO上的巨大优势，
已经成为标杆了。 |
o**2
发帖数: 168 | 160 我也算版面上的了吧，你这样说，我没法不对号入座啊，我可是号称做programming
paradigm的，比做轮子可严重多了，嘿嘿
【在 z****e 的大作中提到】
: 基本上这个版面敢说自己是造轮子的
: 都可以归为骗子一类
: 深入问下去，多数都会有马脚
: 这个世界上不是没有造轮子的
: 但是写个hello world就出来忽悠自己是造轮子的
: 那还是很多的
|
|
|
z****e
发帖数: 54598 | 161 async还要库？
只要有lambda，什么都可以轻易做到async
为什么要库？
即便没有lambda，reflection也同样可以做到完全的async
话说async完全不完全其实就是看你有没有block thread
只要你能让你的组件不block thread，你就能做到完全的async
而且对于多线程来说，一个最最最简单的做到async的方法
就是对于某些特别耗时的step，额外启动独立的线程就好了
所谓worker只是增加了callback func进去而已
如果不需要callback的话，直接new thread().start()，搞定
这个就是最简单的async
【在 p*****2 的大作中提到】
: vert.x async 库不全吧？所以不能做到完全async。
:
: 骗子
|
z****e
发帖数: 54598 | 162 动态类型无法真正启用ide的优势
所以swift和dart都已经抛弃了动态类型
把静态类型作为首选，动态类型维护起来是一个巨大的烦恼
很容易都不知道别人在干嘛
async不需要啥整，压根不是js所独有的
本来node就是抄袭eventmachine这些设计的prototype
【在 p*****2 的大作中提到】
: 你去看看python ruby怎么搞的
: node跟java比本来意思就不大
: web这块动态语言比较有优势
:
: 1ms,
: node
|
z****e
发帖数: 54598 | 163 io优势你说的是async吧
你根本没弄明白async到底啥意思吧？
node本身就是抄袭eventmachine的产物这个知道吗？
node慢又不是什么新闻，随便找个benchmark都可以告诉你结果
https://www.techempower.com/benchmarks/
无数人贴过很多遍的东西了
异步本身可以带来效率上的提升，但是这个跟node没半毛钱关系
也只有你这种半吊子才会以为这个东西是某个语言独有的
丢人现眼
【在 j******f 的大作中提到】
: 现在比速度都拿node比，都想证明比node快，这本身就证明了node在IO上的巨大优势，
: 已经成为标杆了。
|
z****e
发帖数: 54598 | 164 nah
是否是真的做轮子的，看产品就知道了
半海说他有一个开源的project，它跑出来说我是做轮子的，我信
你也有产品，你说你是做轮子的，我也信
真正做轮子的人，不需要把做轮子挂嘴边
直接说产品就好了，你有自己的产品，所以说的都是具体的产品
而非什么做轮子这么general的说法，而且产品本身是竞争的
说这么general的话，会给竞争对手以机会，所以一般都不会说什么轮子
就直接告诉你，我是做a项目的，比如我是做vert.x的
我不会说我是做轮子的，因为这没有意义，所以上来就说自己是造轮子的
不是没有经验，就是纯粹忽悠
【在 o**2 的大作中提到】
: 我也算版面上的了吧，你这样说，我没法不对号入座啊，我可是号称做programming
: paradigm的，比做轮子可严重多了，嘿嘿
|
j******f
发帖数: 825 | 165 靠你抄袭了我那么多还好意识在这喷？
【在 z****e 的大作中提到】
: io优势你说的是async吧
: 你根本没弄明白async到底啥意思吧？
: node本身就是抄袭eventmachine的产物这个知道吗？
: node慢又不是什么新闻，随便找个benchmark都可以告诉你结果
: https://www.techempower.com/benchmarks/
: 无数人贴过很多遍的东西了
: 异步本身可以带来效率上的提升，但是这个跟node没半毛钱关系
: 也只有你这种半吊子才会以为这个东西是某个语言独有的
: 丢人现眼
|
z****e
发帖数: 54598 | 166 瞎扯，谁抄谁啊？
node抄了eventmachine，就不允许别人用了？
【在 j******f 的大作中提到】
: 靠你抄袭了我那么多还好意识在这喷？
|
p*****2
发帖数: 21240 | 167
你的理解真的是有问题了。我建议你好好学学Node，就知道Node的强大了。
【在 z****e 的大作中提到】
: async还要库？
: 只要有lambda，什么都可以轻易做到async
: 为什么要库？
: 即便没有lambda，reflection也同样可以做到完全的async
: 话说async完全不完全其实就是看你有没有block thread
: 只要你能让你的组件不block thread，你就能做到完全的async
: 而且对于多线程来说，一个最最最简单的做到async的方法
: 就是对于某些特别耗时的step，额外启动独立的线程就好了
: 所谓worker只是增加了callback func进去而已
: 如果不需要callback的话，直接new thread().start()，搞定
|
z****e
发帖数: 54598 | 168 我知道node怎么搞的呀
问题是node无法像vert一样自由创造threads
这个就是一大限制
只要保证threads之间独立，异步很容易搞
有了lambda该有的就都有了，完全不需要屈从worker其实
自己写也就是分分钟的事
【在 p*****2 的大作中提到】
:
: 你的理解真的是有问题了。我建议你好好学学Node，就知道Node的强大了。
|
p*****2
发帖数: 21240 | 169
异步跟thread没啥关系，其实。
【在 z****e 的大作中提到】
: 我知道node怎么搞的呀
: 问题是node无法像vert一样自由创造threads
: 这个就是一大限制
: 只要保证threads之间独立，异步很容易搞
: 有了lambda该有的就都有了，完全不需要屈从worker其实
: 自己写也就是分分钟的事
|
z****e
发帖数: 54598 | 170 因为node只考虑一个thread，所以造成了这种误解
当多个threads出现之后，哪怕是worker出现了之后
thread就卷进来了，因为node没办法自行启动thread
所以这种解决方案永远都不会出现在node里面
其实vert.x就是把node用process做的全部改成用thread完成
以节省资源，就这么简单
而且因为具体一个thread本身占用资源很少
所以很多时候我可以很随意地使用thread，但是如果是process
那就没办法了，稍微多一点就会出问题，我laptop上chrome最喜欢乱起process
【在 p*****2 的大作中提到】
:
: 异步跟thread没啥关系，其实。
|
|
|
q*c
发帖数: 9453 | 171 现在有 fiber, 可是起上百万的 fiber, 而且还是 sync 的， 容易读。
async 就不是人脑的思维方式， 人脑适合顺序线性。 哪怕各种 async 叫的再欢， 你
看 future 等技术， coffee script..等等 还是往object oriented, 顺序线性执行上
靠。
人的嘴是最无聊的东西， 你要看他们做什么， 而不是说什么，
好？
【在 c*********e 的大作中提到】
: 你的意思是，只有一个cpu的时候，single thread + async 比 multi-threading 更好？
|
z****e
发帖数: 54598 | 172 嗯，最后还是都回到oo上去
哪怕是fp的，也都给写得像oo的有前途
【在 q*c 的大作中提到】
: 现在有 fiber, 可是起上百万的 fiber, 而且还是 sync 的， 容易读。
: async 就不是人脑的思维方式， 人脑适合顺序线性。 哪怕各种 async 叫的再欢， 你
: 看 future 等技术， coffee script..等等 还是往object oriented, 顺序线性执行上
: 靠。
: 人的嘴是最无聊的东西， 你要看他们做什么， 而不是说什么，
:
: 好？
|
