V2EX › BeautifulSoap 的所有回复 › 第 93 页 / 共 134 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

For Existing Member Sign In

1 ... 89 90 91 92 93 94 95 96 97 98 ... 134

❮

❯

2022 年 1 月 25 日

回复了 aljun 创建的主题 › 程序员 › 2022 年最适合写业务代码的编程语言是哪个？

@Hanggi 你的回复简直驴唇不对马嘴，对牛弹琴。建议重看我的 169L

2022 年 1 月 25 日

回复了 aljun 创建的主题 › 程序员 › 2022 年最适合写业务代码的编程语言是哪个？

@Hanggi 等等，你都没发现自己说的话前言不搭后语有问题？？

“Go 语言已经可以构筑当代云原生的从底层到应用的方方面面，且大部分都是纯 Go 语言写的。这就已经说明其标准库（包括谷歌扩展库）已经很健全了”

你前面说的是 **Go 语言** 已经可以构建当代云原生的方方面，但 Go 语言 ≠ Go 语言标准库，你到底是通过怎样一层逻辑转换才通过 Go 语言可以构建当代应用得出了标准库已经很健全的结论了？

难道你想说的是“通过 Go 标准库可以构建当代云原生方方面”？并且结合你对健全的定义是“Robust",那么我们就以你对“健全”的这个定义来做个最极端假设：
假设有一个叫“mini Go 语言标准库”的标准库，这个 mini 标准库除了 runtime 这种没法自己直接实现的功能之外不存在任何其他功能（包括 json 、re 、sort 这些全都没有）。通过你对“健全”的定义：

1. 通过这个 mini 库你完全可以构建现代云原生应用的方方面（唯一区别就是你需要自己实现 json 、re 、sort 所有这些轮子罢了）
2. 然后因为这个 mini 库功能小到极致，所以其足够安全、强壮、稳定

那好，根据你对“健全”的定义，这个功能少到极致的 mini 标准库也能被称为“健全”，对不对？

2022 年 1 月 24 日

回复了 aljun 创建的主题 › 程序员 › 2022 年最适合写业务代码的编程语言是哪个？

@Hanggi 所以呢，你在这说了半天，可依旧没有正面回答我的质问——你对“健全”这个词的定义到底是什么？

你说了半天“基于 Go 语言发展”，“基于对比”什么的，可这些都不是对“健全”这个词的定义。讨论话题最怕的就是对某些概念的定义模糊而导致对话一直在做无用功。现代汉语词典对健全的定义是“①强健而没有缺陷。 ②（事物）完善，没有欠缺”，那你对健全的定义是什么？

2022 年 1 月 24 日

回复了 aljun 创建的主题 › 程序员 › 2022 年最适合写业务代码的编程语言是哪个？

@Hanggi
1. V2EX 没法给自己点赞 2. 我也没开别的号给自己点赞 3. 这赞不是我给的
你看到 1 赞第一反应竟然是我在给自己点赞，能有这种脑回路，看来你经常干用小号给自己点赞的勾当？不去参与刷赞黑产简直屈才了你

我说的是 Go 标准库缺失非常多重要的基础功能导致标准库并不够好用，而你却一直企图用所谓的“你不理解为什么没有”之类的来蒙混过关。说难听点，我理解了又能怎样？能改变标准库事实上的确缺失很多基本功能，并不太好用的事实吗？并不能吧

还有我想把一件事问清楚，你张口闭口 Go 标准库健全、健全、健全的，那么请问你这语境中的“健全”到底是什么意思？现代汉语对健全的解释“①强健而没有缺陷。 ②（事物）完善，没有欠缺”，结合这个解释，你是到底是想说 Go 标准库没有 BUG 呢，还是想说 Go 标准库已经十分完善，没有任何缺陷不用改了呢，还是 Go 标准库功能方面已经十分完美了？

2022 年 1 月 24 日

回复了 aljun 创建的主题 › 程序员 › 2022 年最适合写业务代码的编程语言是哪个？

@Hanggi 做人不能太二极管，喜欢一门语言并不是要么爱死要么喷死。我喜欢 Go 并不意味着这些用得不爽的地方我也要用所谓“设计哲学”来洗脑自己让自己强行接受

