最新

在人们开始担忧人工智能取代软件工程师之际，一个可能的衡量指标是 OpenAI 的各种模型编写的代码量。<p>如果人工智能对软件工程构成威胁，我不会指望很多软件工程师会主动加速这一趋势。我个人并不认为它是一种威胁，但显然有些人（非工程师？）是这么认为的。<p>我很想知道，是否有 OpenAI 的工程师能分享一个关于他们日常工作中人工编写代码与 AI 生成代码的大致比例。

我决定为自己开发这个应用，因为最近有点放纵，想为了健康休息一下。<p>它非常简单——添加任何你想要戒除的物质，设置你开始戒除的时间，它就会开始计时。如果你愿意，你可以在菜单栏中显示它，以便随时提醒你自己的进度。<p>完全免费、私密，你的数据不会离开你的电脑。<p><a href="https://quititapp.com/" rel="nofollow">https://quititapp.com/</a>

只是想知道，其他人是否也对目前领先的现代系统编程语言没有将快速编译作为其基本设计目标之一而感到越来越不满。<p>对我来说——这似乎是未来“十亿美元”错误回顾性文章的明显候选者。<p>为什么“支持快速编译”不是任何希望实现广泛使用的现代语言的必要先决条件？<p>特别是对于 Rust 而言——似乎很多编译速度慢的行为并非该语言最重要的任何方面所必需的……<p>有没有人尝试过以一种故意破坏兼容性的方式来分叉 Rust 生态系统，以便为该语言和生态系统规划一条最简单的快速、可扩展的编译策略？<p>我有一种感觉，这样的努力——移除了一些 Rust 的错误特性，并简化了包管理系统以加快编译速度，实际上会取得成功，并能够相对快速地取代当前的生态系统……