V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  lesismal  ›  全部回复第 54 页 / 共 63 页
回复总数  1248
1 ... 46  47  48  49  50  51  52  53  54  55 ... 63  
2021-07-09 00:25:05 +08:00
回复了 Mark24 创建的主题 程序员 技术栈的选择没什么好纠结的
@Mark24 #10
我在前面给出了这句:"除非自己不打算往更高层次提升、去有机会处理超大业务量级"

其他方面的楼主说了一大堆,但是兄弟,你可能没 get 到为什么那些巨头要用去换掉 py 、php 。可以搜些帖子、新闻,稍早点的 B 站用 go 重构大量服务,往前大概还有七牛、猎豹移动、滴滴、头条大量用 go,或者我上面发的那个知乎的那个改造应该是近期一两年内的,好像前年还在知乎上看到有人说知乎 py 性能垃圾然后知乎技术大佬出来回复有好方案愿意怎么样怎么样的

py 不只是国内这些巨头在海量业务时要抛弃,十几年前谷歌造 go 的时候是因为被 c++虐得快瓶颈了,再往前有点谷歌把 py 之父招到麾下了本来是打算让 py 能帮助谷歌解决很多工程上的问题,但是搞了几年,没办法,py 虽然是真的方便但也是实在太慢了,谷歌根本无法忍受 py 这种性能。
不要用 py 在大数据、AI 等领域仍旧遍地开花来解释 py 性能不是问题,你要看看 py 在这俩领域是怎么使用的——都只是胶水语言 bind 个 c++之类的接口而已。另外就是 devops 领域了,然后呢?还是主要用于非性能敏感领域的工具、简单服务。真正涉及性能的,k8s 也好,周边的 netdata 、filebeat 也好,都是 go 、java 之类的(早期很多人用 java 搞了很多东西,但是后面很多是用 go 比如 EFK 的 F 替代 ELK 的 L,因为 java 的性能和吃内存也是让人无法忍受的)

还是上面那句话:"除非自己不打算往更高层次提升、去有机会处理超大业务量级"
至于你解释的那些,兄弟,你首先得搞懂 py 自己的瓶颈是什么、为什么在那些领域被大家抛弃了,然后再来讨论时你的论据才会更具说服力,但是我相信,如果内真的去了解了那些内容,你直接就会站到我这边的观点、不需要再为 py 争取什么了。
2021-07-08 20:41:14 +08:00
回复了 Mark24 创建的主题 程序员 技术栈的选择没什么好纠结的
某乎社区核心业务 Golang 化实践
https://zhuanlan.zhihu.com/p/48039838
2021-07-08 20:36:33 +08:00
回复了 Mark24 创建的主题 程序员 技术栈的选择没什么好纠结的
"好了现在你已经知道如何去选择,或者说学习什么样子的技术框架。"
——对于 pyer 、phper 之类的服务端开发者,最正确的选择是转 go/java,除非自己不打算往更高层次提升、去有机会处理超大业务量级

看看近几年的各大明星企业大量用 go 起步或者用 go 重构的情况吧,连知乎都用 go 重构了
2021-07-04 15:21:18 +08:00
回复了 cucldk 创建的主题 云计算 aliyun 服务器本地磁盘损坏导致数据丢失问题
即使使用云盘,重要数据也应当自己备份。
并不是云的问题+1
2021-07-04 15:18:15 +08:00
回复了 James369 创建的主题 Python js 都有 worker 线程,什么时候 Python 也能增强一下线程?
出门左转,golang 欢迎你
2021-06-28 17:43:38 +08:00
回复了 eccentric579 创建的主题 汽车 大西北自驾,两个司机出现的一点争执
上联:你走你的阳关道,安全去西北
下联:他过他的奈何桥,容易上西天
横批:道不同不相为谋

