lz 也只提到一点优势，速度。相对于生态，速度真的是权重非常小了。
而且 python 做原型做科研做探索，根本不太介意速度。教授和学生们选择 matlab 和 R 需要认真考虑速度吗？
真要到生产环节，速度也有多种弥补方式，架构对速度的影响远大于虚拟机和 GIL。
再具体化到功能或者指令级的速度优化，也有太多的选择。c/c++做 python 的底层已经是业界常规，框架、系统级开发 go 的面前还横着一个 rust 插队，旁边一个 julia 横空出世打着 python 继任者的旗号。
go 在 python 的领域实在看不到啥机会。

量化的前提不是已经完备的框架，而是更细节更原子更重要的数据分析、处理库。这些库确保可用性和易用性。然后才是并行、GPU 等库确保效率。
这些领域，python 有着超过 20 年的生态积累。go 有什么？只有中间件和 web 服务。go 是一种工程化语言，而 python 不但有工程界的喜爱，更重要的是科研界的基础。这是 go 连想都不敢想的。

我可以一局从午休挺到天亮，手机不行。

收藏此帖。
以后每次需要$的时候，来这里复制粘贴一下。

忘了总结：
1，自己做项目主体。别废话别 bb，以结果为导向，为自己发展而谋算，不要受外界影响。项目是你负责，成败是你的 KPI，这点永远不变。目标是第一要素。
2，控制情绪不以物喜不以己悲。冷静是程序员的基准，理智是程序员的武器。自我修炼是第二要素。
3，过程和其他非关键因素反而最不重要。有很多种处理办法，据此找个 平衡点 /兴趣点 /成长点 都可以。

if 你能决策团队:
把猪队友宰了炖一锅酸菜猪肉炖粉条犒赏自己和队友提升团队战斗力（战斗指数 105%）
elif 你能决策自己:
if 你想做个好人:
项目主体自己做。分配他一点毫无影响的活，做不做随他。（战斗指数 100%）
elif 你想做个诚实的人:
项目主体自己做。分配他一点毫无影响的活，严格记录安排日期、催促日期、交付日期、交付质量等，如实汇报老板。（战斗指数 90%，管理、跟进和汇报需要一点成本）
elif 你想做个有收益的人:
项目主体自己做。分配他一点毫无影响的活，但跟他强调重要性，但同时跟他讲咱俩好兄弟我罩着你，你要是实在完成不了计划老板那边我帮你想办法。（战斗指数 100% + 收益指数 N ）
else:
项目主体自己做。其余所有事装傻，协调和安排所有事转嫁给老板。（战斗指数 100% - 老板印象指数 N%）
else:
上来发帖。

移动 18 元套餐，每天都有短信或者电话送流量送套餐搞活动，神经病啊！

而且非常有针对性。主号几乎不太营销，小号骚扰个不停，天天换着法子催着换套餐。

越 bb 越烦，越烦报复心越强烈。我决定这张卡这个套餐用到移动倒闭为目标。有种直接改套餐，让我也体验一下工信部投诉。

咖啡确实提神我告诉你！

尤其午休后迷迷糊糊来一杯，烫的当场就精神了！

记住一定要 80 度以上的。

要求就是。。。根据场景选择合适的图片格式、尺寸。没有唯一标准，只取决于具体场景下的业务需求+性能需求+价格需求。

png 适合颜色简单、色块边界规则、细节不太丰富的图片。比如界面、文字、icon 等。
jpg 适合颜色丰富、细节丰富的图片。比如照片。
webp 很多指标比 png 还好一些，但毕竟比较新，兼容性不如 png。
以上都是位图。而 svg 是矢量图，适合图片面积不大、颜色简单、边界规则，但需要在各种尺寸下无损缩放的场景。比如界面、icon。
gif 能动，仅此一点天下无敌。
ico 格式专做网站图标，这也是比较独特的。当然现代浏览器已经可以支持其他格式的图标了。

大部分场景最好使用合适的尺寸、合适的 dpi/ppi 的图片。比如列表里只放小尺寸缩略图，详情里只放最大尺寸 1280 的图，原图下载时放高清原图。这只是一个例子，例如如果你做的是桌面壁纸站，那标准就要提高很多很多了。
充分考虑小屏手机、大屏高 dpi 手机、retina 屏等各种物理屏幕场景。

压缩分有损和无损两种。无损意味着原汁原味保留原图每一个像素点的信息，一般可以换格式、同格式下换压缩算法、剔除注释信息、Exif 信息等像素无关信息。有损可以换格式、换压缩算法、缩放等。

总之，这是一个多目的多规则共同权衡的问题。没有唯一解。

hashids + snowflake + GUID 简直绞杀我所有关于 id 的需求。

确定伪基站的话可以报警。

另外，帮钓鱼网站打码是出于什么考虑？

@j0hnj 项目依赖比较简单，暂时还没遇到痛点，除了 lock 耗时问题。
能比较一下 pipenv 和 poetry 吗？

感觉设定没错。支持 @opengps 的观点。
主要问题是客服水平太糙，理解问题能力低下，技术能力低下，沟通能力低下，客户关怀能力低下。然则这好像是各大厂技术支持的通病。可以尝试通过非工单途径积攒一些直接对接到具体人的方法（ QQ、微信、手机）等，然后定点请求协助，效率会比工单随机分配到菜鸟要高一些。
另外，强迫症一样的反对给数据库增加任何逻辑。

pipenv 了解一下

从帖子里大部分人的对立面聊聊这个话题。

先表立场：小公司，我就是上级，开发出身。我的 boss 不算太懂技术。

大概 80%的重构需求由开发提出，其中只有 20%的重构需求我会认可，80%都被我拒了。常见原因按比例列举如下：
1，纯粹就是想炫技，想用新技术，想搞事情想赚工分。这个比重最大，一般特点是年轻、活跃、激进、前端等。这些人纯粹就是吃饱撑的，兴趣驱动最大无视其他一切因素。没办法，只能说磨砺中成长吧。。。把他们的无穷精力稍微倾斜一些在预研、攻关、分享等技术型任务会更双赢一些。
2，代价，时间和人员。说实话这是男默女泪的巨坑。但毕竟公司不是学校，盈利是根本目的。学院里好的技术人员可以用无限的资源挑战学术的极限，但社会中好的技术人员需要带着沉重的现实镣铐尽最大可能让各方利益都能接近最大化。这部分只能说可惜，但必须让开发同学能理解能把心态调整好。
3，不够平滑。这种一般原则上已经赞同了，但执行方式上比较粗暴，比如项目主线暂停、阶梯式升级导致用户流失、服务暂停等。会搁置、会要求优化、会要求分解，分阶段落地或者部分落地。
4，动机不纯。一般发生在老员工。为了攫取话语权和 KPI。这部分直接堵回去，打负分。

以上来看，根本原因大部分都出在视野问题，视野不够大，看不到全局看不到负面。另外一个根本原因是出在立场问题。毕竟屁股决定脑袋，有时候并不是使坏，是潜意识让人做出了对自己利好的决策而没有意识到。期望大家能换位思考，能认可共赢价值观，能杜绝自我自私损人利己。

大概 20%的重构需求由我提出，其中 80%会得到上级的认可，推行并落地。
毕竟同是开发，懂得在屎山中摸爬滚打是什么滋味。有时候能从架构层面发现开发同学们发现不了的重构点，就尽力去推动改善，这也是对团队对公司都有利的。但毕竟不存在人定胜天的鬼话，有时候我也有局限，推不动的甚至推错方向的，同学们多担待吧，我陪你们。