V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  neoblackcap  ›  全部回复第 41 页 / 共 99 页
回复总数  1972
1 ... 37  38  39  40  41  42  43  44  45  46 ... 99  
2018-09-26 23:53:39 +08:00
回复了 GTim 创建的主题 Go 编程语言 作为 Go 使用者,你如何评价 go module ?
@taowen
@reus
不对就要喷,分散代码,靠 github 管理有什么好?
集中的一个源,我可以说有以下几个优点
1. 快速部署镜像
2. 不会因为 github 的地址变更而改变依赖关系。你们自己想想到底有没有 github repo 转让过用户,转让了是不是不用动代码,一个新的项目参与者能用什么方式同步依赖?

为什么 Rob 就一定要采取这样的方式来管理依赖,你们说这个没有受到 Google 内部的基础设施影响,你们自己信吗?
自从 Golang 发布依赖出现了多少依赖管理工具,为什么官方就不钦定一个?原因就是 Google 内部没有这个必要。bazel 加上单一的版本库,完全就可以解决版本控制,构建的问题。但是一般公司不是这样,这样才是为什么 2018 年了,golang 的版本控制还是如此让人蛋疼。

同时你们觉得时不时插入的 check error 没有影响思路的,我觉得也是可以,毕竟这个风格问题。问题也不大,正如没有泛型也可以自己写一个代码生成器生成代码,或者编辑器编写代码片段。但是你们倒是说说用 github 作为代码仓库有什么好处?
2018-09-26 19:22:38 +08:00
回复了 GTim 创建的主题 Go 编程语言 作为 Go 使用者,你如何评价 go module ?
@SuperMild 但是他为什么不做?原因就是 Google 不需要,你们社区要不要,他不管。
Rob 不是圣人,要排资论辈 cpp,Java 哪个不是大牛设计?
错误就是错误,跟谁做的没关系。

