1
reorx 2012-08-23 18:10:53 +08:00
哈哈,楼主最后一句我喜欢。
|
2
skywinger OP 呵呵,看来大家对用C、C++来做web都不感冒。
|
5
limu 2012-08-26 18:30:52 +08:00
@ljbha007 要说支持自然是支持,就连c也可以concat。 但是好用吗,易用吗,有正则表达式吗,要手动管理内存吗,有split函数吗,unicode好搞吗,这都是问题
|
6
zealot 2012-08-26 19:11:21 +08:00
@limu 有一两年技术积累的C++团队,如果没有类似动态语言一样的正则表达式/split函数/编码处理 封装,那就该反思了。
最大缺陷还在手动内存管理,不过简单业务逻辑(点击统计等中转页面、简单吐出一个iframe页面等)&追求高性能的场景下,这个缺陷就是优势了(自定义内存管理带来的性能提升)。 不过如果需要用到模版引擎、ORM,那么这个复杂性估计已经不适合用C++了。 个人认为,C++应用到web前段引擎开发还是比较适合处理简单的业务逻辑,框架可以是基于Nginx模块机制,或libevent的http库,封装出来一个易于使用的东西,提供uri参数、header、cookie、postdata的获取与Response生成的便利接口。简化开发逻辑。 |
8
limu 2012-08-26 20:20:00 +08:00
@zealot 赞同。
用nginx或boost.asio写异步的代码,由于没有closure,资源的所有权问题很棘手,就算java,也有gc,这个问题还不是那么突出,经过多次异步回调,业务逻辑分散在各处时,c++的资源(内存)谁来分配,谁来释放,都很考量设计能力(智能指针也不能完全解决)。 时间花在这里头就一大半,就不能专注于业务逻辑了,开发效率低,而且门槛太高了。 |
9
skywinger OP |
10
fangzhzh 2012-08-26 22:16:59 +08:00
@limu
@skywinger @zealot 我们公司在boost::asio和muduo的基础上开发了一套蛮强悍的网络库,前几天我封了一下uri的处理,也是一个web framework了。执行效率和并发都很强悍。 我本来想自己做点东西出来,玩一玩。 但是发现他最大的问题,而你们说的都不在点子上。 字符串拼接,资源释放,正则表达都不是什么问题,closure没什么,有了boost,c++0X就可以玩一玩。 最大的问题是投入。 1 服务器的投入,php,python,ruby的空间,便宜的一抓一大把,程序移植也没什么大问题。 但是C++程序开发环境和运行环境的一致性就很头痛。 linux内核版本,glibc版本,boost版本,一个不同,他就运行不起来。 方案就是买vps,直接自己装。vps对于想要玩一玩的就相对很奢侈了。对一些前期比较拮据的小团队也很奢侈。 2 员工。 不是为了引起口水战。相同段位的C++程序员要比python,php,ruby的程序员贵。相对投入要大。 3 开发周期。 相对来说,C++相对python,ruby,php来说开发的低效才是最重要的。相同的业务逻辑用python这种动态语言开发很快,库很多,语法优雅;C++各种变量,各种类型,各种引用,指针,变量,库。头文件包含问题,编译时间时间爆长。开发起来很麻烦,产出不高。 |
11
zealot 2012-08-27 09:55:03 +08:00
@fangzhzh
“1. 服务器的投入,php,python,ruby的空间,便宜的一抓一大把。” 看来我们讨论的不是一个阶段的问题。 起步阶段:需要不断试错,探索,要点就一个字:快!产品快速迭代,不该用C++来写web前端,php/python/ruby更合适。就算是后端也应当Python/Ruby+开源软件来搭建。 成熟阶段:这时候产品成熟了,也开始赚钱了,线上堆上成千上万台服务器,性能优化1%都能带来巨额的经费节省,那么没有人会介意投入点人和时间进去搞搞C++的。而实际上,前期快速的产品迭代必然给后期留下巨大的优化空间,发展没压力时该考虑从性能上榨出利润了。 |
13
skywinger OP |
14
zealot 2012-08-27 13:31:29 +08:00
@fangzhzh
我说的第二点可以对你的第三点,但业务规模发展到每天千万、甚至过亿的PV时,人力成本占比就没那么大了,当然,依旧不建议复杂的web逻辑用C++实现,可以针对api之类的简单逻辑且调用次数庞大的业务采用C++,这样的话过于复杂且笨重的C++框架也未必合适: 成熟阶段:这时候产品成熟了,也开始赚钱了,线上堆上成千上万台服务器,性能优化1%都能带来巨额的经费节省,那么没有人会介意投入点人和时间进去搞搞C++的。而实际上,前期快速的产品迭代必然给后期留下巨大的优化空间,发展没压力时该考虑从性能上榨出利润了。 |
15
forest520 2012-08-27 13:44:04 +08:00
@fangzhzh 说的好。对于第三点,不知道你怎么看java的开发效率?因为对java更熟悉些,play框架看起来还比较易用。
|
16
zealot 2012-08-27 13:46:12 +08:00
@skywinger 重点还是在开发效率,小公司刚起步时迭代速度很重要,C++ web framework有runtime binding 及动态编译的功能也无济于事。
使用动态语言,可以马上拥有庞大且成熟的开发库,包括模版引擎、ORM、Auth集成、权限管理、甚至是开源的SNS/电子商务网站等等,这些是C++真正缺乏也没必要拥有的特性。当然如果真在C++里面把这些功能全集成进去时,性能也会大打折扣,选择C++意义就不大。 小公司起步时就一个字:快! 至于性能问题不应该优先考虑C++,而是考虑找些资深的Python/Ruby/PHP工程师。 产品都没定型,业务模式还没想清楚时,就不应该想C++还是Python,而应当考虑下个A/B Testing有什么办法能快点发布,尽早验证想法和方向。 |
18
zealot 2012-08-27 14:09:15 +08:00
@skywinger 我不知道怎么建议,如果是我的话,会优先选择开源的,比如Sphinx等,毕竟用户需要的是产品,而不是C++/Python之类的东西。
产品演化过程中,有必要的话,可以改进开源工具,既节省了自己从头开始研发的时间成本,也能给社区做出回馈。比如Twitter之前采用Lucene,后来因为实时性的特殊需求而在Lucene之上做改进。 等到有一天开源工具彻底不能满足需求时,也应该有钱、有时间去自行研发定制化的搜索引擎了。 |
20
shiweifu 2012-08-27 15:15:17 +08:00
c++ 都忍了,为啥不上openresty?
|
21
fangzhzh 2012-08-27 16:36:24 +08:00 1
|
22
zealot 2012-08-27 20:28:02 +08:00
@skywinger Google那不一样
好比你现在要去北京可以坐飞机,即使去太空砸点钱也能买到一张商业太空飞船的票。但是去火星的话,就只能自己造飞船了。 |
23
xuan_lengyue 2012-08-27 22:10:01 +08:00
照这样说,其实Objective-C倒是蛮适合用来做Web Framework的。
|