语言 & 框架

采纳 我们强烈建议业界采用这些技术，我们将会在任何合适的项目中使用它们。

试验 值得一试。了解为何要构建这一能力是很重要的。企业应当在风险可控的前提下在项目中尝试应用此项技术。

• 84. Astro

  Astro 框架在社区中越来越受欢迎。我们的团队已经使用 Astro 构建了诸如博客和营销网站之类的内容驱动型网站。Astro 是一个多页面应用程序框架，它在服务器上渲染 HTML 并最小化通过网络发送的 JavaScript 。我们认为不错的一点是，尽管 Astro 鼓励仅发送 HTML，但它支持在适当的情况下选择性地使用您选择的前端 JavaScript 框架编写的活动组件。它通过其岛屿架构实现这一点。岛屿是单页内的交互区域，在这里所需的 JavaScript 仅在需要时才被下载。通过这种方式，网站的大部分区域被转换为快速的静态 HTML，而 JavaScript 部分则优化为并行加载。我们的团队既喜欢其页面渲染性能，也喜欢其构建速度。Astro 组件语法是 HTML 的简单扩展，学习曲线相当平缓。

  查看历史条目
• 85. DataComPy

  对数据帧进行比较是数据工程中的常见任务，常用于确保两个数据转换方法间没有显著的偏差或不一致。 DataComPy 是一个用于比较 pandas, Spark 或其他格式 DataFrame 的工具。这个库不仅能比较 DataFrame 的一致性，还能在行和列上对不一致的地方给出细致的洞见。 DataComPy 还可以指定忽略掉无需展示的数值绝对/相对比较和已知差异。我们的一些团队将它用于了冒烟测试组件中，他们发现它能高效比对大数据量多字段的 DataFrame，与此同时它给出的报告也易于理解和应对。

  查看历史条目
• 86. Pinia

  Pinia 是一个在Vue.js中使用的存储库和状态管理框架。它使用声明性语法并提供了自己的状态管理 API。与Vuex相比，Pinia 提供了一个更简单的 API，简化了使用流程，提供了组合式 API，并且在与TypeScript一起使用时具有可靠的类型推断支持。Vue.js 团队认可 Pinia 作为 Vuex 的可靠替代品，目前它是 Vue.js 的官方状态管理库。总的来说，我们认为 Pinia 的简单性和易用性是非常不错的。

  查看历史条目
• 87. Ray

  机器学习（ML）的工作负载正在变得越来越计算密集型。尽管用笔记本电脑开发训练模型很便利，但这样的单节点开发环境很难适应扩展需求。Ray AI 和 Python 代码从笔记本电脑扩展到集群的统一框架。它本质上是一个封装良好的分布式计算框架，集成了一系列 AI 库以简化 ML 的工作。通过与其他框架（例如，PyTorch 和TensorFlow的集成，它可以用于构建大规模 ML 平台。像 OpenAI 和字节跳动这样的公司大量使用 Ray 进行模型训练和推理。我们还使用它的 AI 库帮助我们的项目进行分布式训练和超参数调优。我们推荐你在构建可扩展的 ML 项目时尝试使用 Ray。

  查看历史条目

评估 在了解它将对你的企业产生什么影响的前提下值得探索

• 88. 安卓适应性

  有些移动应用或者游戏非常消耗资源，他们可以在几分钟内导致散热过载。在这种情况下，设备会降低 CPU 和 GPU 的频率以降低温度，但游戏帧率也会随之降低。当散热情况有所改善时，设备的帧率会回升。如此循环往复，软件会变得非常不稳定。Android Adaptability 是一套允许移动程序开发者根据动态的设备性能和散热情况进行调校的新类库集。安卓动态性能框架( ADPF ) 集成了提供设备热量信息的 Thermal API、帮助安卓系统选择 CPU 的最佳运行点以及核心配置的 Hint API。Unity 的自适应性能包也同时支持这两种 API，使用 Unity 进行开发的团队应该会觉得这很有帮助。

  查看历史条目
• 89. Concrete ML

  在此之前，我们曾经标记过允许在加密过的数据上进行计算的同态加密技术。Concrete MLl 就是这样一个允许在隐私保护的环境下进行机器学习的开源工具。作为一个基于Concrete 构建的工具，它帮助数据科学家们简化了完全同态加密(FHE)的使用，帮助他们将机器学习的模型自动转化为同态加密过的数据。此外，Concrete ML的内置模型中还有和他们的机器学习算法库几乎相同的API。你也可以通过Concrete ML的转换API将PyTorch 网络进行完全同态加密。然而，需要注意的是，若在没有调校过的硬件 中使用Concrete ML会导致完全同态加密的速度变慢。

  查看历史条目
• 90. Crabviz

  Crabviz 是一个用于创建调用图的 Visual Studio Code 插件。这些图表是交互式的，这在使用中等规模的代码库（例如微服务）时起到了很大的作用。它们按文件分组显示类型、方法、函数和接口，并显示函数调用关系和接口实现关系。因为 Crabviz 基于语言服务器协议，只要安装了相应的语言服务器，就可以支持任意数量的语言。虽然这也意味着 Crabviz 仅限于静态代码分析，可能不足以满足某些用例。该插件是用 Rust 编写的，可在 Visual Studio Code Marketplace 上获取。

  查看历史条目
