e****e
发帖数: 677 | |
r*g
发帖数: 186 | 2 我觉得新标准下c++越来越好用了
如果stl早出来几年
现在也不会这么被唱衰
【在 e****e 的大作中提到】
: RT
|
n******7
发帖数: 12463 | 3 学习c++只学新标准行不行？
感觉这样会看不懂别人的代码
【在 r*g 的大作中提到】
: 我觉得新标准下c++越来越好用了
: 如果stl早出来几年
: 现在也不会这么被唱衰
|
T******7
发帖数: 1419 | 4 不够
大多数代码还是老风格。
【在 n******7 的大作中提到】
: 学习c++只学新标准行不行？
: 感觉这样会看不懂别人的代码
|
d****i
发帖数: 4809 | 5 对于大部分系统编程来说，ANSI C89加上C++98已经足够，但是如果是应用的话，当数
据结构变得复杂和抽象的时候，新的标准C++11增添了很多便利。
【在 T******7 的大作中提到】
: 不够
: 大多数代码还是老风格。
|
n******7
发帖数: 12463 | 6 我猜想也是这样
那还是要熟悉老标准
新标准带来的好处就有限了
【在 T******7 的大作中提到】
: 不够
: 大多数代码还是老风格。
|
g*****g
发帖数: 34805 | 7 哪看到的？L 没有可能。A也没有可能。
【在 e****e 的大作中提到】
: RT
|
Y**G
发帖数: 1089 | 8 c++唯一的好处就是没有GC,不会间歇性的僵住。
【在 e****e 的大作中提到】
: RT
|
z****e
发帖数: 54598 | 9 快给我拉倒
baidu都是hadoop，你说c++职位多？
alibaba是sun搭建的总构架，你说c++职位多？
我以前宿舍四个人，其他三个分别在bat
就腾讯有点c的工作，主要是尾大不掉，现在想换也换不了
另外两个用java用的那叫一个如火如荼
要不要我给你内推一下bat啊？ |
z****e
发帖数: 54598 | 10 坏处也是没有gc，随便一个不小心，整个系统就挂了
gc也不是全然没有办法，现在分布式系统，反正网络的latency也很高
gc一次控制在一定时间内，其实跟你公网上的latency差不了多少
如果pool起来的话，小gc几乎感觉不到，大gc要看内存大小
如果放100g进去，大gc还是会停比较久的，所以要切割成一小块一小块
然后用chaos monkey进去砸一顿，看看系统健壮程度
一个特别庞大的机器不是future，分布式才是future
hpc，mainframe这种迟早进垃圾堆
【在 Y**G 的大作中提到】
: c++唯一的好处就是没有GC,不会间歇性的僵住。
|
|
|
g*********e
发帖数: 14401 | 11 l也看组的 sna下面现在新产品都用cxx了
【在 g*****g 的大作中提到】
: 哪看到的？L 没有可能。A也没有可能。
|
g*********e
发帖数: 14401 | 12 普通的网页没问题 infra的东西qps很高，全公司都来call你。 减少gc的时间和频率
是非常重要的 没gc更好
【在 z****e 的大作中提到】
: 坏处也是没有gc，随便一个不小心，整个系统就挂了
: gc也不是全然没有办法，现在分布式系统，反正网络的latency也很高
: gc一次控制在一定时间内，其实跟你公网上的latency差不了多少
: 如果pool起来的话，小gc几乎感觉不到，大gc要看内存大小
: 如果放100g进去，大gc还是会停比较久的，所以要切割成一小块一小块
: 然后用chaos monkey进去砸一顿，看看系统健壮程度
: 一个特别庞大的机器不是future，分布式才是future
: hpc，mainframe这种迟早进垃圾堆
|
z****e
发帖数: 54598 | 13 所以最后做的领域还是infra，用go吧
java等gc语言做infra从来就是一般般，一般都是冲着应用面去的
big data，ml这些就是应用面，cloud比较接近infra，cloud上开发用go也比较多
【在 g*********e 的大作中提到】
: 普通的网页没问题 infra的东西qps很高，全公司都来call你。 减少gc的时间和频率
: 是非常重要的 没gc更好
|
g*****g
发帖数: 34805 | 14 scale大的话，不同结点同时 GC的概率很低，即使timeout retry 会 hit不同结点，所
以基本不是问题。
【在 g*********e 的大作中提到】
: 普通的网页没问题 infra的东西qps很高，全公司都来call你。 减少gc的时间和频率
: 是非常重要的 没gc更好
|
e****e
发帖数: 677 | 15 就算alibaba，里面c++职位也就比java少1/3而已
【在 g*****g 的大作中提到】
: 哪看到的？L 没有可能。A也没有可能。
|
g*****g
发帖数: 34805 | 16 你这不是自己打脸吗？
【在 e****e 的大作中提到】
: 就算alibaba，里面c++职位也就比java少1/3而已
|
e****e
发帖数: 677 | 17 问题是 alibaba是java大本营啊
而Baidu tencent 是c++大本营
【在 g*****g 的大作中提到】
: 你这不是自己打脸吗？
|
g*********e
发帖数: 14401 | 18 你不可能因为gc而retry
【在 g*****g 的大作中提到】
: scale大的话，不同结点同时 GC的概率很低，即使timeout retry 会 hit不同结点，所
: 以基本不是问题。
|
z****e
发帖数: 54598 | 19 别逗了，baidu要是没有hadoop，丫早就嗝屁了
【在 e****e 的大作中提到】
: 问题是 alibaba是java大本营啊
: 而Baidu tencent 是c++大本营
|
z****e
发帖数: 54598 | 20 网络不知道对方到底是因为什么而无应答
只要没有响应，就会找其他nodes retry
gc只是其中一种，还有各种丢包啥的，情况很多
分布式就需要考虑这种failure的可能性
【在 g*********e 的大作中提到】
: 你不可能因为gc而retry
|
|
|
g*****g
发帖数: 34805 | 21 当然可以，我们后端的服务用的同样的rest client，缺省的设置就是5秒timeout, 3次
重试。一旦一个stop world gc导致超时立马就自动重试，重试hit的基本不会是同一个
结点。
就算1%的request因为各种非bug原因可能没响应，这个简单策略立马降到0.01%以下。
你还可
以拿历史数据来调cutoff以提高响应时间。
【在 g*********e 的大作中提到】
: 你不可能因为gc而retry
|
w**z
发帖数: 8232 | 22 5秒对一般service timeout 都太长了吧。
【在 g*****g 的大作中提到】
: 当然可以，我们后端的服务用的同样的rest client，缺省的设置就是5秒timeout, 3次
: 重试。一旦一个stop world gc导致超时立马就自动重试，重试hit的基本不会是同一个
: 结点。
: 就算1%的request因为各种非bug原因可能没响应，这个简单策略立马降到0.01%以下。
: 你还可
: 以拿历史数据来调cutoff以提高响应时间。
|
g*****g
发帖数: 34805 | 23 看前端后端，非 UI触发的操作可以接受。很多后端操作是批处理，处理的时间相对长
。反正是 client决定的。
【在 w**z 的大作中提到】
: 5秒对一般service timeout 都太长了吧。
|