如果是我,趁早散伙, :doge:
2021-06-26 18:49:37 +08:00
回复了 beexu 创建的主题 程序员 《tcp/ip 详解卷一第二版》值得花时间精读吗
值得看,看这种书需要讲究方法,否则硬啃效率低:
详解更偏学术,不好啃,可以先看图解 tcp/ip
1. wireshark 的书或资料也找些,wireshark 抓包配合着看协议栈,会容易理解和加深理解,比起只啃书事半功倍
2.《 UNP 》网络那卷最好也带上,顺便看一些系统函数和编码,加深理解
3. 《 Web 性能权威指南》也挺好,也看看吧
2021-06-25 11:50:55 +08:00
回复了 xiaoxuz 创建的主题 程序员 生成器模式-代码的艺术系列(一)
@no1xsyzy #34
设计模式之父是 GoF,他们并不承认这一策略的失败,并且似乎还在宣传?
你说 G.Alexander ?我盲猜他会认为你(称他为设计模式之父)是在侮辱他。
——按你说的这个 Gof 对 G.Alexander 的借鉴关系,我觉得 G.Alexander 才算是之父,Gof 这种坑害社区的存在,更加不配之父的名头
建筑和软件最大的共同点都是工程属性,但设计模式在软件领域的发挥威力比在建筑领域的发挥威力更加困难。
专业的建筑团队,建筑施工前画图纸、数学物理的公式计算、材料的实验、还有安全等各种流程的把控,要比软件工程规范得多,因为那都是人命关天的事。并且建筑建造完成后,日后建筑主体也不会大改。软件工程就不一样了,除了成型的领域,更新迭代太快了,而且 if else 的分之太多,多数产品出了事故也不是什么闹出人命的特大责任事故。
所以,在建筑领域这种相对更容易发挥设计优势的场景,人家的之父都承认实验失败了,软件领域却还嗨得飞起,只能说社区里有伪布道师们的市场,就像保健品、传销一样。

楼主根本就不是一个聊法,逻辑性太差,不跟他这浪费时间了
2021-06-25 00:50:41 +08:00
回复了 xiaoxuz 创建的主题 程序员 生成器模式-代码的艺术系列(一)
以上所有打字直到现在,我确实心里没什么波澜,算是平和的。
中毒这种说法是因为早年也跟不少 cpp 语言党聊过太多了,cpp 中毒太深的人过度玩弄语法语义和各种特性,cpp 里也有不少乐于搞设计模式的,一个单例能搞出 6 种还是 8 种实现。然而实际的架构设计、工程设计、算法设计、结构设计却不到位,导致日常夸夸其谈,项目问题不断。
这些多年撕得多得出的结论,而且也因为撕得多,所以早就平和了。

就像无法叫醒一个装睡的人,执着于语言特性、设计模式的好多人,也难回头,所以我称之为中毒。
经济学上讲,是因为“沉没成本效应”。在程序员这种职业上体现出来就是:自己花了不少功夫在某些知识上,舍不得承认这些知识的无用,并且继续对它学习研究,从而遮了眼、阻碍了自己的提升。
就比如设计模式吧,@no1xsyzy 见识广博,#21 里已经提到过了,设计模式之父自己都承认实际效果并不那么好。你再掰开了揉碎了仔细思考,真正有用的一些设计模式,比如观察者 /发布订阅,这种总结出来确实不错,但是大多数的设计模式真的未必有用,反倒是误以为宝贝的人,反复琢磨把玩、浪费了很多时间。比如单例模式,除了 java 这种一切皆类、必须通过实现单例或者直接 static 变量(不方法不优雅)才能使用这个公共变量的方式,其他语言基本都是一个公共变量就完事了,最多再加个显示的初始化或者作为函数返回值,让调用的方式看上去有一点虚伪的逼格而已。再比如工厂系列,最初知道这竟然是一种设计模式的时候,我都不好意思笑,多自然的一个事情,构造函数写舒服点就是工厂系列,非要整个单独的 createXX 之类的也行,设计模式之父自己都承认了一些事(我没去考证真假,但从设计模式实际的效用上讲,我觉得他应该承认过),我们大众何苦为难、作践自己呢。。。

设计模式和 go,我这么多认真回复,我觉得是“买椟还珠”,你作为卖家拿设计模式当个珠,用 go 的 demo 的盒子把它装里面了,而我是为了 go 这个盒子而来,真没 care 过设计模式

甚至于面向对象,大概 1996 年 cpp 标准委员会那帮老头子们开会就在聊“面向对象被社区滥用了呀”

