c******n
发帖数: 4965 | 1 mysql mysql 一直就试图在小马dorm 的时代的架构不断patch patch, mysql+memcache
+ php 到现在都没有变。
说实在的他们弄那个hiphop 看起来很fancy， 其实实在是在一个错误的大方向下面的
无奈选择。 现在web framework 那么多， natively 性能超过hiphop generated code
肯定有， 就不用麻烦过一遍hiphop 了 |
s**x
发帖数: 7506 | |
l******n
发帖数: 648 | 3 FB内部hackish成风
就这个风格
短期还凑合
长久恐怕有问题
memcache
code
【在 c******n 的大作中提到】
: mysql mysql 一直就试图在小马dorm 的时代的架构不断patch patch, mysql+memcache
: + php 到现在都没有变。
: 说实在的他们弄那个hiphop 看起来很fancy， 其实实在是在一个错误的大方向下面的
: 无奈选择。 现在web framework 那么多， natively 性能超过hiphop generated code
: 肯定有， 就不用麻烦过一遍hiphop 了
|
b**********5
发帖数: 7881 | 4 现在web framework 那么多， natively 性能超过hiphop generated code肯定有
那你举个例子呢。。。
memcache
code
【在 c******n 的大作中提到】
: mysql mysql 一直就试图在小马dorm 的时代的架构不断patch patch, mysql+memcache
: + php 到现在都没有变。
: 说实在的他们弄那个hiphop 看起来很fancy， 其实实在是在一个错误的大方向下面的
: 无奈选择。 现在web framework 那么多， natively 性能超过hiphop generated code
: 肯定有， 就不用麻烦过一遍hiphop 了
|
p*****2
发帖数: 21240 | 5 node和go？
【在 b**********5 的大作中提到】
: 现在web framework 那么多， natively 性能超过hiphop generated code肯定有
: 那你举个例子呢。。。
:
: memcache
: code
|
p*****2
发帖数: 21240 | 6 我以前听他们tech talk就这感觉
memcache
code
【在 c******n 的大作中提到】
: mysql mysql 一直就试图在小马dorm 的时代的架构不断patch patch, mysql+memcache
: + php 到现在都没有变。
: 说实在的他们弄那个hiphop 看起来很fancy， 其实实在是在一个错误的大方向下面的
: 无奈选择。 现在web framework 那么多， natively 性能超过hiphop generated code
: 肯定有， 就不用麻烦过一遍hiphop 了
|
d****n
发帖数: 12461 | 7 fb就是hacker culture。不过你仔细研究过几个成长型科技公司以后就会发现，hacker
culture其实是一种很牛的战略。 |
f*******t
发帖数: 7549 | 8 呃，楼主不了解FB，现在已经没人用过渡产品hiphop了。
当年FB两边一齐搞，hiphop短期能做出来，就先用上了；同时也在做类似于JVM的项目
hhvm，几年前已经替换掉hiphop。
而现在为了更好的优化php执行性能，又把php变成静态类型语言hack。
FB的infrastructure一直在进化，主要很多东西自己用着方便，比如scuba，但技术上
并没有特别大的亮点，所以外界关注没那么多了。 |
N*****m
发帖数: 42603 | 9 scuba开源没？
【在 f*******t 的大作中提到】
: 呃，楼主不了解FB，现在已经没人用过渡产品hiphop了。
: 当年FB两边一齐搞，hiphop短期能做出来，就先用上了；同时也在做类似于JVM的项目
: hhvm，几年前已经替换掉hiphop。
: 而现在为了更好的优化php执行性能，又把php变成静态类型语言hack。
: FB的infrastructure一直在进化，主要很多东西自己用着方便，比如scuba，但技术上
: 并没有特别大的亮点，所以外界关注没那么多了。
|
l*****z
发帖数: 3022 | 10 技术控就是看不到实质，任何牛的公司都是business model牛，技术是次要的。
Bloomberg用的还是上世纪80年代的技术，并不妨碍钱滚滚来
memcache
code
【在 c******n 的大作中提到】
: mysql mysql 一直就试图在小马dorm 的时代的架构不断patch patch, mysql+memcache
: + php 到现在都没有变。
: 说实在的他们弄那个hiphop 看起来很fancy， 其实实在是在一个错误的大方向下面的
: 无奈选择。 现在web framework 那么多， natively 性能超过hiphop generated code
: 肯定有， 就不用麻烦过一遍hiphop 了
|
|
|
c******n
发帖数: 4965 | 11 hhvm 是什么？ “hiphopvm"! 我的理解是里面 code base 跟 hip hop 一样的， 只
不过是 interpret mode 运行，其实就是重写了一个 PHP interpreter, 或许性能比现
有的 interpreter 强， 但是如果直接用 JVM language (java , Scala ) 会不会更快
呢？ 我的意思是， 当时拘泥于 PHP 这个 low-entry barrier 的技术， 可以雇到更
多 developer (或者更可能的原因是小马不会别的， 又不愿学， 结果拉所以人跟他一
起背这个 tech debt) 长痛不如短痛， 早换 java 长期看的 investment 要比现在在
PHP 这个破车上花的功夫小的多
【在 f*******t 的大作中提到】
: 呃，楼主不了解FB，现在已经没人用过渡产品hiphop了。
: 当年FB两边一齐搞，hiphop短期能做出来，就先用上了；同时也在做类似于JVM的项目
: hhvm，几年前已经替换掉hiphop。
: 而现在为了更好的优化php执行性能，又把php变成静态类型语言hack。
: FB的infrastructure一直在进化，主要很多东西自己用着方便，比如scuba，但技术上
: 并没有特别大的亮点，所以外界关注没那么多了。
|
c******n
发帖数: 4965 | 12 没错 但现在就是单独就技术讨论。
火的公司大部分都很糙快猛， 比如 uber
【在 l*****z 的大作中提到】
: 技术控就是看不到实质，任何牛的公司都是business model牛，技术是次要的。
: Bloomberg用的还是上世纪80年代的技术，并不妨碍钱滚滚来
:
: memcache
: code
|
s********k
发帖数: 6180 | 13 现在的很多语言工具其实也有点像CPU这样的硬件，大多数任务完全过剩，不管hack质
量低，只要产品好也比well written的code有用啊。
hacker
【在 d****n 的大作中提到】
: fb就是hacker culture。不过你仔细研究过几个成长型科技公司以后就会发现，hacker
: culture其实是一种很牛的战略。
|
g*****g
发帖数: 34805 | 14 FB这条路走得比较奇怪。大部分公司都是上来快糙猛，PHP, Python, Ruby单应用走天
下。做大之后走 SOA, 慢慢把商业逻辑用JVM语言重写，前端代码可以保留。
FB能跟PHP生抗一方面是技术牛，另一方面从长线来看并不占便宜。走主流路线自己要
做的轮子少，业界熟手多。
【在 f*******t 的大作中提到】
: 呃，楼主不了解FB，现在已经没人用过渡产品hiphop了。
: 当年FB两边一齐搞，hiphop短期能做出来，就先用上了；同时也在做类似于JVM的项目
: hhvm，几年前已经替换掉hiphop。
: 而现在为了更好的优化php执行性能，又把php变成静态类型语言hack。
: FB的infrastructure一直在进化，主要很多东西自己用着方便，比如scuba，但技术上
: 并没有特别大的亮点，所以外界关注没那么多了。
|
s********k
发帖数: 6180 | 15 是不是也是内部博弈的结果，做PHP的解释器，能够最大化的呈现工程部门或者有些高
手的能力，比起四平八稳的选择更能让部分人快速上位？
【在 g*****g 的大作中提到】
: FB这条路走得比较奇怪。大部分公司都是上来快糙猛，PHP, Python, Ruby单应用走天
: 下。做大之后走 SOA, 慢慢把商业逻辑用JVM语言重写，前端代码可以保留。
: FB能跟PHP生抗一方面是技术牛，另一方面从长线来看并不占便宜。走主流路线自己要
: 做的轮子少，业界熟手多。
|
c******n
发帖数: 4965 | 16 是啊， 体现了高层技术总监的傻逼本质, 没能控制方向
就跟国内盖房子一样， 盖了拆 拆了盖， 施工队才能赚钱， 政府官员才有 GDP
【在 s********k 的大作中提到】
: 是不是也是内部博弈的结果，做PHP的解释器，能够最大化的呈现工程部门或者有些高
: 手的能力，比起四平八稳的选择更能让部分人快速上位？
|
z*******o
发帖数: 4773 | 17 又不是大规模计算，速度不是问题。顶多加点机器。
语言易用好读，节省马工时间更关键。马工费用比机器大多了。 |
f*******t
发帖数: 7549 | 18 php都在前端，后端各种C++ Java，脚本很多python。
我觉得语言并没有想象中重要，很多时候程序员写出质量差的代码，寥寥几行就可以把
global CPU usage提高1个百分点。
FB主要把力气花在两个方面，把php变成静态类型语言，狠抓dev破坏性能的代码（
profile后能精确到diff，现在android app也用上了这个），我觉得方向是正确的。花
大力气全部用java重写SOA架构并没有太多好处。
【在 g*****g 的大作中提到】
: FB这条路走得比较奇怪。大部分公司都是上来快糙猛，PHP, Python, Ruby单应用走天
: 下。做大之后走 SOA, 慢慢把商业逻辑用JVM语言重写，前端代码可以保留。
: FB能跟PHP生抗一方面是技术牛，另一方面从长线来看并不占便宜。走主流路线自己要
: 做的轮子少，业界熟手多。
|
s********k
发帖数: 6180 | 19 FB主要把力气花在两个方面，把php变成静态类型语言，狠抓dev破坏性能的代码（
profile后能精确到diff
FB是一个大trunk还是很多不同code base？能做到这点，如果反馈很快的话还是很牛的
【在 f*******t 的大作中提到】
: php都在前端，后端各种C++ Java，脚本很多python。
: 我觉得语言并没有想象中重要，很多时候程序员写出质量差的代码，寥寥几行就可以把
: global CPU usage提高1个百分点。
: FB主要把力气花在两个方面，把php变成静态类型语言，狠抓dev破坏性能的代码（
: profile后能精确到diff，现在android app也用上了这个），我觉得方向是正确的。花
: 大力气全部用java重写SOA架构并没有太多好处。
|
g*****g
发帖数: 34805 | 20 现在重写当然工作量太大，但从开始转 SOA到现在我估计至少90%的代码是新的或者重
写的。所以 PHP语言上的工作量纯粹是多余的。
【在 f*******t 的大作中提到】
: php都在前端，后端各种C++ Java，脚本很多python。
: 我觉得语言并没有想象中重要，很多时候程序员写出质量差的代码，寥寥几行就可以把
: global CPU usage提高1个百分点。
: FB主要把力气花在两个方面，把php变成静态类型语言，狠抓dev破坏性能的代码（
: profile后能精确到diff，现在android app也用上了这个），我觉得方向是正确的。花
: 大力气全部用java重写SOA架构并没有太多好处。
|
|
|
f*******t
发帖数: 7549 | 21 大trunk
【在 s********k 的大作中提到】
: FB主要把力气花在两个方面，把php变成静态类型语言，狠抓dev破坏性能的代码（
: profile后能精确到diff
: FB是一个大trunk还是很多不同code base？能做到这点，如果反馈很快的话还是很牛的
|
f*******t
发帖数: 7549 | 22 SOA丢失了hack精神，文化不对。员工变成螺丝钉，大家不爽
【在 g*****g 的大作中提到】
: 现在重写当然工作量太大，但从开始转 SOA到现在我估计至少90%的代码是新的或者重
: 写的。所以 PHP语言上的工作量纯粹是多余的。
|
D*******a
发帖数: 3688 | 23 内部认为php monorepo其实是强项：
1. 大部分需要高强度运算，内存或者io的东西，基本已经分出去了。
2. 剩下的主要是商业逻辑。这些东西互相通过网络调用，还不如就在一个process里面
直接调用。而且fb的规模，要是全面SOA，对dc网络负担很大，latency不好控制。
3. 统一的release management降低风险。
4. 做产品的新手比较容易上手，不需要处理很多运营service的负担。
语言本身不重要
【在 g*****g 的大作中提到】
: 现在重写当然工作量太大，但从开始转 SOA到现在我估计至少90%的代码是新的或者重
: 写的。所以 PHP语言上的工作量纯粹是多余的。
|
r****7
发帖数: 2282 | 24 re
百度的UI模块还都是C写的呢，不照样好好的，纠缠语言本身太junior了
【在 D*******a 的大作中提到】
: 内部认为php monorepo其实是强项：
: 1. 大部分需要高强度运算，内存或者io的东西，基本已经分出去了。
: 2. 剩下的主要是商业逻辑。这些东西互相通过网络调用，还不如就在一个process里面
: 直接调用。而且fb的规模，要是全面SOA，对dc网络负担很大，latency不好控制。
: 3. 统一的release management降低风险。
: 4. 做产品的新手比较容易上手，不需要处理很多运营service的负担。
: 语言本身不重要
|
g*****g
发帖数: 34805 | 25 统一的release management提高了风险，妨碍了开发进度。一个show blocker就必须全
盘rollback。不同team不能以自己的进度来发布，出了问题找源头需要花更多的时间。
Continuous Delivery更是不可能。Monolithic vs. Microservices有很多文献可以参
考。
【在 D*******a 的大作中提到】
: 内部认为php monorepo其实是强项：
: 1. 大部分需要高强度运算，内存或者io的东西，基本已经分出去了。
: 2. 剩下的主要是商业逻辑。这些东西互相通过网络调用，还不如就在一个process里面
: 直接调用。而且fb的规模，要是全面SOA，对dc网络负担很大，latency不好控制。
: 3. 统一的release management降低风险。
: 4. 做产品的新手比较容易上手，不需要处理很多运营service的负担。
: 语言本身不重要
|
g*****g
发帖数: 34805 | 26 什么语言都能做，但有开发效率的区别。自己做一套轮子看着很酷，但并不给生意带来
任何附加价值。
【在 r****7 的大作中提到】
: re
: 百度的UI模块还都是C写的呢，不照样好好的，纠缠语言本身太junior了
|
f*****d
发帖数: 2285 | 27 FB主要靠Business Model。现在谁都可以建一个social network，关键是看有没有人用。
比如Snapchat，就是基于Google Cloud Platform建立的social networks
现在不需要技术，只要产品有用户，就是牛！ |
i*****h
发帖数: 1534 | 28 看fb招人职位贴出来的description，感觉好多职位用的技术不是很新啊，为什么人人
都想去呢？ |
r****7
发帖数: 2282 | 29 通用和专用本来就是dilemma吧，所以就看公司的研发能力了。
【在 g*****g 的大作中提到】
: 什么语言都能做，但有开发效率的区别。自己做一套轮子看着很酷，但并不给生意带来
: 任何附加价值。
|
n*o
发帖数: 442 | 30 FB本来就不是靠技术吃饭的公司。想学技术还是去狗狗或者AWS. |
|
|
g*********e
发帖数: 14401 | |
m****u
发帖数: 3915 | 32 php不说了，你能说说mysql＋memcache有啥不好？
memcache
code
【在 c******n 的大作中提到】
: mysql mysql 一直就试图在小马dorm 的时代的架构不断patch patch, mysql+memcache
: + php 到现在都没有变。
: 说实在的他们弄那个hiphop 看起来很fancy， 其实实在是在一个错误的大方向下面的
: 无奈选择。 现在web framework 那么多， natively 性能超过hiphop generated code
: 肯定有， 就不用麻烦过一遍hiphop 了
|
l****t
发帖数: 228 | 33 看看twitter用java重写soa花了多久 就觉得fb这路走得其实还不错
【在 g*****g 的大作中提到】
: FB这条路走得比较奇怪。大部分公司都是上来快糙猛，PHP, Python, Ruby单应用走天
: 下。做大之后走 SOA, 慢慢把商业逻辑用JVM语言重写，前端代码可以保留。
: FB能跟PHP生抗一方面是技术牛，另一方面从长线来看并不占便宜。走主流路线自己要
: 做的轮子少，业界熟手多。
|
f*******t
发帖数: 7549 | 34 diversity带来了更多生产力的潜力。java soa确实是work的，但它是不是最优的有待
商榷，何况你说的好像大公司重写成这个才对
【在 g*****g 的大作中提到】
: 什么语言都能做，但有开发效率的区别。自己做一套轮子看着很酷，但并不给生意带来
: 任何附加价值。
|
g*****g
发帖数: 34805 | 35 这不是对错的区别，而是成本和难易的区别。
【在 f*******t 的大作中提到】
: diversity带来了更多生产力的潜力。java soa确实是work的，但它是不是最优的有待
: 商榷，何况你说的好像大公司重写成这个才对
|
p*****2
发帖数: 21240 | 36 从哪里调查的人人都想去？
【在 i*****h 的大作中提到】
: 看fb招人职位贴出来的description，感觉好多职位用的技术不是很新啊，为什么人人
: 都想去呢？
|
t********e
发帖数: 1169 | |
z*******3
发帖数: 13709 | 38 重新搞一套eco，一般公司承受不了
也就是apple, fb这种大公司有这个条件
一个llvm，一个hhvm，本质上跟jvm有相似的地方
google干脆就是抄了jvm的hotspot搞了dalvik
还有m$的clr之类的，主要搞vm这种东西难度一点不比os低
很容易失败不说，就算做出来了，上面的轮子还需要大量时间去建设
这一来二去，各种开销花费可不少
【在 f*******t 的大作中提到】
: diversity带来了更多生产力的潜力。java soa确实是work的，但它是不是最优的有待
: 商榷，何况你说的好像大公司重写成这个才对
|
z*******3
发帖数: 13709 | 39 还不如拿去做手机
【在 g*********e 的大作中提到】
: 搞网站需要鸟技术？又不是做导弹
|
y****r
发帖数: 211 | 40 有点纸上谈兵了。事实是FB的CI/CD做的比绝大多数(如果不是所有)java的公司都好。
【在 g*****g 的大作中提到】
: 统一的release management提高了风险，妨碍了开发进度。一个show blocker就必须全
: 盘rollback。不同team不能以自己的进度来发布，出了问题找源头需要花更多的时间。
: Continuous Delivery更是不可能。Monolithic vs. Microservices有很多文献可以参
: 考。
|
|
|
n******n
发帖数: 12088 | 41 什么是CI/CD？
【在 y****r 的大作中提到】
: 有点纸上谈兵了。事实是FB的CI/CD做的比绝大多数(如果不是所有)java的公司都好。
|
g*****g
发帖数: 34805 | 42 都Monolithic了做不了CD。除非前面那位FB同学传递的信息不准确。CI可以做，但是应
用太大，跑测试时间很长。
【在 y****r 的大作中提到】
: 有点纸上谈兵了。事实是FB的CI/CD做的比绝大多数(如果不是所有)java的公司都好。
|
y****r
发帖数: 211 | 43 你被java限制了想象力。不过不怪你，我进fb之前也是十几年java经验，理解你在想什
么。
【在 g*****g 的大作中提到】
: 都Monolithic了做不了CD。除非前面那位FB同学传递的信息不准确。CI可以做，但是应
: 用太大，跑测试时间很长。
|
g*****g
发帖数: 34805 | 44 你不如来点有营养的东西，架构又不是商业机密。microservice vs. monolith跟语言
完全没有关系。
你要说不清楚要不就解释个简单的就好，单一应用，发现blocker需要rollback，如何
不影响其他team没问题的feature。不要跟我说feature flag.
【在 y****r 的大作中提到】
: 你被java限制了想象力。不过不怪你，我进fb之前也是十几年java经验，理解你在想什
: 么。
|
y****r
发帖数: 211 | 45 跟语言的语法没关系，跟build, test, 和deployment的速度有关系。FB的webapp要是
用java来写成一个big monolitic application, mvn install一遍起码得一个小时，
release management当然成问题。FB的webapp现在一台普通的server上一两分钟就能
build完。明白了吗?
一个大的code base出了问题怎么办? 很简单。第一，自动测试避免出问题，第二，出
了问题，马上fix。就这样。
你信也好，不信也好，FB的www code base就是几千人check in, 而且so far 还work。
你非要说它行不通，就没意思了。
【在 g*****g 的大作中提到】
: 你不如来点有营养的东西，架构又不是商业机密。microservice vs. monolith跟语言
: 完全没有关系。
: 你要说不清楚要不就解释个简单的就好，单一应用，发现blocker需要rollback，如何
: 不影响其他team没问题的feature。不要跟我说feature flag.
|
g*****g
发帖数: 34805 | 46 编得快当然好。你这一两分钟包括了所有自动化测试？至于你说的后者，就自欺欺人了
。自动化测试不可能避免所有的问题。出bug马上fix也是不可能的，有时候一个bug影
响面很大，就算一个小时能fix损失都很大，只能一发现马上rollback. 更糟糕的是你
想rollback发现你的dependency已经改动而且不向后兼容了，这时候不rollback与其说
你能马上fix，不如说你没有rollback的选择。
你说的只不过是一些常规的尽量避免问题的办法，但没有解决问题。我们不过几百个
engineer，上千个microservice，平均每个工作日部署到产品环境上百次。你们前端几
千人
checkin，我很好奇每天能够部署多少次？
【在 y****r 的大作中提到】
: 跟语言的语法没关系，跟build, test, 和deployment的速度有关系。FB的webapp要是
: 用java来写成一个big monolitic application, mvn install一遍起码得一个小时，
: release management当然成问题。FB的webapp现在一台普通的server上一两分钟就能
: build完。明白了吗?
: 一个大的code base出了问题怎么办? 很简单。第一，自动测试避免出问题，第二，出
: 了问题，马上fix。就这样。
: 你信也好，不信也好，FB的www code base就是几千人check in, 而且so far 还work。
: 你非要说它行不通，就没意思了。
|
c******n
发帖数: 4965 | 47 Netflix 以前也是 一个很大的 jar ebay 是一个大的 c++ binary 跟语言无关。
很难想象今天还有人这么搞， 一看就是补丁套补丁的结果。 非 online 的软件， 像
Linux kernel 你这么搞可以， 有无数的 test 时间， 有人统一安排 release, 但你
敢想象 Linux 每天 release 一个 bug fix/new feature ? 在 大 包的 模式下不可能
【在 g*****g 的大作中提到】
: 编得快当然好。你这一两分钟包括了所有自动化测试？至于你说的后者，就自欺欺人了
: 。自动化测试不可能避免所有的问题。出bug马上fix也是不可能的，有时候一个bug影
: 响面很大，就算一个小时能fix损失都很大，只能一发现马上rollback. 更糟糕的是你
: 想rollback发现你的dependency已经改动而且不向后兼容了，这时候不rollback与其说
: 你能马上fix，不如说你没有rollback的选择。
: 你说的只不过是一些常规的尽量避免问题的办法，但没有解决问题。我们不过几百个
: engineer，上千个microservice，平均每个工作日部署到产品环境上百次。你们前端几
: 千人
: checkin，我很好奇每天能够部署多少次？
|
g****y
发帖数: 1172 | 48 楼上两位长老，别吵了，赶快收了神通吧。。
【在 g*****g 的大作中提到】
: 编得快当然好。你这一两分钟包括了所有自动化测试？至于你说的后者，就自欺欺人了
: 。自动化测试不可能避免所有的问题。出bug马上fix也是不可能的，有时候一个bug影
: 响面很大，就算一个小时能fix损失都很大，只能一发现马上rollback. 更糟糕的是你
: 想rollback发现你的dependency已经改动而且不向后兼容了，这时候不rollback与其说
: 你能马上fix，不如说你没有rollback的选择。
: 你说的只不过是一些常规的尽量避免问题的办法，但没有解决问题。我们不过几百个
: engineer，上千个microservice，平均每个工作日部署到产品环境上百次。你们前端几
: 千人
: checkin，我很好奇每天能够部署多少次？
|
T******g
发帖数: 21328 | 49 kernel是必须随时online的，现在有动态打补丁的方法，以前必须reboot的
【在 c******n 的大作中提到】
: Netflix 以前也是 一个很大的 jar ebay 是一个大的 c++ binary 跟语言无关。
: 很难想象今天还有人这么搞， 一看就是补丁套补丁的结果。 非 online 的软件， 像
: Linux kernel 你这么搞可以， 有无数的 test 时间， 有人统一安排 release, 但你
: 敢想象 Linux 每天 release 一个 bug fix/new feature ? 在 大 包的 模式下不可能
|
g*****g
发帖数: 34805 | 50 http://www.infoq.com/presentations/migration-cloud-native
有兴趣的可以看看Andrian Cockcroft在QCon上的presentation。其中有一部分就在比
较Microservice v.s Monolith |
|
|
z****e
发帖数: 54598 | |
z*******o
发帖数: 4773 | 52 release的时候出bug居然要fix，
立即rollback之后都要出事故报告。 |
s*****m
发帖数: 8094 | 53 凑合吧，youtube也这个操行，不一样活的好好的？人还是用python在玩的。
startup比这个恐怖的不要太多啊。
memcache
code
【在 c******n 的大作中提到】
: mysql mysql 一直就试图在小马dorm 的时代的架构不断patch patch, mysql+memcache
: + php 到现在都没有变。
: 说实在的他们弄那个hiphop 看起来很fancy， 其实实在是在一个错误的大方向下面的
: 无奈选择。 现在web framework 那么多， natively 性能超过hiphop generated code
: 肯定有， 就不用麻烦过一遍hiphop 了
|
s*****m
发帖数: 8094 | 54
不全是，但基本意思是对的。难道这不值得google反思么？
【在 c******n 的大作中提到】
: 没错 但现在就是单独就技术讨论。
: 火的公司大部分都很糙快猛， 比如 uber
|
s*****m
发帖数: 8094 | 55 用php玩是有点过了
【在 c******n 的大作中提到】
: 是啊， 体现了高层技术总监的傻逼本质, 没能控制方向
: 就跟国内盖房子一样， 盖了拆 拆了盖， 施工队才能赚钱， 政府官员才有 GDP
|
s*****m
发帖数: 8094 | 56 php好读？imo这鸡巴玩意儿挺自虐的。
【在 z*******o 的大作中提到】
: 又不是大规模计算，速度不是问题。顶多加点机器。
: 语言易用好读，节省马工时间更关键。马工费用比机器大多了。
|
s*****m
发帖数: 8094 | 57 什么东西都有个度，语言不太重要，但也不应该是随便来。
易维护性还是非常重要的。
【在 r****7 的大作中提到】
: re
: 百度的UI模块还都是C写的呢，不照样好好的，纠缠语言本身太junior了
|
s*****m
发帖数: 8094 | 58 光有用户当然不够，用户又不直接花钱。
有用户不赚钱的多了去了。
用。
【在 f*****d 的大作中提到】
: FB主要靠Business Model。现在谁都可以建一个social network，关键是看有没有人用。
: 比如Snapchat，就是基于Google Cloud Platform建立的social networks
: 现在不需要技术，只要产品有用户，就是牛！
|
d****i
发帖数: 4809 | 59 你完全错了，FB这种是叫做"不装逼“，坚守码工传统和文化，就是用传统的PHP和LAMP
架构又如何，照样做出十几亿人的大规模网站出来，财源滚滚来，盈利暴涨。反观FB的
竞争对手twitter,就是喜欢装逼，先用喜欢玩装逼的Ruby，用什么欧洲左逼发明的装逼
的scala，最后输得连逼都捅烂了。
memcache
code
【在 c******n 的大作中提到】
: mysql mysql 一直就试图在小马dorm 的时代的架构不断patch patch, mysql+memcache
: + php 到现在都没有变。
: 说实在的他们弄那个hiphop 看起来很fancy， 其实实在是在一个错误的大方向下面的
: 无奈选择。 现在web framework 那么多， natively 性能超过hiphop generated code
: 肯定有， 就不用麻烦过一遍hiphop 了
|
t********e
发帖数: 1169 | |
|
|
f*******t
发帖数: 7549 | 61 Re
LAMP
【在 d****i 的大作中提到】
: 你完全错了，FB这种是叫做"不装逼“，坚守码工传统和文化，就是用传统的PHP和LAMP
: 架构又如何，照样做出十几亿人的大规模网站出来，财源滚滚来，盈利暴涨。反观FB的
: 竞争对手twitter,就是喜欢装逼，先用喜欢玩装逼的Ruby，用什么欧洲左逼发明的装逼
: 的scala，最后输得连逼都捅烂了。
:
: memcache
: code
|
s**x
发帖数: 7506 | 62 这个讨论挺有意思。还是细分的好。成长太快，总会带来一些影响。work 的东西未必
最好，最好的未必 work。梦想跟现实的差距。 |