Go 的标准库健全吗？或许你可以说 Go 的标准库“健”，但绝对担不上“全”的名头。我希望你能摸摸自己良心问自己一句：Go 的标准库它好用吗？注意是“简单”“方便”“功能全面”这层面的意思，至少我觉得 Go 的标准库完全担不上这个名号。而且更别提 Go 标准库那令人一言难尽、写得让人摸不着头脑的文档（这点你还真别跟我杠，去年 JetBrains 做的调查，关于 Go 标准库文档，我记得有 50%左右的人都觉得这文档写得不得要领、无法获得有帮助的信息）

2022 年 1 月 24 日

回复了 aljun 创建的主题 › 程序员 › 2022 年最适合写业务代码的编程语言是哪个？

go 用了挺长一段时间了，也写过不少业务代码，虽然很喜欢 Go 但也来抱怨下写业务时经常觉得烦心的地方：

1. 作为一门新生的现代语言，标准库功能之缺乏让人难以忍受。比如 Go 标准库里连个查找指定值是否在数组或切片里的功能都没有，所以理所当然的数组查找相关的所有功能（数量统计、获取 index 之类的）也都没有，都让你自己手写。当然，这东西写个 for 循环就搞定了，但每次不同项目里想要用的时候都得复制粘贴一遍的时候就不由得在心里咋舌一下。除此之外还有很多功能也同理。希望这方面能随着接下来泛型的发布有所好转

2. 写业务方面另一个感触就是，Go 的 DDD 实践没有太过统一的标准，所以参与不同项目经常看到各种风格迥异的 DDD 实践。光是我参与的几个项目就见过了从经典的分层架构到 Clean Architecture 的应用，再加上不同的人对不同架构有不同理解。。。。。

3. 现在写业务代码最烦的就是写 Entity 和 DTO 等各种对象之间的转换。大部分对象转换就是值一个个赋过去，手写起来烦得要死，找过自动代码生成的轮子也都是好几年前的不太好用，IDEA 里也没现成的插件。用基于反射的自动转换的轮子的话又有一定性能问题。相关的工具链方面还有挺多想吐槽的，记得 java 这方面工具链挺完善的？希望 go 啥时候这方面也能完善点

2022 年 1 月 23 日

回复了 MiketsuSmasher 创建的主题 › Python › 怎么优雅地翻译文档中的“seek”、“seeked”和“seekable”？

翻成定位呗

2022 年 1 月 22 日

回复了 monetto 创建的主题 › Go 编程语言 › GoLand 能否根据结构体自动导入包前缀

@logique goland 啊还能是啥

@hzzhzzdogee material theme ui 插件里的 Monokai Pro ，因为喜欢亮色主题，我把这个主题的所有颜色都取了个反色

2022 年 1 月 21 日

回复了 monetto 创建的主题 › Go 编程语言 › GoLand 能否根据结构体自动导入包前缀

@monetto 用过好多电脑配置再差也不至于一两秒吧。。。难道是项目或者 sdk 还没有索引好？

2022 年 1 月 21 日

回复了 monetto 创建的主题 › Go 编程语言 › GoLand 能否根据结构体自动导入包前缀

难道我用的是假的吗。。。。

这样 tab 选择对应的对象之后直接不就帮你导入对应的包了。。。。

https://i.imgur.com/I2LPqrp.png

2022 年 1 月 20 日

回复了 sen2 创建的主题 › Windows › win10 如何创建独立用户？

@x66 你什么时候产生了远程桌面只能用电脑连的错觉。。。。还有不建议像你这样放地图炮，windows 给普通用户输管理密码等同于 linux 下用 sudo ，你要放地图炮的话等于也在放 linux 系系统得地图炮

2022 年 1 月 20 日

回复了 312ybj 创建的主题 › 推广 › 关于我年终绩效拿了 B 这件事

@BeautifulSoap 错别字订正：1.路过庆幸下自己 2.是一年发两次，每次发根据之前半年营收平分利润

2022 年 1 月 20 日

回复了 312ybj 创建的主题 › 推广 › 关于我年终绩效拿了 B 这件事

路过庆幸走自己。。。我在的日本公司一年发两次奖金，每次奖金都是把公司当年利润的一定比例平分给所有员工。所以所有员工无论谁拿的奖金但是同样的金额。好处自然都能理解，但坏处就是公司营收不好的时候奖金就没了。。。。。