历史就是明证,说泛型无用,check error 最好的,官方都在打脸。
2018-09-26 17:12:58 +08:00
回复了 GTim 创建的主题 Go 编程语言 作为 Go 使用者,你如何评价 go module ?
我只想说,包管理是很难么?为什么现代化的语言都用中心话管理,golang 就整天扯这些。
承认吧,golang 在依赖管理这方面就是个残废,就是想着自己内部有一个超级大的代码库,什么都可以从里面 checkout。
压根就没有考虑其他人的使用。1991 年发明的 Python 跟 Java 都有很成熟的包管理方案,大家都习惯这样的做法。golang 到今天还要整天发文说这个版本号管理,那个机制管理。简直是败笔,无病呻吟,自找麻烦,抄都不会抄!
2018-09-24 18:00:16 +08:00
回复了 ltoddy 创建的主题 Python 关于 Python 协程的一个问题 (asyncio)
为什么难理解,其实是大家看书查资料的方向错了。这里虽然是协程,但更多的是事件驱动编程,除了用上了 await 来解决以前的装饰器,还有一些默认的封装。但本质还是事件驱动编程。具体可以看 linux 网络编程,跟 epoll 相关的内容。现在大多数事件循环在 Linux 下都是封装 epoll,将对应的套接字以及回调函数注册到 epoll 实例上。抓住本质自然就会了解。其实很多现在这些框架的作者是默认你了解这部分内容的。
@passerbytiny
第一我没叫你换
第二我只是回答别人对破解版的质疑
第三我觉得你这样只能从工具上面来获得成就感的人很可怜
@liuawei 有社区版,全部 bundle 加起来也不贵,也就一年 1000 多而已,v2ex 上的人,没有几个买不起
2018-09-20 22:43:52 +08:00
回复了 xoxo419 创建的主题 PHP Google PHP 项目设计思想指的是什么?
据我了解 google 用 C++,Java,Javascript,Go,Python。研究的了解,不过干活就那些,比如代码规范就没 php,都多少年了
@shijingshijing 都是账目,将研发外包就知道了,微软就是这么干。研究院剥离,集团每年给大量的钱去买他们的研发成果,研究院年年都有产出,大家都开心,美滋滋
2018-09-20 17:24:56 +08:00
回复了 ns2250225 创建的主题 Python 请教大家: Django 集成了 Celery,怎样分布式部署 worker 啊 👻
@NaVient 你到底是有多少个 celery beat 实例?
2018-09-20 16:57:48 +08:00
回复了 ChristopherWu 创建的主题 程序员 设计分布式系统—简明粗暴的名字发现服务
@ChristopherWu 然后你的 LBS 层又是一个单点是吗?如果你的 LBS 不是单点的话,那么直接将服务注册到 LBS 层上面不是更好了?
2018-09-20 16:44:39 +08:00
回复了 ChristopherWu 创建的主题 程序员 设计分布式系统—简明粗暴的名字发现服务
@ChristopherWu 你每个节点保存的信息是多少?全部节点的路由信息嘛?如果不是,那么不就出现相当抛弃了 CAP 理论里面的 P。
如果你全部保存,那么就是一个星状网络,你能处理的信息取决于你单机能处理的数据量。
不知道我理解的对不对。有错请指出
2018-09-20 16:02:36 +08:00
回复了 ChristopherWu 创建的主题 程序员 设计分布式系统—简明粗暴的名字发现服务
@YouXia 文章里面的确是没有 master 的意思,因为每个节点都是 master。
@yidinghe 如果我没有理解错的话。也可以说这个分布式没有水平拓展性。因为单机解决不了的数据,上这个分布式方案也解决不了。
2018-09-20 12:53:32 +08:00
回复了 ctrlaltdeletel 创建的主题 程序员 各位公司中的后端项目要求代码必须线程安全吗?
库没有说,默认线程不安全,自己 review 或者加锁
2018-09-18 22:53:44 +08:00
回复了 XiiLii 创建的主题 Python 纠正《存储 dict 的元素前是计算 key 的 hash 值?》
hash 表的实现各大算法书都有写,就算没写,也有 CPython 的源代码。
这个完全不需要讨论吧
2018-09-18 14:39:13 +08:00
回复了 zynlp 创建的主题 C ->*和.*有什么实际应用场景吗?
2018-09-17 18:27:57 +08:00
回复了 userlol 创建的主题 程序员 Python socket recv 老是收不全数据怎么办?
而且你想性能好些应该用 epoll 来监听 socket 是否可读,用另外一个线程去读
2018-09-17 18:26:16 +08:00
回复了 userlol 创建的主题 程序员 Python socket recv 老是收不全数据怎么办?
@userlol 如 3 楼所说,你必须先循环读出头部,然后才按长度去读剩下的部分。
还有就是你读到尾部,也有可能是一部分尾部,一部分是另外一个请求,记得将他们分开
2018-09-17 17:38:29 +08:00
回复了 userlol 创建的主题 程序员 Python socket recv 老是收不全数据怎么办?
你自己不 parse 就想读出来? tcp 又不保证你一次就收到全部数据
2018-09-17 12:05:01 +08:00
回复了 geekyoung 创建的主题 程序员 mac python3 莫名丢失,求大神帮忙
@geekyoung 就是 3.7 的 python 不会在 /usr/local/Cellar/python3/3.6.1/bin/,brew 将旧的卸载了,但是你之前的路径是写的绝对路径,新的 3.7 是在 /usr/local/Cellar/python3/3.7.1/bin/之类的路径嘛
2018-09-16 23:43:24 +08:00
回复了 abcbuzhiming 创建的主题 程序员 遇到真正的高并发问题了,特来求助
@jokerlee @tcsky 这样我觉得其实架构师需要背锅了。出来久了,面试多,项目做多了,我觉得一个合格的架构师的确是需要预估业务量的。然后选择合适的架构。以前还好觉得很多项目都很容易做烂,不过我现在觉得,刚开始选一个性能高一些的架构的确是好事。开发效率其实可以从外部库来提升的。比如现在基于 openresty 的东西他们的性能都不差,业务写起来其实跟其他的框架也不会差到哪里去。
因为以前自己也干过无脑加线程的事情,但是业务高上去的话,的确解决不了。自己后来也反省,并发这事情啊其实跟 IO 密不可分,比较好解决的一个就是用户态线程(erlang, golang),二就是 IO 复用+非堵塞 IO+线程池即 one thread one loop + 线程池的架构。
无脑加线程的确可以解决一部分问题,但是假如业务是往上走的话,很快就会出问题的。因为单纯地加线程跟规模不是线性的关系。
1 ... 37  38  39  40  41  42  43  44  45  46 ... 99  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1099 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 46ms · UTC 18:57 · PVG 02:57 · LAX 10:57 · JFK 13:57
Developed with CodeLauncher
♥ Do have faith in what you're doing.