z****e
发帖数: 54598 | 1 就是vertx-sync
就是利用fiber构建一个轻量级的thread
which并不一一对应kernal thread
简单说，如果你block了fiber
并不会导致os的thread被blocked
通过这种方式，你就可以丢掉promise, rxjava以及更为糟糕的callback了
直接用你最熟悉的sync的方式编写异步代码
唯一的改变就是你把Future改成Message
然后随便用.get, .body，会block fiber但是没有关系，不会阻塞thread
类似goroutine，vert.x依赖的这个类似go的项目名字叫做quasar
http://docs.paralleluniverse.co/quasar/
然后vert.x就把quasar的api用它自己的api包装起来
就类似vert.x把akka的actor给抄了过来，然后用相对简单的api包装起来一样
3.1发布之前，对于这个需求的呼声相当高，这是链接
http://github.com/vert-x3/vertx-sync/blob/master/src/main/ascii
效率对比，quasar做了一个跟go还有erlang的简单对比，13年有一个blog
http://blog.paralleluniverse.co/2013/05/02/quasar-pulsar/
举个简单例子，比如这个
Future reply = awaitResult(h -> eb.send("someaddress", "ping", h));
System.out.println("Received reply " + reply.body());
到第二步，system.out的时候，会block当前thread
所以不适合把这段代码放到verticle中去，因为会把event loop给blocked
但是如果你换成了Message which使用了 fiber，代码就变成了这样
Message reply = awaitResult(h -> eb.send("someaddress", "ping", h));
System.out.println("Received reply " + reply.body());
就不会block thread，但是代码依旧会按照顺序执行，先执行完成第一步之后，再执行
第二步
实际上就是一个cb，只不过被放到了api level中去，对用户来说是透明的
因为不会block thread，所以尽管放到verticle中去运行，没有关系
不会block eventloop，写起来就简单很多
当然你还是可以用cb，promise，rx这些
从这点上看，异步就快白菜了，作为第一生产力的轮子快造好了
java轮子拯救世界 |
p***o
发帖数: 1252 | 2 python啥时候出来？
【在 z****e 的大作中提到】
: 就是vertx-sync
: 就是利用fiber构建一个轻量级的thread
: which并不一一对应kernal thread
: 简单说，如果你block了fiber
: 并不会导致os的thread被blocked
: 通过这种方式，你就可以丢掉promise, rxjava以及更为糟糕的callback了
: 直接用你最熟悉的sync的方式编写异步代码
: 唯一的改变就是你把Future改成Message
: 然后随便用.get, .body，会block fiber但是没有关系，不会阻塞thread
: 类似goroutine，vert.x依赖的这个类似go的项目名字叫做quasar
|
z****e
发帖数: 54598 | 3
应该要等明年了
python lang support那个法国佬在忙着写网站
和vert.x awesome的test cases
年底之前比较可能加上去的语言是极为小众的ceylon
其他都要继续等了，你可以主动申请去试试
他们好像会提供tutor，因为新语言支持都是通过cod gen来生成
【在 p***o 的大作中提到】
: python啥时候出来？
|
l******s
发帖数: 3045 | 4 好像就是.net的async+await关键字的feature.
【在 z****e 的大作中提到】
: 就是vertx-sync
: 就是利用fiber构建一个轻量级的thread
: which并不一一对应kernal thread
: 简单说，如果你block了fiber
: 并不会导致os的thread被blocked
: 通过这种方式，你就可以丢掉promise, rxjava以及更为糟糕的callback了
: 直接用你最熟悉的sync的方式编写异步代码
: 唯一的改变就是你把Future改成Message
: 然后随便用.get, .body，会block fiber但是没有关系，不会阻塞thread
: 类似goroutine，vert.x依赖的这个类似go的项目名字叫做quasar
|
s***o
发帖数: 2191 | 5 Tim Fox:
Apparently folks, JavaEE is the future! (Or so people are telling me). What
do you think about that? |
z****e
发帖数: 54598 | 6 jee是java成熟的规范的合集，vert.x越做越像jee，但是是脚本的jee，还有其它的，
跟jee是一个很好的互补，我不认为vert.x应该纳入jee，强迫要求一般的企业开发用
ruby等脚本没有意义，程序员不管会哪个轮子，学习另外一个都是很好的提升，不同的
东西，架构，理念都不一样
：Tim Fox:
：Apparently folks, JavaEE is the future! (Or so people are telling me).
What do you think about that? |
s***o
发帖数: 2191 | 7 老赵理解错了，Tim Fox是在发牢骚。有可能是red hat 内部的JEE五毛诸如Arun
Guupta之流在搞vert.x的小动作
【在 z****e 的大作中提到】
: jee是java成熟的规范的合集，vert.x越做越像jee，但是是脚本的jee，还有其它的，
: 跟jee是一个很好的互补，我不认为vert.x应该纳入jee，强迫要求一般的企业开发用
: ruby等脚本没有意义，程序员不管会哪个轮子，学习另外一个都是很好的提升，不同的
: 东西，架构，理念都不一样
:
: ：Tim Fox:
: ：Apparently folks, JavaEE is the future! (Or so people are telling me).
: What do you think about that?
|
z****e
发帖数: 54598 | 8
嗯，有可能，vert.x的core developers很多以前都在red hat的jboss组
比如这位
http://www.linkedin.com/in/normanmaurer
不可能现在才说这些话，多半有人给他打了鸡血
感觉这几个人在vert.x, apple, red hat, apache这些组织里面串联过
【在 s***o 的大作中提到】
: 老赵理解错了，Tim Fox是在发牢骚。有可能是red hat 内部的JEE五毛诸如Arun
: Guupta之流在搞vert.x的小动作
|
t**r
发帖数: 3428 | |
z****e
发帖数: 54598 | 10 昨晚看了看，大概是这么一回事
这个东西主要是用来解决callback hell滴
也就是各种恶心的金字塔
让异步之后的处理变得更为flat
而不用担心被blocked
具体的做法是
1）把quasar的lib放入vert.x的lib文件夹下
2）更改extends的class
3）同时启动时候需要加参数
4）最后需要在你使用的方法上加入@Suspendable这个annotation
从这几点上看，还是略微折腾了点
离傻瓜化还有距离，不过anyway，千里之行
解决的问题呢，就是Future之后的future.get, body这些方法
调用的时候都不会block当前的thread，所以可以直接像Future例子一样用async
而不用担心被blocked
以前Future future = awaitResult...
然后future.get();这一步是blocked，如果要想不blocked
就需要callback which会制造出金字塔来
或者rxjava/promise这种publish/subscribe模式，但是略显得麻烦
用了这个之后，这一步就不是blocked
就不需要你再用callback, rxjava & promise了
虽然vert.x也还是支持这三种方式
大概就这么多，呼声很高
加入这个feature的呼声比做scala，python语言的支持呼声都要高
最后加入这个也是顺应了民意，另外一个是redeploy功能
最终的结果还是需要等月底发布之后试一下才知道 |
|
|
S*********t
发帖数: 78 | 11 试了一下 vertx.sync, 确实不错。
现在就可以用 3.1.0-SNAPSHOT了。vertx.core还用 3.0.0就可以。
代码写起来比 rxjava 容易太多了。代码也容易读懂，毕竟大家更习惯sync的思路。
需要注意的是 所有用到异步的地方都要加@Suspendable ，包括 interface。
这块搞了我好久。 |
f*********t
发帖数: 17 | 12 if using fiber why still sticking to Vert.x than use dropwizard
which is much simpler and more familiar to most
【在 S*********t 的大作中提到】
: 试了一下 vertx.sync, 确实不错。
: 现在就可以用 3.1.0-SNAPSHOT了。vertx.core还用 3.0.0就可以。
: 代码写起来比 rxjava 容易太多了。代码也容易读懂，毕竟大家更习惯sync的思路。
: 需要注意的是 所有用到异步的地方都要加@Suspendable ，包括 interface。
: 这块搞了我好久。
|
z****e
发帖数: 54598 | 13
不觉得vert.x更难，我觉得dropwizard的上手难度要高不少
这两个用的库有不少重合的，但是dropwizard更传统一点
用的主要还是jee那些东东，做了一个集成
相比之下，vert.x对于udp, nosql, polyglot这些支持要强过dropwizard
而且vert.x主要优势在于kernal绑定的threads数量，eventloop的搞法
其他都是thread pool，从效率上说，应该vert.x会更强一点
不过如果都用了quasar，本质上的threads数量应该是一样的
另外一个就是，其他大部分框架，包括dropwizard，servlet，spring
集成都要自己折腾，需要倒腾comsat integration
比如comsat-dropwizard
vert.x就有官方帮忙搞，所以会更傻瓜一点
【在 f*********t 的大作中提到】
: if using fiber why still sticking to Vert.x than use dropwizard
: which is much simpler and more familiar to most
|
z****e
发帖数: 54598 | 14 31snapshot在哪下？还是mvn package？
【在 S*********t 的大作中提到】
: 试了一下 vertx.sync, 确实不错。
: 现在就可以用 3.1.0-SNAPSHOT了。vertx.core还用 3.0.0就可以。
: 代码写起来比 rxjava 容易太多了。代码也容易读懂，毕竟大家更习惯sync的思路。
: 需要注意的是 所有用到异步的地方都要加@Suspendable ，包括 interface。
: 这块搞了我好久。
|
f*********t
发帖数: 17 | 15 dropwizard is just a bundle of jersey, jetty, hibernate(optional)
people don't even need to learn it, assuming most have already used these
adding fiber to dropwizard is just a minor change
【在 z****e 的大作中提到】
: 31snapshot在哪下？还是mvn package？
|
z****e
发帖数: 54598 | 16
是啊，这些东西都略微heavy了一点
而且不够灵活
比如udp，nosql，支持就不好了
udp怎么看都需要netty系的产品，比如netty, vert.x这些
nosql怎么看也都不怎么需要orm
【在 f*********t 的大作中提到】
: dropwizard is just a bundle of jersey, jetty, hibernate(optional)
: people don't even need to learn it, assuming most have already used these
: adding fiber to dropwizard is just a minor change
|