再说点设计模式和面向对象的问题。社区已有的积累,可以继续吃老本,比如企业级、电商之类的,尤其是 java
但是良好的 OO 抽象体系也好、易扩展也好,在面对高速发展、快速迭代的产品和需求面前都不那么好使:
面向对象的鸭嘴兽问题,使得在很难预期大部分未来需求前提下,无法完美抽象、只能做到当下的抽象、无法做到未来的易扩展,设计模式同样,那些以为现在这样有哪些好处,未来可以怎样易于修改的好处,当不确定的未来真正到来的时候,很难发挥出其预期的优势,反倒可能因为早期的臃肿设计导致后续的修改难度更大。
真正有效的方案是进行阶段性重构。如果团队业务更新太快、疲于奔命,阶段性重构的频率就要降低、周期就要拉长,就得等到长时间日积月累后毕其功于一役。
今天为了以后易扩展做了很多更复杂的设计,明天可能因为非预期内的变化导致修改难度更大。所以像 go 这种不重语法糖特性和模式,反而专注于让事情简单化的语言,却成了工程性更好的选择

你应该能够从 go 语言本身感受到并且再深入思考一些:为什么 go 不天然面向对象?也不重设计模式?也不在意那些花哨的语法糖?
go 已经是站在那些以往优秀语言的巨人肩膀上,如果那些东西真的那么好,难道 c 爹和 rob pikez 这些老头子是老糊涂了?——这帮老头子们真的是老中医,切脉稳准狠,开出了 go 这副方子,让我一副药下肚,码欲大增、秀发得保,虽老矣,为心所愿之代码,尚可稍废寝食

然后我的疑问来了,既然用 go 了,你的意思好像又说你只写 go,那是谁带你跑偏去研习设计模式的?
把你引入歧途的人,是人性的扭曲还是道德的沦丧。。。你得喷他啊顺便把他也带回正轨。。。
2021-06-24 22:31:51 +08:00
回复了 xiaoxuz 创建的主题 程序员 生成器模式-代码的艺术系列(一)
@xiaoxuz
如果实在觉得用 go 举例子不影响看球,那多举点例子:

一把杀过人的普通菜刀赠送给邻居,邻居不会愿意要,觉得不吉利,是不是应该强调菜刀只是道具跟杀人没关系?
赵薇日本军旗,军旗只是拍时尚照道具而已,赵薇不应该被喷,军旗也没毛病?

如果道具在一切场景都可以解释成只是道具、不影响用来做什么,那这世界就不会存在忌讳了。

天不早了,晚安
2021-06-24 22:18:18 +08:00
回复了 xiaoxuz 创建的主题 程序员 生成器模式-代码的艺术系列(一)
@xiaoxuz

上一楼语气还看着正常些的,说翻脸就翻脸,淡定点。

要是真侃技术,咱就聊技术的,别扯远了,我这也一直聊的技术,别扯什么中医不中医的,你看看#18 楼你几句回复,看上去认真在回复似的,但是都是在把话题扯远了、没在正题上。

既然用 go 举例子,还不能让别人说了?而且设计模式本身的很多臃肿,并不限于 go,我从 go 开喷只是因为你用了这么臃肿的 go 代码做示范。你要说用 go 做示范但是是为了设计模式、跟 go 没丝毫关系和影响,这逻辑就像莫文蔚穿个啥乳 h 品牌然后强调自己只是打广告跟乳 h 没关系类似的道理,然后还不允许别人喷

你要是没用 go 举例子,如果我点进来看一眼是 java 我转身就走了,头都不回,因为个人不喜欢 java 觉得 java 不值得我浪费时间、毫无兴趣,但是我也不随便就喷 java,因为不只是一个人的 java 臃肿

还有不是要安利什么的说法,我在之前楼里也说过了,你都写文章这么正向推介了,还解释不是安利作何?没必要的,安利了就安利了,你认为对、拿出来大家聊,越辩越明就完事了。逻辑搞清楚点,别聊技术又不正面应对又不承认这不承认那的,也别给别人扣帽子什么中医