• 91. Crux

  Crux 是一个用 Rust 编写的开源跨平台应用开发框架。受到 Elm 架构的启发，Crux 将业务逻辑代码作为核心，UI 层则使用了原生框架（如SwiftUI、Jetpack Compose 以及 React/Vue），或者是基于 WebAssembly 的框架（如 Yew）。通过 Crux，你可以在 Rust 中编写无副作用的行为代码，并在 iOS、Android 和网页中共享。

  查看历史条目
• 92. Databricks Asset Bundles

  Databricks 最近发布了 Databricks Asset Bundles (DABs) 的 公开预览版，它包含在 Databricks CLI 0.205 及更高版本中，正成为打包 Databricks 资源进行源代码控制、测试和部署的官方推荐方式。DABs 在我们的团队中逐渐取代了 dbx。DABs 支持将工作流、作业和任务的配置以及要在这些任务中执行的代码打包成一个可以部署到多个环境的捆绑包。它附带了常见资产类型的模板，并支持自定义模板。虽然 DABs 包含笔记本模板并支持将它们部署到生产环境，但我们仍然建议不要将 笔记本用于生产环境，而是鼓励有意地编写生产代码，并采用支持此类工作负载的可维护性、弹性和可扩展性的工程实践。

  查看历史条目
• 93. Electric

  Electric是一种用于移动和 Web 应用程序的本地优先同步框架。本地优先是一种开发范式，其中应用程序代码直接与嵌入式本地数据库对话，并通过双活数据库复制到中央数据库，在后台进行数据同步。使用 Electric，您可以将 SQLite 作为本地嵌入式选项，并将 PostgreSQL 作为中央存储。尽管本地优先极大地改善了用户体验，但它并非没有挑战，CRDT的发明者们已经在 Electric 框架上努力解决这些问题，以减轻困扰。

  查看历史条目
• 94. LiteLLM

  LiteLLM 是一个库，通过 OpenAI API 格式 的标准化交互实现与各种大语言模型（LLM）提供商的 API 的无缝集成。它广泛支持各类提供商和模型，并具备一个用于完成、嵌入和图像生成功能的统一界面。LiteLLM 通过将输入转换为匹配每个提供商特定端点要求的方式，简化了集成。在当前环境下，这特别有价值，因为缺乏标准化的 LLM 提供商 API 规范会导致项目中包含多个 LLM。我们的团队已经利用 LiteLLM 在 LLM 应用中更换底层模型，解决了一个重大的集成挑战。然而，需要认识到，它对相同提示的模型有不同响应，这表明仅仅一致的调用方法可能不足以完全优化完成性能。请注意，LiteLLM 还有其他一些特性，如 代理服务器，这些不在本次讨论范围内。

  查看历史条目
• 95. LLaMA-Factory

  我们一如既往地提醒大家，非必要情况下，不要着急对大语言模型进行微调 —— 这将增加显著的成本和专家资源负担。在必须微调的情况下，我们推荐LLaMA-Factory 。它是一个开源的、易于使用的 LLMs 微调和训练框架。支持LLaMA、BLOOM、Mistral、Baichuan、Qwen 和ChatGLM，它使微调等复杂概念相对容易理解。我们的团队成功地使用了LLaMA-Factory 的 LoRA 调优来训练 LLaMA 7B 模型。如果您需要进行微调，这个框架是值得评估的。

  查看历史条目
• 96. MLX

  MLX 是一个开源的数组框架，专为在苹果芯片上进行高效灵活的机器学习而设计。它使得数据科学家和机器学习工程师可以访问集成的 GPU，并在这个基础上选择最适合其需求的硬件。MLX 的设计灵感来自于诸如 NumPy、PyTorch和 Jax 这样的框架。MLX 的特殊之处在于统一内存模型，它消除了 CPU 和 GPU 之间数据传输的成本，从而实现更高的执行速度。这个特性使得在诸如 iPhone 等设备上运行模型成为可能，为设备端的 AI 应用开辟了巨大的机会空间。尽管这是一个小众领域，但这个框架值得机器学习开发者社区尝试。

  查看历史条目
• 97. Mojo

  Mojo 是一种新的以人工智能为先的编程语言。它旨在通过将 Python 语法和生态系统与系统编程和元编程特性相结合，缩小研究和生产之间的差距。它是第一种利用新的MLIR编译器后端的语言，拥有零成本抽象、自动调优、及早销毁、尾调用优化和更好的单指令/多数据（SIMD）工学等炫酷功能。我们非常喜欢 Mojo，并鼓励您尝试一下。Mojo SDK 目前适用于 Ubuntu 和 macOS 操作系统。

  查看历史条目
• 98. Otter

  Otter 是一个在 Go 语言中非竞争式的缓存库。虽然 Go 语言有几个类似的库，但我们想要强调 Otter 有两个原因：它具有出色的吞吐量并且能够巧妙地实现 S3-FIFO 算法，以获得良好的缓存命中率。Otter 还支持泛型，因此用户可以将任何可比较的类型用作键，并将任何类型用作值。

  查看历史条目
