|
p*****2
发帖数: 21240 | 2
那也要有module吧？我倒是想问一句，vert.x毛长齐了吗？ |
|
z****e
发帖数: 54598 | 3 the best answer for what is vert.x
is
node.js on jvm
if they dont know what this means
then apparently they dont know what node.js is
vice versa |
|
z****e
发帖数: 54598 | 4 尤其是各种script language版本的leetcode
自己想一想是不是这样
而且随着vert.x上语言的增加
也很容易扩展啊，连test cases都可以共享
某人做leetcode的，应该考虑一下
现在群众们对其他语言版本的呼声很高啊 |
|
d*******r
发帖数: 3299 | 5 我觉得要是能用 vert.x message bus + redis 搞出一个有 cluster 模式的, 易用
memory db, 小团队用这个搞 mmorpg 也不是不可能.
我之前看云风他们的blog，觉得前几年国内搞 mmorpg 还在用 C++ 或者 C&Lua 呢，感
觉那个搞法好辛苦。
不知道新的mmorpg小公司怎么在搞。
好像blizzard 和 valve 还在搞 C++ 的那种gaming server (最近看他们招聘广告猜的
)，毕竟他们是传统的游戏公司，C++ guys 肯定很多。 |
|
|
|
|
|
p*****2
发帖数: 21240 | 10 vert连个框架都没有还玩啥呀？还不如学go呢 |
|
d*******r
发帖数: 3299 | 11 有 message bus, cluster, memoryDB (现在看developers讨论, hazelcast版本2.x,3.
x有些问题在扯)
打算用TCP在上面写 clustered game server 玩，web service 不打算玩 vert.x 了.
go 还得自己学一门不知道前途的语言，还不如用 Java 呢. |
|
p*****2
发帖数: 21240 | 12
3.
.
vert.x把Node复杂化了。node的特点就是简单易用。
messagebus, memorydb, 一个redis就搞定了。 |
|
z****e
发帖数: 54598 | 13 ft
这跟你没半毛钱关系
这个底层的依赖是注定要update的
vert.x的各个脚本引擎也都会定期update
对这些做了包装之后，开放的旧的api接口不变，你的代码就不需要重写
当然这可能会有一点点问题，比如以前java升级，hashtable很多会出点问题酱紫
java项目底层依赖升级是非常正常的事情
其本质就跟你升级linux, jvm这些没啥太大区别 |
|
z****e
发帖数: 54598 | 14 jvm的人才不好找啊
community没啥问题啊
我之前一直在等rxjava成熟
因为没有rxjava，金字塔结构实在是很让人恶心
现在vert.x+rxjava配合得非常好呀
npm也很快就有支持，这个主要看对jvm的熟悉程度
一般没用过的搞不定，你应该没啥问题 |
|
z****e
发帖数: 54598 | 15 clj的问题很明显，金字塔，非常讨厌
rxjava的flat很讨喜
rxjava更新很频繁，很活跃，我很喜欢
vert.x 3的milestone 2已经出来大概一个月了
很快3就会下线，到时候跟着升级就是了
据说一般的脚本也可以打成jar了
没试过 |
|
|
z****e
发帖数: 54598 | 17 用vert.x最好一点就是
任何新生事物，你都可以通过它的mod做点尝试
如果尝试可行，可以非常快地转换成生产力
如果不可行，拆掉也就是一分钟的事
不需要你做任何非理性的冲动的选择
all or nothing是不对滴 |
|
f*****w
发帖数: 2602 | 18 我其实需要的就是个webservice的方便高效的后端，然后也需要websocket。后台数据
都是SQL。
其实play挺符合我的要求的，里面整合的ebean啊啥的都还不错 基本我要得也就是这些了
我已经尝试用play 试着写了下code 发现unit test 搞起来很不方便，或者也许是因
为我没有写过带DB操作的unit test, 是不是无论用什么都写带数据库操作的测试都会
很麻烦？ 当然play的问题确实就是太整合了 所以ebean出了问题 包了好几层之
后 我完全弄不明白为什么 好几天了我还是没搞定让测试的时候换一个数据连接 并
且每次自动刷新表定义 汗 太弱了。主要也是play的文档好差啊 真是好差啊觉得
btw vert.x现在的文档支持怎么样啊？
此外play的闹剧你是指什么啊？ 就是在说1到2的结构大改吗？（其实我没用过1，不知
道到底改了些啥） |
|
z****e
发帖数: 54598 | 19 vert.x访问数据库直接用worker+jdbc
jdbc文档烂大街，worker你看官方文档
然后试试就知道了 |
|
z****e
发帖数: 54598 | 20 vert.x clj的hello world
(ns example.server
(:require [vertx.http :as http]))
(-> (http/server)
(http/on-request
(fn [req]
(let [uri (.uri req)]
(-> req
(http/server-response)
(http/send-file (str "webroot/" (if (= "/" uri) "index.html" uri
)))))))
(http/listen 8080))
看到))))))了没有？
这就是金字塔的顶点 |
|
|
z****e
发帖数: 54598 | 22 vert.x文档有8个副本，随便看，对照着看
一个看不懂换另外一个
是1 |
|
|
z*******3
发帖数: 13709 | 24 akka太过于底层了
play又太过于高级了
vert.x介于两者之间正好 |
|
h*i
发帖数: 3446 | 25 这个vert.x在web platform benchmark中成绩是垫底的，有什么说头么？ |
|
z*******3
发帖数: 13709 | 26 http://github.com/TechEmpower/FrameworkBenchmarks/issues/846
放心吧，vert.x很快又会回来的
以前经常争第一第二的，唯一能比的就是go了
purplefox commented on May 2
Basically the same reasoning as Spray used here:
#842
The version used in round 9 is really old (2.1M3) and there have been lots
of performance improvements since then, so the results are misleading. |
|
N*****m
发帖数: 42603 | 27 赵策的两个心头肉：vert.x和dart。哈哈 |
|
p*****2
发帖数: 21240 | 28 我们公司一个大牛最后用了akka 抛弃vert.x了 说是一大堆问题 其实akka也不算是好用 |
|
z****e
发帖数: 54598 | 29 我都已经上线了三个项目了
vert.x没啥太大问题
主要问题是eclipse支持还比较弱
所以很多概念弱人搞不明白
本来jvm就很麻烦
再加上各种语言上的feature
你让脚本语言的程序员怎么活哟
如果搞得明白怎么会沦落到去写脚本的地步？ |
|
z****e
发帖数: 54598 | 30 akka听说有scala的ide上的plugin
但是我们组当时没用
不知道效果如何
hoho
vert.x没有plugin
写起来必需用vi，这个非常非常蛋疼
现有的一个plugin是nodejs在eclipse上的plugin
所以用不了ide，现在我觉得设计没啥问题
执行也没啥问题，问题在于缺少ide的支持 |
|
|
z****e
发帖数: 54598 | 32 对于vert.x除了内存使用比较高以外
没有啥其他看法，理论上你把所有代码写成一堆
是效率最高的，但是这样不利于代码的维护和分工
分开比较好，模块化代码更加清晰，也便于他人接盘 |
|
|
z****e
发帖数: 54598 | 34 这个东西最好的一点就是它允许你尝试
你可以先丢给它一两个mod看看效果
如果不行就不要继续了，如果可以再继续
官方有文档教怎么做，all or nothing是不对的
如果选择其他的
比如akka或者play，如果你不要的话，换起来相当蛋疼
vert.x自由度实在太大，想怎么搞就怎么搞
设计构架的时候，如果不需要这种自由度的话
我也没啥好说的 |
|
d****n
发帖数: 1637 | 35 没有尝试是真的，但是也不是一点也没看。
我就是想像不出什么情况下要python,java,js,perl, ruby groovy一起来。
这不造成混乱么？verticle是它的主要idea，但是为什么要把各种平台搭建一起呢？
如果目的是为了整合现存的project,可能有一些作用。
鄙人觉得它更适合一个 CI平台而不是一个productive的dev平台。
不过我还是想继续关注vert.x
谢谢分享 |
|
d****n
发帖数: 1637 | 36 vert。x拆分的是后端吧
前端多了够乱套的。资源浪费吧。
举个例子，前段的java来一个，web来一个，除了显示公司气派，没有别的太多好处吧 |
|
z****e
发帖数: 54598 | 37 考虑啊
无论用什么框架
你都需要考虑这个成本
哪怕是同样一个java程序员跑路
换人接盘，也还是有成本
这个成本是不可能避免的
只能说尽量压缩这个成本到一个可以接受的范围内
所以java最好，毫无疑问，因为接盘最容易，其他语言接盘都不容易
在此基础之上，我们可以考虑引入一些其他语言
比如ruby开发效率高，而且适合搞web
所以把web部分交给ruby程序员，这也是合情合理的
然后切割成不同的mod，这样万一有一个mod出现了无法接盘的灾难
也可以把重构这个mod的影响控制到最低
这也是这个框架设计的初衷，所以我们不是不考虑接盘成本
就是考虑了接盘成本，再平衡各方面因素后作出的决定
如果不切割成mod，一旦有一个模块出点什么问题
无法接盘的话，那麻烦就大了，而且这种方式很适合切割任务
把mod分配到具体的个人，每个mod都有具体的负责人
这样就不会互相冲突了，有新人进来，如果要接盘，则根据接盘的难度划分成多个等级
然后按照等级来分配接盘适应的时间，整体上便于控制项目进度和调度
以前是把一个大系统切割成几个系统，然后每一个系统有一个负责人
但是这样还是需要协调人和人之间的关系，总会有人这... 阅读全帖 |
|
z****e
发帖数: 54598 | 38 而且不同的mod还可以用不同的framework
比如html，你就可以选择thymeleaf或者freemarker这些
随便选，vert.x对接无非就是包装一个mod的问题
很容易搞 |
|
|
z****e
发帖数: 54598 | 40 用vert.x用多了明显感觉groovy要强过javascript太多
->秒杀function(...){}一堆乱七八糟的写法
js写起来太繁琐了，不管什么例子
只要是适合脚本书写的，groovy写出来的代码都是最短最简洁的 |
|
|
|
c****e
发帖数: 46 | 43 有成功的应用vert.x的大规模网站（或者web service)实例么？
非常好奇怎么控制session, load balance |
|
z****e
发帖数: 54598 | 44 自己去vert.x 3的网页上看嘛
groupon什么都放上去了 |
|
|
c****e
发帖数: 46 | 46 不知道具体那块是vert.x实现的，如果是log analysis之类的就没什么意思了。 |
|
z****e
发帖数: 54598 | 47 自己都不会去看吗？
groupon率先跳出来说，我们用vert.x |
|
z****e
发帖数: 54598 | 48 自己都不会去看吗？
groupon率先跳出来说，我们用vert.x |
|
d******e
发帖数: 2265 | 49 vert.x挺好的。
。。。。
学习材料。我颇学了几手设计思想。 |
|
p*****2
发帖数: 21240 | 50 正在看vert.x的code，callback hell照样比比皆是。这样看async还是golang最美。 |
|