还有,关于私货这个,如果只是简单提起+一个链接,你说 xr 之举也就算了。但即使私货,我也带上了大段的内容,希望能有人看到、从中吸收一些知识点,对于宣传知识贡献开源而言、没什么不好意思的,做这项目也不是为了钱,到了职业年龄末段了,只是想给社区一些回馈、给自己留些念想,如果幸运能多来点人到仓库看看、用用甚至再来点 issue 、pr,那更开心了。但是说句失望的,就这么段内容,能 get 到点的人非常少,一是别人也未必认真读到我这段内容了,二是别人之前不知道这个问题相关的这么些信息,三是确实是有些难度。你反手看看其他一些异步网络库,只做自家业务比如游戏的 tcp 协议异步库也就算了,但是对于 http/websocket/tls,数千 star 那些,基本没有支持的,都是玩具。

最后,既然写文章发出来了,就要接受你的受众的反馈,既有正向的又有负向的,零差评是几乎不可能的事情,不要那么在意面子,太在意面子,即使能在面子驱动下搞好技术也气大伤身、没必要。如果实在在意,可以先内修、等心态更平和的年纪再把文章发出来
2021-06-24 18:04:10 +08:00
回复了 xiaoxuz 创建的主题 程序员 生成器模式-代码的艺术系列(一)
@xiaoxuz
现在我有主观态度了: 爱看不看,话太密! 你写 go,不能证明你可以代表所有 goer~
—— 对,这一点我非常赞同。你写你的,我认为不好的我就提出来,不让某个观点独霸市场。各有说辞,其他人看了也才能有更多思考、减小误入歧途的概率

另外夹带个私活,我自己的异步网络仓库,已经支持  http1.x/websocket/tls:
https://github.com/lesismal/nbio

以往有些老帖子,golang websocket 百万连接相关的,引入 poller 通过事件的方式控制数据读,不用为每个连接都分配一个协程,进而降低海量并发场景下协程数量过多带来的的巨大内存开销和调度成本。
这些方案对应有 gobwas/ws + easygo/netpoll 之类的框架。
但是他们都做错了,只是把 fd 加入到 poller,读事件时进行读取完整的 http upgrade request/websocket message,但是读取过程中如果该连接数据只到达一半,该读取过程将阻塞,进而造成该连接所在的 poller 的 event loop 阻塞或者专用于读取的协程池协程被阻塞占用,这种连接多了则服务相应速度变慢甚至不可用,如果协程池 size 大于连接数,则异步网络网络库减少 goroutine 数量的目的就达不到了
实际要解决问题,需要的不只是异步 io 接口,更需要的是粘包解析,nbio 的实现方式是解决了这些问题的,欢迎试用
2021-06-24 16:13:33 +08:00
回复了 xiaoxuz 创建的主题 程序员 生成器模式-代码的艺术系列(一)
这个文章重点是介绍设计模式,而不是安利谁要干什么,没有个人观点的输出昂!
—— 写这种文章本身就意味着一种宣传,并且文章主体包括楼主后续的回复,其实都是非常认可文章内容、对内容产生的是正向推介作用,所以就不要说安利不安利了,写了文章本身就是一种安利文章观点,而观点本身又是对内容的正向推介

存在即合理
——我不是搞哲学的,解释不清楚,有兴趣的话可以到某乎上去看下,也不要再误解这句话了: https://www.zhihu.com/question/19851152

比如截取一段:

```text
并被当做颇有来历的谚语警句讹传于大众话语圈。通常的表述形式有:

> 存在即合理

甚至干脆就是

> 凡是存在的都是正当的 /正确的。What is,is right.
```

另外,不管楼主安利不安利,我要安利:keep go clean, keep it simple stupid.
2021-06-24 14:55:44 +08:00
回复了 xiaoxuz 创建的主题 程序员 生成器模式-代码的艺术系列(一)
@xiaoxuz

是的,看个人风格——所以手持臃肿的铁锤的人就是那么喜欢臃肿的钉子。

如果能只在自家臃肿就好了,放过那些新手,免得把 go 社区更多小白也整成臃肿的了。