• 99. Pkl

  Pkl 是最初在苹果公司内部使用、现在已开源的配置语言和工具。Pkl 的关键特性是其类型和验证系统，允许在部署之前捕获配置错误。它生成 JSON、.plist、YAML 和 .properties 文件，并拥有广泛的 IDE 和语言集成，包括代码生成。

  查看历史条目
• 100. Rust for UI

  Rust 的影响力与日俱增，很多最近出现的构建工具和命令行工具都是由 Rust 编写的。我们现在观察到 Rust 有移植到 UI 开发领域的趋势。大部分偏向于在前后端使用统一代码语言的开发团队会选择 JavaScript 或者 TypeScript 作为后端语言。然而，开发者现在也可以通过WebAssembly在浏览器里使用 Rust 代码，而这正在变得越来越常见。另外，像 Leptos和sauron 这样的框架会更关注在网页应用开发上，同时Dioxus还有其他的一些框架在网页应用开发之外还提供了跨平台桌面以及移动应用开发的支持。

  查看历史条目
• 101. vLLM

  vLLM 是一个具有高吞吐量和高效内存的大语言模型（LLM）推理和服务引擎，其特别有效的原因在于它可以对传入请求进行连续批处理。它支持几种部署选项，包括使用Ray运行时进行分布式张量并行推理和服务部署，在云中使用SkyPilot、NVIDIA Triton、Docker和LangChain进行部署。我们团队的经验是在本地虚拟机中运行基于 docker 的 vLLM worker，集成了与 OpenAI 兼容的 API 服务器，并在此基础上被一系列应用所利用(包括用于编码辅助以及聊天机器人的 IDE 插件)。团队对此反馈良好。我们的团队利用 vLLM 运行诸如CodeLlama 70B、CodeLlama 7B和Mixtral等模型。引擎的另一个显著特点是其可扩展能力：只需进行一些配置更改，就可以从运行 7B 模型转换为 70B 模型。如果您希望将 LLMs 投入生产，那么 vLLM 值得进一步探索。

  查看历史条目
• 102. Voyager

  Voyager 是为 Android 的 Jetpack Compose 构建的导航库。它支持多种导航类型，包括线性、底部表单、标签和嵌套，其屏幕模型与流行框架如 Koin 和 Hilt 集成。在多平台项目中使用 Jetpack Compose 时，Voyager 是实现跨所有支持平台的常见导航模式的优秀选择。近期，Voyager 的开发又重新活跃起来，并在 2023 年 12 月交付了 1.0 版本。

  查看历史条目
• 103. WGPU

  wgpu 是一个基于 WebGPU API 的Rust图形库，它以能够高效处理 GPU 上通用图形和计算任务的能力而闻名。wgpu 旨在填补由于淘汰旧的图形标准（如 OpenGL 和 WebGL）而留下的空白。它引入了一种现代的图形开发方法，既适用于本地应用程序，也适用于基于 Web 的项目。它与WebAssembly的集成进一步使得图形和计算应用程序能够在浏览器中运行。wgpu 的出现是一种进步，使高级图形编程对 Web 开发人员更加可访问，应用范围更广泛，从游戏到创建复杂的 Web 动画，将 wgpu 定位为一种令人振奋的技术。

  查看历史条目
• 104. Zig

  Zig 是一种新的编程语言，它与 C 语言有许多共同点，但具有更强的类型系统、更容易的内存分配以及对命名空间的支持等，此外还有许多其他特性。Zig 的目标是提供一个非常简单的语言，具有直接明了的编译过程，最小化副作用，并提供可预测、易于追踪的执行。Zig 还简化了访问 LLVM 的跨平台编译能力。我们的一些开发者发现这个特性非常有价值，他们甚至在不编写 Zig 代码的情况下，也能使用 Zig 作为交叉编译器。我们看到行业中的团队使用 Zig 帮助构建 C/C++ 工具链。对于那些正在考虑或已经使用 C 的应用程序，Zig 是一种值得探索的新颖语言。

  查看历史条目

暂缓 谨慎行事

• 105. LangChain

  在上一期 Radar 中，我们提到了一些关于 LangChain 出现的批评言论。自那以后，我们愈发对其充满警惕。虽然这个框架为构建大语言模型应用提供了一套强大的功能，但我们发现它使用起来很困难且过于复杂。LangChain 在这个领域早期获得了人气和注意力，这使得它成为了许多人的默认选择。然而，随着 LangChain 试图发展并快速跟进最新变化，开发者越来越难以跟上这些概念和模式的变更。我们还发现其存在 API 设计不一致且冗长的情况。因此，它经常会掩盖底层实际发生的情况，使得开发者难以理解和控制 LLMs 及其周围的各种模式在背后实际是如何工作的。我们将 LangChain 移动到了“暂缓”环，以反映这一点。在我们的许多用例中，我们发现使用更轻量的的专门框架进行实现就足够了。根据用例，你还可以考虑其他框架，如 Semantic Kernel、Haystack 或 LiteLLM。

  查看历史条目