|
d**x
发帖数: 1934 | 2 【 以下文字转载自 AutoFans 讨论区 】
发信人: drax (沸腾渔乡不是盖的), 信区: AutoFans
标 题: 05 M3 vert 10k miles $47k
发信站: BBS 未名空间站 (Mon May 14 19:00:17 2007), 转信
FULL loaded including everything.
10k miles, warranty to Jan/09
How is this?
Compared with 07 335i, which one will u pick? |
|
d**x
发帖数: 1934 | 3 I don't think the new hardtop vert is cool enough....
touch choice....
startup speed is not my concern at all...5s,6s really doesnt matter to me. |
|
z*******3
发帖数: 13709 | 4 那就这样吧
先把vert.x搞清楚
搞明白了vert.x，你就至少弄明白了async和thread pool
然后进阶，把streaming给搞明白
这个vert.x中也有
然后琢磨清楚vert.x是如何对付udp, tcp, http, websocket这几块的
话说websocket真垃圾，用的是http 1.1的协议，http2比1强太多
2就适合用来搞streaming了
这就是网络，网络不需要特别底层，但是从tcp,udp/ip以上就需要你最好弄清楚
然后把web service大概弄弄，会用到json和xml
这是网络，切记，结合vert.x去搞，看看vert.x是怎么搞的
vert.x的文档例子都很全面，遇到不懂的，查，问，发邮件问你以前大学的叫兽
想办法搞懂
这是网络部分
然后数据部分，这个没那么容易
先把paxos和cap搞懂，各种trade off琢磨清楚
paxos太理论，而且故弄玄虚，搞懂raft，想明白为什么raft那样搞
这个比较实际，然后弄明白cassandra以及hdfs，弄清楚这两个跟一般的rdbms有什么区别
区别点从join和transactio... 阅读全帖 |
|
z****e
发帖数: 54598 | 5
用什么都有，用tomcat因为apache口碑好，坑少，文档多
没了，就这一个，这是最理想的，一个类库做一件事
错了，spring的功能是di，主要是管理一个bean的生命周期
这样从客观上节省了内存和decoupling，其次也减少了内存泄漏的可能性
另外一个spring的主要功能是aop，这是spring两大利器
致于mvc，那个其实不重要，属于扯蛋的部分，ui的东西扯蛋居多
因为db本身的市场正在被nosql所蚕食，nosql天生就是object
所以不怎么强调orm，db因为都是relational，所以需要orm
作为trade off，orm牺牲了一部分性能，但是好处是可以比较容易滴迁移db
hibernate用上去之后，你就不在乎mysql和postgre的差别了
当然这很理想，但是至少一定程度上搞定了这个问题
类似ror
no，java的世界缤纷多彩，你看看techempower那个列表
你就可以看到，几乎一半都是jvm上的东西，你很难说某个东西一定不对
都是个人的选择嘛，grails对于groovy来说很重要，要知道
groovy可是表现最佳的脚本，这个你看vert... 阅读全帖 |
|
z****e
发帖数: 54598 | 6
经常
停止这种无意义的blablabla吧？
我们上点能够测量的
我就这么说vert.x+java性能可以超过go，vert.x+kotlin应该也行
但是会略弱于vert.x+java，但是可读性会超过vert.x+java（现阶段）
其次vert.x&go不管在什么时候，都可以吊打其他任何一个同步api的系统
用异步或者协程肯定比同步快，快很多，尤其是在io bound的时候
再来，我们可以保证，用vert.x，可以把用户线程控制在很少量的几个上
具体是cpu available cores * 2
比如1core就是2个线程就够了
再来，在线程数有限的前提下，coroutine要做的事很少，就是suspend&resume
我相信go的coroutine要做的更多
木有错，所以go很有可能做得不好，所以性能比不过vert.x
说这些，都需要证据，不要没事blablabla，证据就在这里
https://www.techempower.com/benchmarks/#section=data-r14&hw=ph&test=json
我个人认为啊，vert.x和异步，再加上coro... 阅读全帖 |
|
z****e
发帖数: 54598 | 7 尝试着回答一下这个问题
1）做不到比os native的更好，但是问题在于，有些操作系统根本就没有cooperative
sheduling，比如linux，如果有的话，直接做一层包装就好了，但是没有的话，就只能
让语言来做了
2）不靠机器码，但是靠字节码，基本上就差不多了，光靠当前java的api，是不够的，
需要加多一个context参数，参考kotlin的coroutine实现，或者是通过java agent_织
入_一些context代码，这就是quasar的实现，这也是loom名称的由来
3）强在哪里呢
嗯，这个说来话长，说说我的理解
wdong有一篇回帖，解释了os层面cooperative scheduling和preemptive scheduling的
区别，有空自己去找，但是我觉得他说得复杂了，当然也因为后来用户层面框架的发展
，比如actor model有关系，看看我能不能解释清楚，这一块涉及的东西太多，os&jvm
和vert.x/actor model乃至开发者自身，都有需要配合的部分，任何一个部分不能掉链
子，所以解释起来不容易
先说os&jvm层面，这个是... 阅读全帖 |
|
|
z*******3
发帖数: 13709 | 9 vert.x什么都能做
node单线程非常蛋疼，性能并不理想
而且将来streaming弄上去的话，我不认为单线程会有什么前途
因为streaming天生就是blocking的东东，你一定会需要多线程
而一旦涉及worker，node就不是那么好用
如果那帮人已经提出要弄jvm的话，多半是他们自己的考虑
就像你之前说的，主要做http web service，这个就不是web
多半不只需要倒腾html那些东东，等到时候绕了一大圈，最后发现
你还是不得不倒腾jvm的话，那就很不划算了
node有自己的engine，jvm是另外一个平台
要同时维持两套班底，就显得很亏
vert.x的主要竞争对手就是所有的东西
包括node, akka, ejb这些，其实都被某些媒体拿来对比过
就spring的di目前没怎么说，因为暂时先不做di，这个在community讨论过
主要是其他语言的开发者反对，因为无法实现，只有java的用户要求比较强烈
因为spring是de facto企业王者，所以建议多抄袭spring
最后tim说，暂时先不搞
但是你自己对spring熟悉的话，把spring结合到ver... 阅读全帖 |
|
z****e
发帖数: 54598 | 10 java就是vert.x
vert.x把这一块能做的做到了最好
go跟vert.x是一个pattern
只不过go把这个压到了语言level去实现
vert.x则是framework
从本质上说差不了太多
你们只是看个名词，对名词缺乏了解
流于表面，好像语言之间是mutually exclusive
但其实这只是一个外行的观感而已
go跟java可以说是一个path
所以你会发现，go和java互相之间不怎么掐
虽然总有人挑拨离间，巴不得互相骂，哈哈
还有java跟swift也是如此
go和java不仅在idea上有诸多相似
google和sun本身也有很多共通点
程序写得太少的话，最后就是在一些superficial的东西上纠结
我就不纠结这些东西，你看我搞swift，三天出mvc框架，从不懂到出东西
完全就是java/android的基础，同理你会了vert.x对于go也是很快出东西的
熟悉熟悉语法就可以了，你还在认为vert.x非主流
那说明你要么不会vert.x要么不懂go或者干脆就不懂这一块是怎么做的 |
|
z*******3
发帖数: 13709 | 11 怎么可能不值一驳
diversity好，软件产品尤其需要diversity
一家独大对谁来说都是不利的
现阶段flink还没有正式推出，有点像当年我们搞storm时候看spark的感觉
倒是如果你想contribute的话，这个时候是非常好的参与flink的机会
spark人满为患，这个时候再凑过去，顶多就是一个用户，人家也不需要你的贡献
spark有spark自己的问题，比如streaming就不怎样，设计上有缺陷
rdd是好东西，但是把所有的东西都搞成rdd，那又是另外一回事了
就像singlethreadness是容易，但是把所有东西都搞成single thread
那又是另外一回事了，flink的core就是streaming的，如果你对scala还有java敏感的话
应该可以感觉出来，streaming好像是future啊，streaming一捅到底那种感觉非常美妙
完全畅通无阻那种感觉，vert.x和flink都在强调streaming，还有scala那一堆东西
比起flink来说，vert.x的机会更大
vert.x替代akka应该是大势所趋，akka稍微复杂一点的rea... 阅读全帖 |
|
z****e
发帖数: 54598 | 12
我们先找一个共识
就是在一个core上做
很容易，因为没有lock
对吧？这个是所有人都认可的
然后在这个基础之上，我们有两条路可以走
一种是直接上coroutine，要求coroutine解决多核环境下调度的问题
这就是go走的这条路，我相信这条路不好走
也需要“牛得不得了的人”才能搞定，很有可能
另外一条路是这样，你先放下这个问题，我们继续往前走
看看有没有其他的路，找啊找
诶，突然发现，有一条路叫做actor model
可以通过eventloop这种方式，把原来一大票线程给降下来
为什么呢？原理很简单，原先io的时候，同步api无论如何
要占用一个线程，给我等着
异步api的好处就是可以马上释放调用线程
这样我们可以复用同一个线程，然后对于我们常见的场景
也就是那些大量crud的业务场景
基本上都是io bound的场景，所以可以通过少量线程就能host住大量的请求
比如原来用tomcat，要几千个线程的线程池
现在只需要20多个就行了，甚至用1core 1g的机器，也就是2个eventloop，记住这个关
键字
以后你会经常遇到，spring都开始eventloop，spr... 阅读全帖 |
|
p*********e
发帖数: 32207 | 13 突然发现,rose的胳膊好~长啊,手和很大,加起来效果相当震撼了
放狗搜了一下他的wingspan,在这个网页同时看到了cp3跟deron Williams的数据:
http://www.insidehoops.com/forum/showthread.php?t=106661&page=3
D. Williams:
6'2 3/4" w/shoes
6'6 1/4" wingspan
30-inch no step vert
35-inch max vert
3.25 sec. in 3/4 court sprint
C. Paul:
6'1" w/shoes
6'4 1/4" wingspan
32-inch no step vert
38-inch max vert
3.22 sec. in 3/4 court sprint
D. Rose:
6'2 1/2" w/shoes
6'8" wingspan
34.5-inch no step vert
40-inch max vert (I guarantee you it's higher)
3.05 sec. in 3/4 co |
|
d********g
发帖数: 10550 | 14 好虫对蜥蜴鼓吹的vert.x发起猛攻。主要观点：
1. JVM主要是Java自己玩，没几个主流语言在JVM上run更别说抗衡了
2. Java world对async没有不明觉厉（多线程不灵或者没有的更欢迎async例如Python
和JS，Java不着急，这是事实）
3. vert.x不会是主流，结局堪忧
蜥蜴观点：
1. JVM统战一切，只要沾了JVM就得道升天
2. vert.x会吸引别的语言的人
3. vert.x这个没多久前才发现的新玩具是人类的救星，之前鼓吹的那些都不算了
两人观点针锋相对，只是好虫碍于Java面子从来不当面驳斥蜥蜴。拭目以待vert.x能撑
多久
发信人: goodbug (好虫), 信区: Programming
标 题: Re: vert.x 基本上没戏
发信站: BBS 未名空间站 (Tue Jan 28 16:19:03 2014, 美东)
出了java.现在主流语言有几个在jvm 上run啊。
我评论的是他这句话。
其实java world并不是那么在意async，否则netty之上早就一堆东西了。akka迄今也没
火。
vertx估计结局也... 阅读全帖 |
|
z****e
发帖数: 54598 | 15 干活要紧
因为有个项目得把tweets plot在google map上
不得不碰ui，所以这个时候dart就非常管用了
当然vert.x也很好用啊，我用vert.x做个server
然后ui发送request给vert.x，vert.x收到以后，发送一个request到couchdb
或者cassandra这种，然后把结果收集到，处理一下，反馈给ui
很爽的说，dart+vert.x是绝配，很容易搞
vert.x+spark+cassandra这些也是绝配，很容易搞
这是用dart如何call google map api以及如何调用google map的一些函数
我需要用call google map的api来获取经度纬度
供参考
void showMap(double latitude, double longitude){
JsObject center = new JsObject(context['google']['maps']['LatLng'], [
latitude, longitude]);//-37.8136,144.9631
JsObject mapO... 阅读全帖 |
|
z****e
发帖数: 54598 | 16 会依次对比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等... 阅读全帖 |
|
z****e
发帖数: 54598 | 17 会依次对比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等... 阅读全帖 |
|
z*******3
发帖数: 13709 | 18 spark的streaming的对比看这个slides
http://www.slideshare.net/ptgoetz/apache-storm-vs-spark-streami
flink还没推出，但是从设计上看，应该不会有类似的问题
我感觉最近streaming的需求越来越强烈
需要一个针对前后端都能够搞streaming的东东
vert.x是一个很不错的选择，但是vert.x对付c*之类的nosql，还显得工具偏少
另外mllib这些lib目前只能host在spark,flink这些上面，vert.x还缺少类似的libs
vert.x毕竟更为general一些，但其实你自己琢磨琢磨也没啥难的
无非那么一回事了，mapreduce那些api，跟rxjava有很大重叠
可以用rxjava实现一遍，主要是算法，mllib部分，clustering，svm etc.
api的话，什么flatmap，streaming之类的rx都有了，vert.x成熟之后大有可为
vert.x, rxjava, flink这些逐步走向成熟，过程值得学习和参考
当然spark之类已经取得巨大成功的更值得... 阅读全帖 |
|
z****e
发帖数: 54598 | 19 java最好一点就是不会动不动闹革命
把已经解决过的问题再解决一遍
这个绝对不是java整个eco的哲学
所以j2ee, spring, vert.x, netty, groovy, scala这些东西
互相之间有一些交集，但是基本上都不是直接竞争关系
而是互相补充，j2ee是最大的一个集合
但是j2ee并不管很多事情，只负责制定一些high level的标准
netty相比之下则只负责一些底层的api封装
并不负责high level的标准，实际上jee早就已经把vert.x的哲学吸收进去了
undertow就是一个代表，vert.x则侧重于传统jee所不涉及的部分
比如对于其他脚本的兼容性，比如兼容其他网络协议，比如tcp&udp
远不像servlet container那样侧重http
同样j2ee并不怎么搭理persistence的部分，spark, hadoop这些就负责完善这部分
所以问取代不取代，毫无意义，你用vert.x和netty一样可以搞出j2ee来
看你自己怎么做了，问题在于，vert.x和netty并不侧重j2ee那些标准
虽然有重合，实际上vert.x也已经实... 阅读全帖 |
|
z****e
发帖数: 54598 | 20
rxjava主要是用来弥补java在fp上的不足的
主要应用是streaming部分
你做flink应该清楚，set和stream是两种不同的类型
前者一开始就知道大小，后者对于结束边界搞不清楚
所以涉及streaming的部分，用rxjava比较多
而且streaming部分主要是fp的应用，map(func,a)
如果是fp语言的话，比如clojure，就不怎么需要这个东西
但是java是纯粹的oop语言，所以需要弥补fp上的不足
这个不足就由rxjava来填，当然你换clojure或者scala也可以
这两者的fp部分比java要强不少
vert.x则是一个什么都做的东东
我感觉vert.x是java的延伸，java的特征就是尽一切可能封装各种接口之类的
jvm封装了os的差异，jdbc封装了db connection，hibernate封装了sql的差异
vert.x则封装了file system的差异，还有web protocol的差异，以及各种jvm上脚本的
差异
尽可能提供一个统一的接口，对于所有不同的软件产品
然后还做了其他很多东西，其中reactive和stream... 阅读全帖 |
|
z****e
发帖数: 54598 | 21
这就是脚本嘛，哪个脚本不能实现if then else？
这个叫做操作，file system可以做到，vert.x的filesystem，自己去看能做啥
还有就是，任务本身并不一致，你做个四则运算，难道是copy&paste能够解决的？
如果你觉得能够把所有人类的任务都给归纳总结出来的话
那就做吧，你觉得人类的活动有多少种？
jvm是一个平台，os/linux/unix/windows->jvm/llvm/hhvm/clr -> vert.x/其它还没有
这是一个平台上的进步
c对于物理机器的指令做了封装
java对于跨平台以及内存管理做了封装
vert.x则处理了并发冲突
基于这个进步，有理由认为，vert.x是下一个generation的平台
事实上vert.x已经开始逐步支持各种脚本语言了
这就是一个维度，最左边表示机器能够看懂，而人看不懂的，最右边表示人能看懂，而
需要翻译机器才能看懂的
机器语言 － 汇编语言 － c －c++ － java － 脚本 － 置标语言
我比较看好的下一个语言应该是groovy，groovy已经投入apache的怀抱了
估计以后会得到大面积的支... 阅读全帖 |
|
z****e
发帖数: 54598 | 22
静：
tim fox已经退了吧？
vert.x的东西该做的也就那些了
我不认为vert.x再怎么做会有什么特别的东西了
也就是那样了，就跟linux, jvm一样
再做也就是那么一回事了，该解决的问题解决了
再搞有什么可以搞的？
jvm的james gosling, lars bak几个早就退了
linus还不退，不过也看不出有啥可留恋的了
这些东西做完了，剩下点维护人员就好了
留在那边瞎搞反而会出问题
比如python2->3，我靠，尼玛这样瞎搞，谁有办法接受啊？
生产代码一个升级就要重写一遍，谁都吃不消啊
vert.x跟java, linux一样，将来不依赖于某一个人
这个人退了就退了，滚蛋
爱死哪死哪去，idea留下，就可以了
至于谁来写，不重要，不折腾反而更为重要
就怕瞎折腾，改来改去，把原来work的东西改成不work了
或者东西越加越多，就像spring一样，那反而出问题
vert.x的核心就是core，估计这个版本以后就封死了
别再做了，idea就是这个，再做也做不出什么花样来了
我也不认为这个架构定下来之后，还能做啥
留下几个人做维护，一点一点慢慢改，主要是把一些监控... 阅读全帖 |
|
z****e
发帖数: 54598 | 23
给你个建议，不要碰akka
akka和vert.x的概念很相似，但是上来就跟你扯各种概念
akka的复杂度类似ejb，其实很简单的东西
绕出各种概念，什么actor，什么immutable
如果你从akka开始，你会花很多时间在这些扯蛋的概念上
相反，如果从vert.x开始，就不跟你说这些概念
就用最简单直白的语言告诉你是怎么回事
你看懂了vert.x之后，回头去看akka，很快就能看明白
然后再去看那些概念，就变得很简单了，如果反过来
学起来就是事倍功半，网络上有很多vert.x vs akka的对比
你可以看看别人怎么说的，我看到的都是一边倒支持vert.x
akka这个东西，就跟sun当年的很多东西一样
复杂难懂，java他爹james gosling就在typesafe混现在
这批人就是sun当年那批人，搞的概念都复杂异常
我当年照着sun的tutorial，搞一个jndi，看了两周的文档
硬是没搞出来，麻痹，概念全懂了，但是例子就是各种run不了
后来下了idea的plugin，直接上jboss，一分钟搞定了 |
|
z****e
发帖数: 54598 | 24 网络上有很多vert.x vs node.js的对比
包括github上有源代码
你自己都可以跑一跑试试
看看效果
vert.py还行，最慢的是vert.js还是vert.groovy，不记得了
不过就是最慢的vert.js也比nodejs要快一个数量级 |
|
d*******r
发帖数: 3299 | 25 我也在观察 vert.x, 我其实对 vert.x 2个 dependencies 里面那个 hazlecast 还比
较感兴趣。
不过最近看 vert.x google group, 好像 vert.x 要升级到 hazlecast3，还是自己搞
个独立的hazlecast-vert.x都不是很确定。 |
|
j******f
发帖数: 825 | 26 说的是你不懂node，你自己说搞不定的。
vert.x用js我都要笑弯腰了，你用js不用node，绕了一大圈去通过vert.x来用js？恰恰
证明你根本不懂node，需要用vert.x来帮助你解决你的问题。
其实用vert.x没什么，没啥不好意识的，水平差点借助一下vert.x也没啥，别想太多，
只要能干活啥都行。 |
|
j******f
发帖数: 825 | 27 说的是你不懂node，你自己说搞不定的。
vert.x用js我都要笑弯腰了，你用js不用node，绕了一大圈去通过vert.x来用js？恰恰
证明你根本不懂node，需要用vert.x来帮助你解决你的问题。
其实用vert.x没什么，没啥不好意识的，水平差点借助一下vert.x也没啥，别想太多，
只要能干活啥都行。 |
|
z****e
发帖数: 54598 | 28
这当然不可能
php和go这些都还有其用武之地
包括node这些
但是vert.x对于node+go+akka这种复杂的架构来说
威胁是十分巨大的，因为维护三套不同语言的系统
需要的人力物力成本，远比你维护一套vert.x来得要高得多
复杂度也要高得多
下面就看flink, spark这些哪一个更聪明点，会先手用上vert.x了
或者出现一个更为聪明的项目，直接用vert.x酱紫
又或者是vert.x逐步演变成这么一个项目 |
|
z****e
发帖数: 54598 | 29
vert.x是所有先进思想的汇总，你学会了vert.x
就会学了很多东西，比如node, akka, go这些，都跟vert.x有某种意义上的重合
或者直接说吧，vert.x就是抄袭这些东西的产物
如果你会java，学得比较好的话，vert.x是一个很好的bridge |
|
z****e
发帖数: 54598 | 30 你可以说计算机语言已死
或者说是一个夕阳产业了
就是人类已经发现了这个领域的最优解
就不再继续折腾了，你只需要学会人类定义好的规则就好了
计算机语言这个领域已经没有什么难题需要人类去解决了
java之前，人们之所以搞计算机语言
是因为觉得机器的对话方式，跟人类对话方式有比较大的差异
所以人类可能看不懂机器在执行什么，比如01001011110101010
给你这么一串，你滴不懂这个是啥意思
但是java之后，基本上人能看懂了
所以满足了这个目的之后，还在折腾计算机语言的
不是脑子有屎就是目光短浅，人家解决过的问题
你解决了干嘛？就犹如数学上的某个猜想，已经得到了证明
你再证明一遍？有用吗？你就算证明出来了，人家多半也会说你是抄的
所以计算机语言这个level，已经没有什么可以继续搞的了
剩下无非继续傻瓜化，做成脚本或者置标语言这些，区别不会太大
所以你应该转移到计算机语言以上的东西上去
比如用java来实现什么，vert.x就是一个最好的前进
vert.x之后肯定还有，但是基础类软件，到vert.x应该是一个终结了
vert.x连并发都搞定了，下面人类应该进入纯粹的数学抽象领域了
进入... 阅读全帖 |
|
z****e
发帖数: 54598 | 31
hello world开始
先学语法和概念，oop这些
然后了解ide，不要用vi和记事本傻做，那样效率很低
然后用vert.x，vert.x的好处就是它不是那么傻瓜的
需要你理解了原理之后才能用好
但是又不是那么困难，比起jvm来说，vert.x容易多了
os/c的难度是最高的，其次jvm/java，然后vert.x最简单 |
|
z****e
发帖数: 54598 | 32
计算机语言其实很简单啊
就是把机器能够理解的各种指令，翻译成人能够理解的语言
最早无非01010000111这些，然后有了汇编，就是指令集嘛
但是看指令多累啊，所以有了操作系统unix和c
但是操作系统和c主要是解决cpu的问题
对于cpu基本上封装得差不多了，但是对于内存呢
c封装得不彻底，就是人还是要手工去操作内存，释放内存这些
很烦，而且容易错，但是在c那个年代，没有特别好的方法
然后c++加入了点object的概念，因为在c横行的那个年代
软件系统已经开始越做越大了，而因为c对于内存的操作没有做封装和统一管理
导致很多项目因为程序员对内存的操作不当，而失败
当时的数据是90%以上大型项目是失败的
包括james gosling本人做的那个c++项目
搞不定，疯了，于是sun那批人就凑一起，说，我们来设计一种新的语言
以解决这些常见的问题，然后就有了java和jvm
jvm其实就是操作系统的扩展，无非就是做了几件所有项目都会遇到的问题
一个是跨平台，把所有操作系统无差别对待，让软件摆脱对于操作系统的依赖
程序员可以不在乎什么操作系统，你可以在unix上编译，然后放到window... 阅读全帖 |
|
z****e
发帖数: 54598 | 33
那你就需要用到vert.x这种东西了
但是vert.x支持python实在是有些慢
甚至我怀疑他们到底想不想支持python
从他们的优先级来看
脚本支持的顺序是
js, ruby, groovy，然后其它
python属于其它里面
另外,python自身的类似vert.x的什么tornado之类的
不行，还是慢的要死，不能跟vert.x和jvm相提并论 |
|
z****e
发帖数: 54598 | 34
那你就需要用到vert.x这种东西了
但是vert.x支持python实在是有些慢
甚至我怀疑他们到底想不想支持python
从他们的优先级来看
脚本支持的顺序是
js, ruby, groovy，然后其它
python属于其它里面
另外,python自身的类似vert.x的什么tornado之类的
不行，还是慢的要死，不能跟vert.x和jvm相提并论 |
|
z****e
发帖数: 54598 | 35
round 11就会有vert.x了
之前因为忙着搞升级，从2->3，所以tim fox要求暂时不加入测试
错过2轮，现在已经有好事者把vert.x3的测试代码放上去了
round 11就会拉出vert.x的结果
如果你看round8就有vert.x |
|
|
z****e
发帖数: 54598 | 37 hadoop+spark+hbase/cassandra+vert.x/tomcat
vert.x文档比较少，你要比较懂java才行，对网络的协议要比较清晰才行
否则你黑暗中摸索会有很大的心理压力，而且很有可能会做不出来
多少算懂？，这个thread学ee转行的domini回了两个帖子
如果你能看懂他的帖子为什么错，你就算懂，他的两个回帖都是很似是而非的错误
如果你看不懂为什么错，那么还是先不要碰vert.x，用tomcat，至少网络上文档多
hbase和cassandra有apache官方文档
但是你要理解ap&cp系统的差异，但是总体而言比mongodb和couchdb要好用很多
spark和stanford nlp也比python的破pkg要快很多
openshift，jboss，vert.x，jruby这些都是red hat做的
所以互相之间的契合度会高一点
hadoop，spark，hbase，cassandra这几个都是apache的产品
所以互相之间的契合度也会高一点，就是有各种优化，跑得快一点
但是前提是你要懂才行
ide你就不要用jboss studio了，很难用
e... 阅读全帖 |
|
z****e
发帖数: 54598 | 38 总的来说，用vert.x做web服务器不太好用
需要折腾session, html template这些
session用vert.x的一个mod叫session manager
html template就自己随便找一个，thymeleaf或者freemarker
然后自己实现一下mvc，总得来说还是挺麻烦的
如果是web service server的话
那用vert.x倒是非常容易搞出一个东西来
你用vert.x来整合hadoop/hbase 和 php/tomcat这些会相对容易很多
选择真的太多了，怎么做都行，随便你搞
每次用java我就感觉跟妹子们的衣柜一样
一打开，琳琅满目，随便搭配，不同的人选，甚至都不会撞衫 |
|
z****e
发帖数: 54598 | 39 计算机语言这个东西，应该说有两个职能
就像人类语言最重要的职能是人与人交流的工具一样
计算机语言的主要职能是机器与人交流的工具
但是很多人都忘记了一点，计算机语言，同样具备有人跟人交流的职能
最早在计算机语言设计之初认为，人跟人交流通过注释来实现
后来发现，coding monkeys只喜欢劈里啪啦敲代码
最讨厌的就是写文档写注释，而且写出来的注释文档错误一堆
经常几十年不更新，所以最后大多数monkeys只能回头去看代码
所以计算机语言不得不具备有跟人类语言一样的职能，这不能不说是一个喜剧
回到最初的职能上去，那就是机器和人交流的工具
在以前，社会资源有限，计算能力有限，所以机器和人都爽是很难的
所以只能选一个爽，那当然是要让机器爽，机器爽了客户才爽
客户如果不爽，没人给monkeys发工资，那不行，所以第一步是满足机器
最早的汇编什么就是指令集，那就是机器语言
当时所谓的编程就是给计算机下指令，其实不存在有真正意义上的编程
然后有了c这个伟大的发明，c给人类社会最大的遗产应该是操作系统
操作系统之上，c就难堪大任了，一个很重要原因是
c没有搞定内存的管理，c搞定了cpu的管理，这个... 阅读全帖 |
|
d*******r
发帖数: 3299 | 40 好帖，关注中。
所以看完还是觉得 vert.x 最接近 production?
"而vert.x最大的问题是不能实现纯异步，所以还必须实用阻碍的线程，这样就造成了
瓶颈，不利于大并发。"
这个我没太懂，vert.x 这种基于 messages, event, event bus, event handler 的框
架，为什么不能实现纯异步呢。
我觉得 vert.x 也提供 blocking worker thread, 只是多了一个 option，让其表现力
更强而已，可以选择不用啊。
x。 |
|
z****e
发帖数: 54598 | 41 是被滥用
你还是木有尝试vert.x
我不跟你argue，因为你缺少vert.x实际动手经验
等你试过之后再说，看看vert.x是怎么解决callback hell的
当然这你需要看rxjava，小马过河，你与其在这里为node做广告
不如自己动手试试看，vert.x从node那边抄袭了很多东西
好不好，我说了不算，你说了也不算，试过的人自己会有判断 |
|
z****e
发帖数: 54598 | 42 比起你自己动手去用各种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金字塔也是一个成果
好？ |
|
z****e
发帖数: 54598 | 43 相对不容易
其实总体而言都很容易
但是有骗子说vert.x scale会有问题嘛
这个一看就是胡扯蛋，那既然要比较难易度
那显然是vert.x容易scale啊
最简单的，我把cpu从一个core弄成多个cores，vert.x不用做任何修改
全部自动搞定，node就需要自己弄了
而且同样能够handle async的情况，前面我说js能够直接用在vert.x上就是告诉某些骗子
async其实跟语言无关，甚至跟运行环境都没有太大关系
换个语言一样用async，哪怕是python, ruby都可以做到
甚至perl，可惜骗子领悟能力太低，看不懂
其实immutable跟语言本身也是无关的
把context看完整 |
|
z****e
发帖数: 54598 | 44 是被滥用
你还是木有尝试vert.x
我不跟你argue，因为你缺少vert.x实际动手经验
等你试过之后再说，看看vert.x是怎么解决callback hell的
当然这你需要看rxjava，小马过河，你与其在这里为node做广告
不如自己动手试试看，vert.x从node那边抄袭了很多东西
好不好，我说了不算，你说了也不算，试过的人自己会有判断 |
|
z****e
发帖数: 54598 | 45 比起你自己动手去用各种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金字塔也是一个成果
好？ |
|
z****e
发帖数: 54598 | 46 相对不容易
其实总体而言都很容易
但是有骗子说vert.x scale会有问题嘛
这个一看就是胡扯蛋，那既然要比较难易度
那显然是vert.x容易scale啊
最简单的，我把cpu从一个core弄成多个cores，vert.x不用做任何修改
全部自动搞定，node就需要自己弄了
而且同样能够handle async的情况，前面我说js能够直接用在vert.x上就是告诉某些骗子
async其实跟语言无关，甚至跟运行环境都没有太大关系
换个语言一样用async，哪怕是python, ruby都可以做到
甚至perl，可惜骗子领悟能力太低，看不懂
其实immutable跟语言本身也是无关的
把context看完整 |
|
|
z****e
发帖数: 54598 | 48 vert.x+rxjava vs akka就差不多了
网络上看，大部分这种对比，都pro vert.x
其实vert.x vs node.js也都是pro vert.x
主要是性能上明显强过node，这两个是经常拿来对比的两个
and
not |
|
z****e
发帖数: 54598 | 49 actor是vert.x里面的verticle
是最小封装单位
go coroutine顾名思义啊，有点像vert.x的thread pool在做的事
scala的actor是fp嘛，fp的多线程要求很严格
要final啊，要immutable，vert.x和go都没有这个要求
所以akka不怎么需要封装，相比之下，vert.x和go都需要封装
所以差异就体现在这里，go其实就是多了一些gc之类常用功能的c
很多毛病都跟c类似，比较底层，搞ee，infra这些的应该多看go
搞app就算了 |
|
z*******3
发帖数: 13709 | 50
用vert.x就可以做到real time咯
不需要用到跨tiers的io
直接用vert.x自带的bus就可以发送消息了
然后其他逻辑几乎可以照抄你说的所有逻辑
做一个verticle来取代node
再做另外一个verticle来取代akka
ok啦
vert.x就是强大，看懂了vert.x，这些东西都是小意思 |
|
