互联网
Async Rust: The new billion-dollar mistake?
Rust专家讲Async现状的文章,这个问题在Python里也有,大多数人只知道Async/Sync用起来比较麻烦,不知道它的来龙去脉,作者在文章里引用了几个讲问题本质的链接,可以有一个深入的了解。另外作者之前写的选择 Rust 语言:Should I Rust or should I go?也可以看看。
Rust专家讲Async现状的文章,这个问题在Python里也有,大多数人只知道Async/Sync用起来比较麻烦,不知道它的来龙去脉,作者在文章里引用了几个讲问题本质的链接,可以有一个深入的了解。另外作者之前写的选择 Rust 语言:Should I Rust or should I go?也可以看看。
这个作者写的Git的故事蛮生动的,而且旁征博引,里边可谓是英雄辈出了,当然软件版本控制系统还有许多别的支流,只是没有Git这么流行和被我们了解了。
作者之前写的Redis作者的故事,也可以读下。
一个 Rust 语言专家写的文章,说明 Rust 适合的领域和不适合的场景,觉得说得很实在,跟我实际使用的体验比较切合,而且作者在下面这两点的看法也很有品味:
The standard library is anemic
you then have many implementations and ecosystems competing for basic features such as cryptographic primitives, async runtimes or HTTP servers, leading to incompatibilities, bugs, busywork and lost time.
async is hard
Now you have sync functions and libs, async functions and libs, and different runtimes that are incompatible and thus require dedicated libraries for I/O. When discussing with a friend who is into Python, he told me that they are experiencing the exact same problem and it creates a lot of busywork writing wrapper for sync code to be called by async code.
Python async 感觉每过几年就要被人拿来否定下,这次是 Peewee 的作者,asyncio 和 Gevent 的项目我都经历过,感觉作者讲的挺有道理的:
Unlike asyncio, gevent transforms all the blocking calls in your application into non-blocking calls that yield control back to the event loop. As a result, you can continue to use the libraries you’re familiar with, and the exact same codebase can be run with or without gevent “enabled”
还好,社区这几年比较务实,在努力提升 Python 语言自身的性能。
之前一直看着 Redis 作者 antirez 的博客,现在台湾有个作者搜索整理了下 antirez 的故事,还蛮有意思的,antirez 也在 Hacker News 上回复了,开源软件就是这么有意思。
一个独立开发者开发的 ChatGPT 相关产品,做得挺好的,他总结了产品的结果,并说了自己对这个方向的看法:
在过去的这一个月里面,OpenPrompt 获得了:
- 16 万独立访客
- 1.2 万个注册用户
- 341 个付费用户
- 收到付款 0.98 万人民币
OpenPrompt 的愿景
- 当你面对一个无法想象大小的数据库,不知道如何挖掘数据时,给你一些例子,看看别人是怎么挖的。
- 当你面对一个聪明人,不知道如何与他交流时,我们给你一些例子,看看别人是怎么问的。
- 我们把这些挖掘,询问,变成可以复用的 Prompt,提升效率,节省时间。
今天看到善用佳软翻译的《Vim作者访谈 2022》,就看了下,感觉还挺好玩的,有两点比较有共鸣吧:
Software development is much more of a craft. And a craftsman uses whatever tools he thinks will get the best result, no matter if they are what everybody else is using or something different. And a good craftsman makes his own tools when needed.
Most people have their most productive time in the morning, therefore it is much better to set a hard time limit on when to stop. Perhaps make a note of where you were, then relax a bit, get some good sleep and continue the next morning. Quite often the problem that you were stuck with yesterday suddenly gets a new insight and you know what to do. The term “sleep on it” actually works, at least it does for me.
最近折腾 Kafka 的迁移和高可用时,两次碰到了这个坑,所以专门记下来并分享下,就是 __consumer_offsets topic 的 replication factor 一定要大于 1,具体可以看上边链接的文章,讲得非常清楚了。另外再说一个我自己碰到的误区吧,Kafka 停止的脚本是 kafka-server-stop.sh
,但是脚本执行完后 server 是要经过一个清理的过程才会停的,所以如果看进程还在的话要等一会儿,不要着急着直接杀进程,否则可能会丢失数据,而且下次再启动时恢复又要好长时间了。
Python 核心开发者为 Python 性能问题辩护的文章,里边讲了些常识性的道理,比如要权衡开发的效率和快速原型迭代等;以及当要优化时可以采取的步骤和方法等,值得看一下。当然反对者也是有理由的,比如 PyPy 很多人总认为无法用到生产环境,也不大会去尝试;另外一些现代的静态编程语言比如 Go、Rust,它们本身的语言表达能力和简洁性也做得很好了,所以可选择的范围也多了。
一对工程师和设计师夫妇创业做的产品反馈 SaaS 产品,还记得3年前分享过他们的文章,这次再看到总结还是很欣喜,喜欢这种简单纯粹的成功。确实还有许多公司像他们一样沿着类似的路途行进,但却未必成功了,所以那些看似简单的道理实践起来却未必容易,学学别人的经验,看看有哪些值得借鉴的地方挺好的。
作者分析了经济学人杂志转型过程中所采取的一些方式,横向对比了一些类似的传统新闻媒体。总之结果还不错,但我觉得因为幸存者偏差的存在,适合别人的未必就适合你,不过可以借鉴它们的经验和获得启示,对从事媒体行业以及对媒体感兴趣的人们。