另外,中了臃肿的毒的人,可能根本不知道自己中毒了。
2021-06-24 12:16:19 +08:00
回复了 xiaoxuz 创建的主题 程序员 生成器模式-代码的艺术系列(一)
“模式”党不要过度污染 go 了吧,隔三差五就看到 java 味道的 go,本来简简单单几行代码搞定,被你们一搞,哦豁。
2021-06-23 16:29:32 +08:00
回复了 liouop 创建的主题 职场话题 是不是只有我对“阿里”这个词 PTSD 了.....
问问他阿里 P 几,如果是>=P9,听他指挥,如果小于 P9
问问他这种 low p 靠谱的少、多数是跳到其他中小团队负责一些管理然后专业坑队友自己心里没点 B 数吗
别说什么 P7 专家 P8 高级专家,7/8 里真正对得起架构师、专家、高级专家这些头衔肯定是有,但是靠谱的比例非常小
2021-06-20 17:42:30 +08:00
回复了 Jay54520 创建的主题 投资 如何看待交易员声称从 1000 赚到 1000 万?
看看这个吧:

18 年收益 14.5 万倍,神秘香港富豪成亚洲新首富!

  上帝之手:神秘账户从事黄金现货的交易,在过去的 18 年里,他的收益高达 14.5 万倍。

  美国期货商品交易委员会(CFTC)近日在审查中发现,一个开户地为香港的神秘人物,其交易账户中的资金额超过 1170 多亿美元,创造了新的历史记录,这个不知名的神秘人物成为了新的亚洲首富,甚至以实际可操控的资金量计算,他的资产远远超过了世界首富贝佐斯。

 美国期货商品交易委员会表示:目前暂不知道这名人物叫什么名字,属于哪个国籍,由于严格的交易人保密原则,仅知道这个人的交易编码。他于 2003 年在香港交易所开设账户,从事黄金现货的交易,在过去的 18 年里,他的收益高达 14.5 万倍,创造了上帝也不可能做到的交易奇迹。目前美国商品交易委员会已经向香港交易所 2 函,要求对其个人是否在交易过程中存在的违规行为进行调查,并且要求香港金融监管委员会配合转交这名交易人的开户资料。

  美国期货商品交易委员会称如此大的资金池,即便是最低保证金的交易量,也足以对全球资本,期货,现货和黄金市场掀起惊涛骇浪,但却在过去的十几年中没有被发现。CFTC 查阅了过去 18 年来这名神秘人物的交易记录发现,他的每次交易量都一直保持在很低的水平,似乎是用“复利”的魔法在累积巨额的财富。虽然他的账户金额高达千亿美元,但过去 18 年来,他通过英国渣打银行总共提取的资金只有数千万美元。

  美国期货业协会首席专家,纽约大学教授詹姆斯·克伦威尔表示: 我们需要知道的是,这名神秘富豪是如何做到如此高的收益率的,全球期货和现货市场并不像股票市场,可以进行人为操纵和干预,这几乎不可能。如果他是靠自己的能力做到的,那么他将比沃伦·巴菲特强万倍。
2021-06-18 15:46:22 +08:00
回复了 hfl1995 创建的主题 程序员 坚定不移的认为,不给程序员配 4K 显示器的公司要远离。
一个显示器或者 mbp 才多少钱。有些公司把办公用的什么 mbp/pc 、工学椅、显示器弄高大上一点,然后压低工资,而且这些还都是公司的固定资产,离职了公司只是付出个折旧费用。
而大部分这种提供好配置的,都压工资,单按钱算,给你配好点环境,多花万八千或者一两三万,但是一年却至少能省几万。如果公司不给配,自带设备但是别压工资都划算

所以,应该是给配 4k 的公司大部分公司别去。

另外,越高清似乎越伤眼睛。
亚马逊谷歌这些都是按量计费,容易翻车,前几个月有个帖子就说有个小公司差点因此破产

用国内厂的包带宽的这种,不走按量计费,坏处是量小浪费钱,但好处是损失可控

按量计费遇上恶意攻击,就只能依赖云厂良心了
1 ... 46  47  48  49  50  51  52  53  54  55 ... 63  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1608 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 33ms · UTC 16:45 · PVG 00:45 · LAX 08:45 · JFK 11:45
Developed with CodeLauncher
♥ Do have faith in what you're doing.