V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  lvlongxiang199  ›  全部回复第 1 页 / 共 2 页
回复总数  30
1  2  
13 小时 35 分钟前
回复了 acr0ss 创建的主题 程序员 Java 性能竟然优于 Rust,哪里有问题呢?
打个火焰图看看 ?
9 天前
回复了 afxcn 创建的主题 Go 编程语言 golang 的 defer 真是个好设计
@w568w 1 这点没得洗. 但 2 这点, 带 gc 的语言一般都没有用 raii 这套的 (对象销毁时机不确定), try 这一套不太好表达把 ownership move 到其他函数这一点. defer 这玩意只能说有优点也有缺点
9 天前
回复了 afxcn 创建的主题 Go 编程语言 golang 的 defer 真是个好设计
@hez2010 另外 java9 中已经废弃 finalize 了
9 天前
回复了 afxcn 创建的主题 Go 编程语言 golang 的 defer 真是个好设计
@hez2010 这玩意真没法兜底. 可能会出现没触发 gc 资源就因为没有及时释放就耗尽的情况
cpp/rust 里头的 RAII 能保证这个 obj 离开作用域就销毁
9 天前
回复了 afxcn 创建的主题 Go 编程语言 golang 的 defer 真是个好设计
@kxct 似乎只有不带 gc 的语言才有析构函数, 带 gc 的语言里头, gc 的时机不确定, 导致析构函数调用时机不确定. 没 gc 的话, 又一堆操心事
13 天前
回复了 kksd0912334 创建的主题 Kubernetes 如何劝领导不要搭建备用 k8s 集群
能先说出在你们这种场景下, 为啥两套集群不合适比一套集群更合理吗 ?
实际上, 也有人主张用多个小规模 K8s 集群的联邦代替一个大 K8s. 比如: https://www.infoq.cn/article/lgzz3duliciczvoibpxh

ps: 想起了罗素的一句话: 未受哲学熏陶的人,一生都被禁锢在种种偏见中,这些偏见来自常识,来自他那个时代或民族的习惯性信念,来自未经审慎理性的合作或同意而在其心灵中形成的信念。对这样的人来说,世界往往变得明确、有限、显而易见;寻常的事物不会引出问题,**陌生的可能性会被轻蔑地拒绝**。
动手实现一遍, 之后压测试试呗
25 天前
回复了 wangpugod2003 创建的主题 程序员 讨论一道面试题啊(take home task)
感觉可以并行来跑, 充分利用 CPU 多核. 启动多个线程, 每个线程同时做 topK, 最后 merge 成一个
直接用 adblock/uBlock 之类的东西屏蔽了呗
瞎翻了下, 感觉没提到啥设计哲学. 比如可以说说以下问题. 如何实现是一个有意思的问题, 但在语言设计上选择要实现 X 这种特性而非 Y 特性也是个有意思的问题.
+ 为什么 go 没有 Java 中的异常机制, 出现异常的时候选择返回 err 而非抛出异常 ? 这是不是一个好的设计 ? 异常有啥问题
+ 为啥 go 没有一般意义上的继承 ? 如果没有继承, 如何实现多态 ? embedded struct 算不算继承 ? 一般意义上的继承又有啥问题 ?
+ channel 跟 Java 中 BlockingQueue 又有啥区别 ? 通过共享内存实现的并发跟通过 channel 实现的并发在哪种场景下更好 ?
+ 为啥 channel 会有 close 这个操作, 在哪些场景下会用到这个操作 ?

另外讲闭包的时候, 可以提下如何让函数实现一个接口.
你为啥实际试试呢 ?
@gdfsjunjun 有时会要求双击电源键确认, 起码 appstore 是这么处理的
如果向 master 内写了 x=1, 写成功之后 master 挂了(其它节点, 拿不到最新的 binlog). 这时候从其它节点读 x, 能读到 1 还是之前的值 ?

raft 能提供这种线性一致性的保证
@AoEiuV020JP 我仅仅说你提供的这个封装不适合处理这种情况, 没说 golang 没提供这种处理. io.Reader 就是一个流
@AoEiuV020JP
> 高级一点的现代语言都有封装一些方便的方法,比如直接把 body 完整读取转成字符串并 close
我的意思是, 这种封装挪到第三方库就行了, 没必要放到标准库, 这东西的使用场景很有限. 流式读取的应用场景更广泛, []byte, string 都可以看作是流


ps: **请你好好说话**
我觉得很合理. `resp.Body` 就是个 reader 跟 fileReader 类似, 区别就是这是别人帮你 open 然后把 ownership move 给你, 负责 close 是用户的事, 你觉得 fileReader 必须 close 是不是合理的 ?
虽然对于大部分调用 rest api 的情况, 是把 reader 内的读出来, 之后 close. 但是对于需要流式获取的场景并不合适(比如: 实时视频流, 大文件), 按我的理解, 进入标准库的东西, 得适配普遍的场景, 而非 rest api 这种单一场景
@AoEiuV020JP 如果是个文件呢 ? 直接读到内存里, 没准会 OOM
@SSang 似乎可以这样,
```
middlewareA:|________________________将 user_id 等信息放入 ctx______________________|
middlewareB: |____________________________log__________________________|
middlewareC: |_________________如果没有 user_id 报错_____|
```
@SSang 似乎可以这样,

middlewareA:|________________________将 user_id 等信息放入 ctx______________________|
middlewareB: |____________________________log__________________________|
middlewareC: |_________________如果没有 user_id 报错_____|
建议还是把鉴权放到 log 之前. 向 ctx 里头塞指针, 万一有地方把指针里的值改了, 很难 debug, 不如让它不可变
1  2  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1030 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 30ms · UTC 19:42 · PVG 03:42 · LAX 12:42 · JFK 15:42
Developed with CodeLauncher
♥ Do have faith in what you're doing.