2022 年 1 月 18 日

回复了 shfan 创建的主题 › iPhone › iPhone 充电太快了，有没有 2W 的充电头

你们调侃了 lz ，lz 则调到了鱼，除了电池健康度魔怔人之外没人受伤的世界完成了

2022 年 1 月 18 日

回复了 naoshier 创建的主题 › 云计算 › aws s3 用户上传的文件，如何只允许用户访问

你是要直接访问 s3 链接还是要在 s3 链接外套一层服务再访问？

直接访问 s3 链接需要首先在 IAM 里配置对应的 user 和 user 的策略只能访问指定的 bucket ，然后获取到用户的两个 KEY ，然后用这两个 KEY 来获取。至于怎么在代码里用，直接找 aws 的 sdk 就行，用 sdk 里附带的 s3 类配合认证信息获取图像
但这么做有个问题在于你必须明文把 aws 用户的两个 key 交给客户端，而且用户多了不可能每个用户都配置一个 user

所以一般做法还是在 s3 外套个自己写的服务器，在服务器内鉴权，成功之后通过你服务器获取 s3 中的图片而非直接拿 s3 的 url

2022 年 1 月 18 日

回复了 ab 创建的主题 › Android › 一加现在不让刷氧了吗？

@starcraft 一加海外市场可不小，而且本来就是蓝绿厂的公司，不自己作死的话再怎么也不可能比魅族先倒。倒是一加的系统技术能力是真的值得诟病，每年出的机型数量少到和苹果差不多，结果自己的系统更新支持，bug 处理之类的拉跨得一塌糊涂

2022 年 1 月 17 日

回复了 lingdu666 创建的主题 › git › git 操作命令行比界面有哪些优势呢？

@gengchun 我作为公司里入职不到 3 年的普通小员工，当真受没有领导这头衔。不信？我之前发的在日本工作的帖子你可以看一下： https://v2ex.com/t/748274 （帖子里说有上下关系是为了不被特定出所在公司，因为奉行完全扁平化的 it 公司在日本毕竟少数。而且最近几个月天天 1 点多才到公司上班，虽然公司制度上这么做完全没问题但被特定出公司的话毕竟不太好）
我思考了一下，觉得可能是因为在日本工作大家都还算轻松，所以不太会像国内崩得这么紧员工之间小心眼吧

2022 年 1 月 15 日

回复了 lingdu666 创建的主题 › git › git 操作命令行比界面有哪些优势呢？

@gengchun 有被笑到，我平时说话遇到提交了不该提交的文件都是大概这么说的 “这 xxxx 变更、xxxx 文件是不该提交的内容，如果你平时只用命令行的话，我觉得可能是你习惯了 git add *还不确认提交内容，这不好可能需要注意下”当然，我用日语的所以实际字打出来的话会有对应敬语的修饰。

如果这种话在你眼里都是普通人都没法接受，所谓官威的话，那么你平时工作生活都遇到的都是一群心眼多么小的人啊？虽然不太想用这成语但“物以类聚人以群分”要不要思考下？

还有，不好意思我们公司奉行完全扁平化的管理模式，我们各项目组连组长都没有，所有开员工在职能上都是平等地位。甚至我们公司扁平化到普通员工的上面直接就是公司懂事们，互相之间只有新员工对老员工前辈的适当礼节根本没有职位上的所谓上级可以去要求或欺压别人。所以可能也拜此所赐我们公司氛围是真的很好，可能这也是比较少遇到你说的小心眼人的一个原因。

对了，都说了这么多楼了，你还张口闭口 gitgnore 是认真的吗，避重就轻简直死鸭子嘴硬。我就问你无论什么环境，写代码时临时加了几行调试用代码或任意的临时的代码，然后提交时忘了这茬提交前一行 git add *全给交上来了那么请问这种情况你给我配置下 gitgnore 给我看看？？这次你可以把临时代码提交上来，那么今后万一提交上什么敏感信息导致出事怎么办？当然我看你说的话也是个连最基本的这种责任感都没的老油条了，那也和你继续逼逼下去的需要了

1 ... 89 90 91 92 93 94 95 96 97 98 ... 134

❮

❯