Rust-script: Run Rust Files & Expressions As Scripts without any Setup

Rust-script

Run Rust script files without any setup or explicit compilation step, with seamless use of crates specified as dependencies inside the scripts.

$ cargo install rust-script
[...]

$ cat script.rs
#!/usr/bin/env rust-script
//! Dependencies can be specified in the script file itself as follows:
//!
//! ```cargo
//! [dependencies]
//! rand = "0.8.0"
//! ```

use rand::prelude::*;

fn main() {
    let x: u64 = random();
    println!("A random number: {}", x);
}

$ ./script.rs
A random number: 9240261453149857564

Rust version 1.60 or newer required.

See the documentation at rust-script.org.

Related projects

• cargo-script - the unmaintained project that rust-script was forked from.
• cargo-eval - maintained fork of cargo-script.
• cargo-play - local Rust playground.
• runner - tool for running Rust snippets.
• scriptisto - language-agnostic "shebang interpreter" that enables you to write scripts in compiled languages.

Download Details:

Author: Fornwall
Source Code: https://github.com/fornwall/rust-script 
License: Apache-2.0, MIT licenses found

#rust #script #cargo 

フリート：Rustの貨物を改善するためのビルドツール

2021年のRustSurveyによると、Rustの長いコンパイル時間は、開発者にとって依然として大きな懸念事項であり、さらなる改善の余地があります。特に、多くの依存関係を持つ大規模なプロジェクトやクレートに関しては、デバッグビルドであっても、コンパイル時のパフォーマンスよりも実行時のパフォーマンスにRustが重点を置くことはかなり罰せられます。これは開発者のエクスペリエンスに悪影響を及ぼし、一部の開発者がまだRustを試してみたがらない理由です。

いずれにせよ、Rustのビルド時間は、特に大規模なプロジェクトの場合、当面の間、遅い側にあり続けるでしょう。この状況を改善するためにいくつかの調整を行うことができますが、ビルド時間を改善するためのフラグや構成オプションなど、新しい開発をセットアップして最新の状態に保つのは面倒です。

この記事では、ローカル開発とCI / CDパイプラインの両方で、Rustのビルド時間を改善するための基本的に1つのツールソリューションであるビルドツールであるFleetについて説明します。

フリートを始めますか？

フリートの焦点は使いやすさにあります。Fleetは、必ずしも車輪の再発明を目的としておらず、Rustビルドの動作方法を完全にオーバーホールまたは再構築することを目的とはしていません。むしろ、既存のビルドツールをラップし、最適化を調整して、ビルドの高速化を処理する構成可能で直感的なツールにします。Linux、Windows、MacOSで動作します。

残念ながら、執筆時点では、Fleetはまだベータ版であり、夜間のみをサポートしていrustcます。ただし、これは積極的に開発されており、stableツールチェーンへの移行は今後の改善のリストに含まれています。とはいえ、Fleetをすぐに使用することに不安がある場合、または現在のプロジェクト設定がFleetと互換性がない場合は、いくつかの良いニュースがあります。ほとんどの最適化は手動で行うことができます。この記事の後半では、それらについて簡単に説明し、それらについて詳しく知ることができるいくつかのリソースを共有します。

まず、Fleetをインストールしてプロジェクトで使用する方法を学ぶことから始めましょう。

Fleetのインストールと使用

Fleetをインストールするには、マシンにRustをインストールする必要があります。それが処理されたら、ターミナルを開いて、それぞれのインストールスクリプトを実行するだけです。

Linuxの場合：

curl -L get.fleet.rs | sh

Windowsの場合：

iwr -useb windows.fleet.rs | iex

それが完了したら、4つのコマンドライン引数のいずれかを使用してFleetを設定できます。

• -h / --help：ヘルプ情報を印刷する
• -V, / --version：バージョン情報を印刷する
• build：フリートプロジェクトを構築する
• run：フリートプロジェクトを実行する

Fleetdocsrunのおよびbuildで追加のオプションの引数を確認できます。これらはCargoにいくぶん似ていますが、1：1の置き換えではないため、プロジェクトに関して特定のニーズがある場合は、さまざまな構成オプションを確認してください。

Fleetを使用した場合と使用しない場合のビルド時間をベンチマークする場合は、クリーンビルドを実行し、キャッシュとプリロードを念頭に置いてください。Fleetは、一部のビルドでCargoよりも最大5倍高速であると主張していますが、コンパイル速度に関するプロジェクトの実際のパフォーマンス向上のサイズは、コンパイルしようとしているコードやその依存関係など、さまざまな要因によって異なります。ハードウェア、SSDとWSL（Windows System for Linux）も同様です。

いずれにせよ、現在プロジェクトのビルドが非常に遅いと感じている場合は、Fleetをインストールして、状況が改善されるかどうかを試してみてください。セットアップに関しては、艦隊はまったく時間がかかりません。

ローカル開発の改善に加えて、フリートのもう1つの重要な目標は、CI/CDパイプラインを改善することです。自動ビルドでFleetを試すことに興味がある場合は、GitHubforLinuxおよびWindowsでのセットアップに関するドキュメントを確認してください。

最適化

この記事の執筆時点で、Fleetは4つの異なる最適化に焦点を当てています。Ramdisk、設定によるビルドの最適化、Sccache、およびカスタムリンカーです。このGitHubチケットに簡単な説明がありますが、特にFleetが移動しstableてさらに開発されると、このリストは時間の経過とともに変化する可能性があります。

さまざまな最適化を1つずつ調べて、実際に何が行われるかを見てみましょう。以下は、詳細な説明ではなく、さまざまな手法の表面的な概要と、それらの使用方法に関するヒントとリソースです。この記事の最後には、Rustでコンパイル時間を手動で改善する方法を説明する素晴らしい記事へのリンクもあります。

Ramdisk

ラムディスク、またはラムドライブは、本質的には、速度を向上させるためにハードディスクであるかのように使用されているRAMのブロックであり、場合によってはハードディスクへのストレスを軽減します。

この最適化のアイデアは/target、ビルドのフォルダーをRamdiskに配置して、ビルドを高速化することです。すでにSSDを使用している場合、これによってビルド時間がわずかに改善されるだけです。ただし、WSL（Windows Subsystem for Linux）または非SSDハードディスクを使用している場合、Ramdiskはパフォーマンスを大幅に向上させる可能性があります。

さまざまなオペレーティングシステム用のRamdiskを作成する方法についてのチュートリアルはたくさんありますが、出発点として、MacOSとLinuxで次の2つの記事を使用できます。

ビルド構成

Fleetは、コンパイラオプションとフラグを使用してビルド構成を操作し、パフォーマンスを向上させます。

この一例は増加codegen-unitsです。これにより、コードのコンパイルに関してLLVMの並列処理が本質的に増加しますが、実行時のパフォーマンスが犠牲になる可能性があります。

これは通常、開発者の経験とより高速なビルドが重要なデバッグビルドでは問題になりませんが、リリースビルドでは間違いなく問題になります。このフラグの詳細については、ドキュメントをご覧ください。

手動で設定するcodegen-unitsのはかなり簡単ですrustflags。~/.cargo/config.toml：に追加するだけです。

[target.x86_64-unknown-linux-gnu]
rustflags = ["-C", "codegen-units=256"]

ただし、前述のように、1リリースビルドでは、これを確実にオーバーライドして戻す必要があります。

もう1つのオプションは、デバッグビルドの最適化レベルを下げることです。これは、実行時のパフォーマンスが低下することを意味しますが、コンパイラーは実行する作業が少なくなります。これは通常、コードベースで反復するために必要な作業です。ただし、これには例外がある場合があります。最適化レベルの詳細については、ドキュメントをご覧ください。

最適化レベルを可能な限り低い設定に設定するには、以下のコードを~/.cargo/config.tomlファイルに追加します。

[target.x86_64-unknown-linux-gnu]
rustflags = ["-C", "opt-level=0"]

繰り返しになりますが、これはデバッグビルドにのみ設定し、リリースビルドには設定しないでください。プロダクションバイナリに完全に最適化されていないコードを含めたくないでしょう。

前述のように、最適化レベルを低くするには、share-genericsフラグを追加してみてください。これにより、プロジェクト内の複数のクレート間でジェネリックスを共有できるようになり、コンパイラーが重複作業を行うのを防ぐことができます。

たとえば、Linuxの場合、これを~/.cargo/config.toml：に追加できます。

[target.x86_64-unknown-linux-gnu]
rustflags = ["-Z", "share-generics=y"]

Sccache

次の最適化は、Mozillaのsccacheを使用することです。Sccacheはコンパイラキャッシュツールです。つまり、たとえばプロジェクトやクレート間でコンパイル結果をキャッシュし、ローカルまたはクラウドストレージのいずれかでディスクに保存しようとします。

これは、依存関係が多く、場合によっては大きな依存関係を持つプロジェクトが複数ある場合に特に役立ちます。これらの異なるプロジェクトのコンパイル結果をキャッシュすると、コンパイラーが作業を複製するのを防ぐことができます。

特にCI/CDパイプラインのコンテキストでは、ビルドは通常、ローカルに存在するキャッシュなしで、新しく生成されたインスタンスまたはコンテナのコンテキストで実行されます。クラウドでバックアップされたsccacheは、ビルド時間を大幅に改善できます。ビルドが実行されるたびに、キャッシュが更新され、後続のビルドで再利用できます。

Fleetはsccacheをビルドにシームレスに導入しますが、これを手動で行うことも特に難しくありません。sccacheのインストールと使用法の指示に従うだけです。

カスタムリンカー

最後に、Fleetはカスタムリンカーを構成して使用し、ビルドのパフォーマンスを向上させます。特に依存関係ツリーが深い大規模なプロジェクトの場合、コンパイラはリンクに多くの時間を費やします。このような場合、可能な限り最速のリンカーを使用すると、コンパイル時間を大幅に改善できます。

以下のリストには、各オペレーティングシステムに使用する正しいリンカーが含まれています。

• Linux：clang + lldただし、Linuxは まもなくカビを使用する可能性があります
• ウィンドウズ：rust-lld.exe
• マックOS：zld

カスタムリンカーの構成は特に難しくありません。基本的には、リンカーをインストールしてから、それを使用するようにCargoを構成することになります。たとえば、zldMac OSでの使用は、次の設定をに追加することで実装できます~/.cargo/config。

[target.x86_64-apple-darwin]
rustflags = ["-C", "link-arg=-fuse-ld=<path to zld>"]

Linuxでは、lld またはmoldがRustの最良の選択です。ライセンスの問題moldのため、Fleetはまだ使用されていませんが、モールドドキュメントのRustの手順に従うだけで、ローカルのビルドで使用できます。

この短い概要の後、この時点でFleetの使用に消極的な場合にビルド時間を改善するための別の素晴らしいリソースは、このトピックに関するMatthiasEndlerのブログ投稿です。

結論

フリートは、特にビルドパイプラインやビルドプロセス全般に煩わされることを好まない開発者にとって、大きな可能性を秘めています。ビルド速度のためのマルチプラットフォームおよびマルチ環境最適化の強力なオールインワンパッケージを提供するため、ビルド時間に苦労している場合は試してみる価値があります。

それ以外に、Fleetがバックグラウンドで実行する最適化のいくつかと、それらが何をするのか、そしてそれらをどのように導入するのかを理解するために少し時間を割いても構わないと思っている場合に、それらがコンパイル速度の苦痛を軽減するのにどのように役立つかについて触れました設定。

とはいえ、多くの場合、ビルド時間が遅い理由は、プロジェクトが非常に多くの、または大きな木枠に依存しているためです。

依存関係を適切に管理し、最小限の考え方で管理します。つまり、必要なものの最小限のバージョンのみを導入するか、既存のクレートを追加する代わりに必要な機能を最初から構築することで、構築時間を短縮するだけでなく、複雑さを軽減し、コードの保守性。

出典：https ：//blog.logrocket.com/introducing-fleet-improving-rusts-cargo/

#rust #cargo 

Fleet: Một Công Cụ Xây Dựng để Cải Thiện Rust's Cargo

Theo Khảo sát Rust năm 2021 , thời gian biên dịch dài của Rust vẫn là một mối quan tâm lớn đối với các nhà phát triển và là một lĩnh vực cần cải thiện hơn nữa. Đặc biệt khi nói đến các dự án lớn hoặc thùng có nhiều phụ thuộc, việc Rust tập trung vào hiệu suất thời gian chạy hơn hiệu suất thời gian biên dịch trở nên khá nghiêm trọng, ngay cả trong các bản dựng gỡ lỗi. Điều này ảnh hưởng tiêu cực đến trải nghiệm của nhà phát triển và là lý do tại sao một số nhà phát triển vẫn không muốn dùng thử Rust.

Trong mọi trường hợp, thời gian xây dựng của Rust sẽ tiếp tục chậm hơn trong tương lai gần, đặc biệt là đối với các dự án lớn hơn. Mặc dù có một số tinh chỉnh mà người ta có thể thực hiện để cải thiện tình trạng này, nhưng việc thiết lập chúng và cập nhật những phát triển mới, như cờ và các tùy chọn cấu hình để cải thiện thời gian xây dựng, rất cồng kềnh.

Trong bài viết này, chúng ta sẽ khám phá Fleet , một công cụ xây dựng về cơ bản là giải pháp một công cụ để cải thiện thời gian xây dựng Rust của bạn, cho cả phát triển cục bộ và cho các đường ống CI / CD.

Bắt đầu với Fleet?

Trọng tâm của Fleet là dễ sử dụng. Fleet không nhất thiết nhằm mục đích phát minh lại bánh xe và đại tu hoàn toàn hoặc tái cấu trúc cách thức hoạt động của Rust Build, mà thay vào đó, nó kết hợp các công cụ xây dựng hiện có, điều chỉnh tối ưu hóa cùng nhau thành một công cụ trực quan, có thể định cấu hình giúp tăng tốc các bản dựng. Nó hoạt động trên Linux, Windows và Mac OS.

Thật không may, tại thời điểm viết bài, Fleet vẫn đang trong giai đoạn thử nghiệm và chỉ hỗ trợ hàng đêm rustc. Tuy nhiên, nó đang được tích cực phát triển và việc chuyển nó sang stablechuỗi công cụ nằm trong danh sách ngắn các cải tiến sắp tới. Điều đó nói rằng, nếu bạn không cảm thấy thoải mái khi sử dụng Fleet ngay lập tức hoặc các thiết lập dự án hiện tại của bạn không tương thích với Fleet, thì có một số tin tốt. Bạn có thể thực hiện hầu hết các tối ưu hóa theo cách thủ công. Ở phần sau của bài viết này, chúng ta sẽ xem qua chúng một cách nhanh chóng, chia sẻ một số tài nguyên mà bạn có thể tìm hiểu thêm về chúng.

Đầu tiên, hãy bắt đầu bằng cách học cách cài đặt Fleet và sử dụng nó trong một dự án.

Cài đặt và sử dụng Fleet

Để cài đặt Fleet, bạn cần cài đặt Rust trên máy của mình. Sau khi đã xử lý xong, chỉ cần mở terminal của bạn và thực thi tập lệnh cài đặt tương ứng:

Đối với Linux:

curl -L get.fleet.rs | sh

Cho cửa sổ:

iwr -useb windows.fleet.rs | iex

Sau khi hoàn tất, bạn có thể thiết lập Hạm đội với một trong bốn đối số dòng lệnh:

• -h / --help: In thông tin trợ giúp
• -V, / --version: Thông tin phiên bản in
• build: Xây dựng dự án Hạm đội
• run: Chạy một dự án Hạm đội

Bạn có thể xem các đối số bổ sung, tùy chọn cho runvà trong tài liệubuild của Hạm đội . Những thứ này hơi giống với Cargo, nhưng nó không phải là sự thay thế 1: 1 , vì vậy hãy đảm bảo kiểm tra các tùy chọn cấu hình khác nhau nếu bạn có nhu cầu cụ thể về dự án của mình.

Nếu bạn định chuẩn thời gian xây dựng có và không có Hạm đội, hãy đảm bảo chạy các bản dựng sạch và lưu ý bộ nhớ đệm và tải trước. Mặc dù Fleet tuyên bố là nhanh hơn Cargo năm lần trên một số bản dựng, nhưng quy mô của hiệu suất thực tế đạt được cho dự án của bạn về tốc độ biên dịch sẽ phụ thuộc vào nhiều yếu tố khác nhau, bao gồm mã bạn đang cố gắng biên dịch và các phụ thuộc của nó như cũng như phần cứng của bạn, SSD so với WSL (Hệ thống Windows cho Linux).

Trong mọi trường hợp, nếu bạn hiện cảm thấy dự án của mình xây dựng rất chậm, hãy cài đặt Fleet và thử xem nó có cải thiện được tình hình hay không. Về mặt thiết lập, Fleet hoàn toàn không mất thời gian.

Ngoài cải tiến phát triển địa phương, một mục tiêu quan trọng khác của Hạm đội là cải thiện đường ống CI / CD. Nếu bạn quan tâm đến việc dùng thử Fleet cho các bản dựng tự động của mình, hãy nhớ xem tài liệu của họ về cách thiết lập nó với GitHub dành cho Linux và Windows .

Tối ưu hóa

Tại thời điểm viết bài này, Fleet tập trung vào bốn cách tối ưu hóa khác nhau: Ramdisk, tối ưu hóa bản dựng thông qua cài đặt, Sccache và một trình liên kết tùy chỉnh. Bạn có thể tìm thấy một mô tả ngắn trong vé GitHub này , nhưng có khả năng danh sách này sẽ thay đổi theo thời gian, đặc biệt là khi Fleet chuyển đến stablevà được phát triển thêm.

Hãy xem xét từng cách tối ưu hóa khác nhau và xem chúng thực sự làm gì. Sau đây sẽ không phải là một mô tả bao quát, mà là một cái nhìn tổng quan hời hợt về các kỹ thuật khác nhau với một số mẹo và tài nguyên về cách sử dụng chúng. Ở cuối bài viết này, cũng có một liên kết đến một bài báo tuyệt vời mô tả cách cải thiện thời gian biên dịch trong Rust theo cách thủ công.

Ramdisk

Ramdisk, hay Ramdrive, về cơ bản chỉ là một khối RAM được sử dụng như thể nó là một đĩa cứng để cải thiện tốc độ và trong một số trường hợp, gây ít căng thẳng hơn cho đĩa cứng.

Ý tưởng của việc tối ưu hóa này là đặt /targetthư mục của bản dựng của bạn vào đĩa Ram để tăng tốc quá trình xây dựng. Nếu bạn đã có SSD, điều này sẽ chỉ cải thiện một chút thời gian xây dựng. Tuy nhiên, nếu bạn sử dụng WSL (Hệ thống con của Windows dành cho Linux) hoặc đĩa cứng không phải SSD, Ramdisk có khả năng cải thiện hiệu suất một cách đáng kể.

Có rất nhiều hướng dẫn về cách tạo đĩa Ram cho các hệ điều hành khác nhau, nhưng để bắt đầu, bạn có thể sử dụng hai bài viết sau trên Mac OS và Linux .

Xây dựng cấu hình

Fleet điều khiển cấu hình bản dựng bằng cách sử dụng các tùy chọn và cờ trình biên dịch để tăng hiệu suất.

Một ví dụ về điều này đang tăng lên codegen-units. Điều này về cơ bản làm tăng tính song song trong LLVM khi biên dịch mã của bạn, nhưng nó đi kèm với chi phí tiềm năng về hiệu suất thời gian chạy.

Đây thường không phải là vấn đề đối với các bản dựng gỡ lỗi, nơi mà kinh nghiệm của nhà phát triển và các bản dựng nhanh hơn rất quan trọng, nhưng chắc chắn đối với các bản dựng phát hành. Bạn có thể đọc thêm về cờ này trong tài liệu .

Cài đặt codegen-unitstheo cách thủ công khá dễ dàng, chỉ cần thêm nó rustflagsvào ~/.cargo/config.toml:

[target.x86_64-unknown-linux-gnu]
rustflags = ["-C", "codegen-units=256"]

Tuy nhiên, như đã đề cập ở trên, bạn chắc chắn nên ghi đè điều này trở lại 1cho các bản dựng phát hành.

Một tùy chọn khác là giảm mức tối ưu hóa cho các bản dựng gỡ lỗi của bạn. Mặc dù điều này có nghĩa là hiệu suất thời gian chạy sẽ bị ảnh hưởng, trình biên dịch có ít công việc phải làm hơn, đây thường là những gì bạn muốn lặp lại trên cơ sở mã của mình. Tuy nhiên, có thể có ngoại lệ cho điều này; bạn có thể đọc thêm về các cấp độ tối ưu hóa trong tài liệu .

Để đặt mức tối ưu hóa thành cài đặt thấp nhất có thể, hãy thêm mã bên dưới vào ~/.cargo/config.tomltệp của bạn:

[target.x86_64-unknown-linux-gnu]
rustflags = ["-C", "opt-level=0"]

Một lần nữa, hãy đảm bảo chỉ đặt điều này cho các bản dựng gỡ lỗi chứ không phải cho các bản dựng phát hành. Bạn sẽ không muốn có mã hoàn toàn chưa được tối ưu hóa trong tệp nhị phân sản xuất của mình.

Đối với các mức tối ưu hóa thấp hơn, như đã đề cập, bạn có thể thử thêm share-genericscờ, cho phép chia sẻ các chỉ số chung giữa nhiều thùng trong dự án của bạn, có khả năng tiết kiệm trình biên dịch khỏi thực hiện công việc trùng lặp.

Ví dụ: đối với Linux, bạn có thể thêm cái này vào ~/.cargo/config.toml:

[target.x86_64-unknown-linux-gnu]
rustflags = ["-Z", "share-generics=y"]

Sccache

Cách tối ưu hóa tiếp theo là sử dụng sccache của Mozilla . Sccache là một công cụ biên dịch bộ nhớ đệm, có nghĩa là nó cố gắng lưu vào bộ đệm các kết quả biên dịch, ví dụ, trên các dự án hoặc thùng, lưu trữ chúng trên đĩa, cục bộ hoặc trong bộ nhớ đám mây.

Điều này đặc biệt hữu ích nếu bạn có một số dự án với nhiều phụ thuộc và đôi khi lớn. Lưu vào bộ đệm kết quả của việc biên dịch các dự án khác nhau này có thể ngăn trình biên dịch trùng lặp công việc.

Đặc biệt trong bối cảnh đường ống CI / CD, nơi mà các bản dựng thường được thực thi trong bối cảnh một phiên bản hoặc vùng chứa mới được tạo ra mà không có bất kỳ bộ nhớ cache hiện tại cục bộ nào, sccache được hỗ trợ bởi đám mây có thể cải thiện đáng kể thời gian xây dựng. Mỗi khi bản dựng chạy, bộ nhớ đệm được cập nhật và có thể được sử dụng lại bởi các bản dựng tiếp theo.

Fleet đưa sccache vào các bản dựng của mình một cách liền mạch, nhưng thực hiện việc này theo cách thủ công cũng không đặc biệt khó khăn. Chỉ cần làm theo hướng dẫn cài đặt và sử dụng sccache.

Trình liên kết tùy chỉnh

Cuối cùng, Fleet cũng định cấu hình và sử dụng trình liên kết tùy chỉnh để cải thiện hiệu suất xây dựng. Đặc biệt đối với các dự án lớn có cây phụ thuộc sâu, trình biên dịch dành nhiều thời gian để liên kết. Trong những trường hợp này, việc sử dụng trình liên kết nhanh nhất có thể có thể cải thiện đáng kể thời gian biên dịch.

Danh sách dưới đây bao gồm trình liên kết chính xác để sử dụng cho từng hệ điều hành:

• Linux: clang + lldtuy nhiên, Linux có thể sẽ  sớm sử dụng khuôn
• Các cửa sổ:rust-lld.exe
• Hệ điều hành Mac:zld

Việc cấu hình một trình liên kết tùy chỉnh không đặc biệt khó. Về cơ bản, nó hoàn thành việc cài đặt trình liên kết và sau đó định cấu hình Cargo để sử dụng nó. Ví dụ: sử dụng zldtrên Mac OS có thể được triển khai bằng cách thêm cấu hình sau vào ~/.cargo/config:

[target.x86_64-apple-darwin]
rustflags = ["-C", "link-arg=-fuse-ld=<path to zld>"]

Trên Linux, lld hoặc mold, là lựa chọn tốt nhất cho Rust. Fleet chưa sử dụng molddo vấn đề giấy phép , nhưng bạn có thể sử dụng nó trong bản dựng của mình cục bộ bằng cách chỉ cần làm theo các bước dành cho Rust trong tài liệu khuôn .

Sau phần tổng quan ngắn này, một tài nguyên tuyệt vời khác để cải thiện thời gian xây dựng của bạn nếu bạn không muốn sử dụng Fleet vào thời điểm này là bài đăng trên blog của Matthias Endler về chủ đề này.

Sự kết luận

Hạm đội có tiềm năng lớn, đặc biệt là đối với các nhà phát triển không thích loanh quanh với việc xây dựng đường ống hoặc xây dựng quy trình nói chung. Nó cung cấp một gói tối ưu hóa đa nền tảng và đa môi trường mạnh mẽ, đa năng cho tốc độ xây dựng, vì vậy rất đáng để thử nếu bạn đang gặp khó khăn với thời gian xây dựng.

Ngoài ra, chúng tôi đã đề cập đến một số tối ưu hóa mà Fleet thực hiện ở chế độ nền và cách những điều đó sẽ giúp giảm bớt khó khăn về tốc độ biên dịch của bạn nếu bạn sẵn sàng bỏ ra một ít thời gian để tìm ra những gì chúng làm và cách giới thiệu chúng trong thành lập.

Điều đó nói rằng, thông thường, lý do đằng sau thời gian xây dựng chậm là do một dự án phụ thuộc vào rất nhiều hoặc thùng lớn.

Quản lý tốt các phụ thuộc của bạn và với tư duy tối giản, nghĩa là chỉ giới thiệu phiên bản tối thiểu của bất kỳ thứ gì bạn cần hoặc xây dựng chức năng cần thiết từ đầu thay vì thêm một thùng hiện có, sẽ không chỉ giữ cho thời gian xây dựng của bạn thấp mà còn giảm độ phức tạp và tăng khả năng bảo trì mã của bạn.

Nguồn: https://blog.logrocket.com/introductioning-fleet-improving-rusts-cargo/

#rust #cargo 

Fleet: Una Herramienta De Construcción Para Mejorar Rust's Cargo

Según la Encuesta de Rust de 2021, el largo tiempo de compilación de Rust sigue siendo una gran preocupación para los desarrolladores y un área para seguir mejorando. Especialmente cuando se trata de grandes proyectos o cajas con muchas dependencias, el enfoque de Rust en el rendimiento del tiempo de ejecución sobre el rendimiento del tiempo de compilación se vuelve bastante arduo, incluso en compilaciones de depuración. Esto afecta negativamente la experiencia del desarrollador y es una razón por la cual algunos desarrolladores todavía no están dispuestos a probar Rust.

En cualquier caso, los tiempos de compilación de Rust seguirán siendo más lentos en el futuro previsible, especialmente para proyectos más grandes. Si bien hay algunos ajustes que se pueden hacer para mejorar esta situación, configurarlos y mantenerlos actualizados con nuevos desarrollos, como banderas y opciones de configuración para mejorar los tiempos de compilación, es engorroso.

En este artículo, exploraremos Fleet , una herramienta de compilación que es esencialmente una solución de una sola herramienta para mejorar los tiempos de compilación de Rust, tanto para el desarrollo local como para las canalizaciones de CI/CD.

¿Empezando con Fleet?

El enfoque de Fleet está en la facilidad de uso. Fleet no tiene como objetivo necesariamente reinventar la rueda y revisar o reestructurar por completo la forma en que funcionan las compilaciones de Rust, sino que envuelve las herramientas de compilación existentes, ajustando las optimizaciones en una herramienta configurable e intuitiva que se encarga de acelerar las compilaciones. Funciona en Linux, Windows y Mac OS.

Desafortunadamente, en el momento de escribir este artículo, Fleet todavía está en versión beta y solo es compatible con Nightly rustc. Sin embargo, se está desarrollando activamente y moverlo a la cadena de stableherramientas está en la breve lista de próximas mejoras. Dicho esto, si no se siente cómodo usando Fleet de inmediato, o si las configuraciones de su proyecto actual son incompatibles con Fleet, hay buenas noticias. Puede hacer la mayoría de las optimizaciones manualmente. Más adelante en este artículo, los repasaremos rápidamente y compartiremos algunos recursos donde puede aprender más sobre ellos.

Primero, comencemos aprendiendo cómo instalar Fleet y usarlo en un proyecto.

Instalación y uso de Flota

Para instalar Fleet, necesitará Rust instalado en su máquina. Una vez que se solucione, simplemente abra su terminal y ejecute el script de instalación respectivo:

Para Linux:

curl -L get.fleet.rs | sh

Para ventanas:

iwr -useb windows.fleet.rs | iex

Una vez hecho esto, puede configurar Fleet con uno de los cuatro argumentos de la línea de comandos:

• -h / --help: Imprimir información de ayuda
• -V, / --version: información de la versión de impresión
• build: Crear un proyecto de flota
• run: ejecutar un proyecto de flota

Puede consultar los argumentos opcionales adicionales para runy en los documentosbuild de la flota . Estos son algo similares a Cargo, pero no es un reemplazo 1: 1 , así que asegúrese de revisar las diferentes opciones de configuración si tiene necesidades particulares en términos de su proyecto.

Si planea comparar los tiempos de compilación con y sin Fleet, asegúrese de ejecutar compilaciones limpias y tenga en cuenta el almacenamiento en caché y la precarga. Si bien Fleet afirma ser hasta cinco veces más rápido que Cargo en algunas compilaciones, el tamaño de las ganancias de rendimiento reales para su proyecto en términos de velocidad de compilación dependerá de muchos factores diferentes, incluido el código que está tratando de compilar y sus dependencias como así como su hardware, SSD vs. WSL (Sistema Windows para Linux).

En cualquier caso, si actualmente siente que su proyecto se desarrolla muy lentamente, instale Fleet y pruébelo para ver si mejora la situación. En términos de configuración, Fleet no toma tiempo en absoluto.

Además de las mejoras de desarrollo local, otro objetivo importante de Fleet es mejorar las tuberías de CI/CD. Si está interesado en probar Fleet para sus compilaciones automatizadas, asegúrese de consultar sus documentos sobre cómo configurarlo con GitHub para Linux y Windows .

Optimizaciones

Al momento de escribir este artículo, Fleet se enfoca en cuatro optimizaciones diferentes: Ramdisk, optimizando la configuración de compilación, Sccache y un enlazador personalizado. Puede encontrar una breve descripción en este ticket de GitHub , pero es probable que esta lista cambie con el tiempo, especialmente cuando Fleet se mueva stabley se desarrolle más.

Repasemos las diferentes optimizaciones una por una y veamos qué hacen realmente. La siguiente no será una descripción extensa, sino una descripción general superficial de las diferentes técnicas con algunos consejos y recursos sobre cómo usarlas. Al final de este artículo, también hay un enlace a un artículo fantástico que describe cómo mejorar manualmente los tiempos de compilación en Rust.

ramdisk

Un Ramdisk, o Ramdrive, es esencialmente solo un bloque de RAM que se utiliza como si fuera un disco duro para mejorar la velocidad y, en algunos casos, ejercer menos presión sobre los discos duros.

La idea de esta optimización es colocar la /targetcarpeta de su compilación en un Ramdisk para acelerar la compilación. Si ya tiene un SSD, esto solo mejorará marginalmente los tiempos de construcción. Pero, si usa WSL (Subsistema de Windows para Linux) o un disco duro que no sea SSD, Ramdisk tiene el potencial de mejorar enormemente el rendimiento.

Hay muchos tutoriales sobre cómo crear discos RAM para los diferentes sistemas operativos, pero como punto de partida, puede usar los siguientes dos artículos en Mac OS y en Linux .

Configuración de compilación

Fleet manipula la configuración de compilación mediante el uso de opciones y marcas del compilador para aumentar el rendimiento.

Un ejemplo de esto es el aumento codegen-units. Esto esencialmente aumenta el paralelismo en LLVM cuando se trata de compilar su código, pero tiene el costo potencial del rendimiento del tiempo de ejecución.

Por lo general, esto no es un problema para las compilaciones de depuración, donde la experiencia del desarrollador y las compilaciones más rápidas son importantes, pero definitivamente para las compilaciones de lanzamiento. Puede leer más sobre esta bandera en los documentos .

La configuración codegen-unitsmanual es bastante fácil, solo agréguela a rustflagssu ~/.cargo/config.toml:

[target.x86_64-unknown-linux-gnu]
rustflags = ["-C", "codegen-units=256"]

Sin embargo, como se mencionó anteriormente, definitivamente debe anular esto para las 1versiones de lanzamiento.

Otra opción es reducir el nivel de optimización de las compilaciones de depuración. Si bien esto significa que el rendimiento en tiempo de ejecución se verá afectado, el compilador tiene menos trabajo que hacer, que generalmente es lo que desea para iterar en su base de código. Sin embargo, puede haber excepciones a esto; puede leer más sobre los niveles de optimización en los documentos .

Para establecer el nivel de optimización en la configuración más baja posible, agregue el siguiente código a su ~/.cargo/config.tomlarchivo:

[target.x86_64-unknown-linux-gnu]
rustflags = ["-C", "opt-level=0"]

Nuevamente, asegúrese de configurar esto solo para compilaciones de depuración y no para compilaciones de lanzamiento. No le gustaría tener un código completamente no optimizado en su binario de producción.

Para niveles de optimización más bajos, como se mencionó, puede intentar agregar el share-genericsindicador, lo que permite compartir genéricos entre varias cajas en su proyecto, lo que podría evitar que el compilador realice un trabajo duplicado.

Por ejemplo, para Linux, podría agregar esto a su ~/.cargo/config.toml:

[target.x86_64-unknown-linux-gnu]
rustflags = ["-Z", "share-generics=y"]

Escache

La siguiente optimización es usar sccache de Mozilla . Sccache es una herramienta de almacenamiento en caché del compilador, lo que significa que intenta almacenar en caché los resultados de la compilación, por ejemplo, entre proyectos o cajas, almacenándolos en un disco, ya sea localmente o en la nube.

Esto es particularmente útil si tiene varios proyectos con muchas y, a veces, grandes dependencias. El almacenamiento en caché de los resultados de la compilación de estos diferentes proyectos puede evitar que el compilador duplique el trabajo.

Especialmente en el contexto de canalizaciones de CI/CD, donde las compilaciones generalmente se ejecutan en el contexto de una instancia o contenedor recién generado sin ningún caché existente localmente, sccache respaldado en la nube puede mejorar drásticamente los tiempos de compilación. Cada vez que se ejecuta una compilación, la memoria caché se actualiza y se puede reutilizar en compilaciones posteriores.

Fleet introduce a la perfección sccache en sus compilaciones, pero hacerlo manualmente tampoco es particularmente difícil. Simplemente siga las instrucciones de instalación y uso de sccache.

Enlazador personalizado

Finalmente, Fleet también configura y usa un enlazador personalizado para mejorar el rendimiento de la compilación. Especialmente para proyectos grandes con árboles de dependencia profundos, el compilador dedica mucho tiempo a la vinculación. En estos casos, usar el enlazador más rápido posible puede mejorar mucho los tiempos de compilación.

La siguiente lista incluye el enlazador correcto para cada sistema operativo:

• Linux: clang + lldsin embargo, Linux podría usar  moho pronto
• Ventanas:rust-lld.exe
• Mac OS:zld

Configurar un enlazador personalizado no es particularmente difícil. Esencialmente, todo se reduce a instalar el enlazador y luego configurar Cargo para usarlo. Por ejemplo, el uso zlden Mac OS se puede implementar agregando la siguiente configuración a su ~/.cargo/config:

[target.x86_64-apple-darwin]
rustflags = ["-C", "link-arg=-fuse-ld=<path to zld>"]

En Linux, lld o mold, son las mejores opciones para Rust. Fleet aún no se usa molddebido a problemas de licencia , pero puede usarlo en su compilación localmente simplemente siguiendo los pasos para Rust in the mold docs .

Después de esta breve descripción general, otro recurso fantástico para mejorar sus tiempos de compilación si es reacio a usar Fleet en este momento es la publicación de blog de Matthias Endler sobre el tema.

Conclusión

Fleet tiene un gran potencial, especialmente para los desarrolladores que no disfrutan preocuparse por las canalizaciones de compilación o los procesos de compilación en general. Proporciona un poderoso paquete todo en uno de optimizaciones multiplataforma y multientorno para la velocidad de compilación, por lo que vale la pena intentarlo si tiene problemas con los tiempos de compilación.

Más allá de eso, mencionamos algunas de las optimizaciones que Fleet realiza en segundo plano y cómo ayudarán a aliviar el dolor de la velocidad de compilación si está dispuesto a dedicar un poco de tiempo para averiguar qué hacen y cómo introducirlas en su configuración.

Dicho esto, muchas veces, la razón detrás de los tiempos de construcción lentos es que un proyecto depende de muchas o grandes cajas.

Administrar bien sus dependencias y con una mentalidad minimalista, lo que significa introducir solo la versión mínima de lo que necesite o crear la funcionalidad requerida desde cero en lugar de agregar una caja existente, no solo mantendrá bajos los tiempos de compilación, sino que también reducirá la complejidad y aumentará la mantenibilidad de su código.

Fuente: https://blog.logrocket.com/introducing-fleet-improving-rusts-cargo/

#rust #cargo 

Fleet: Uma Ferramenta De Construção Para Melhorar A Carga Da Rust

De acordo com o 2021 Rust Survey , o longo tempo de compilação do Rust ainda é uma grande preocupação para os desenvolvedores e uma área para melhorias adicionais. Especialmente quando se trata de grandes projetos ou caixas com muitas dependências, o foco do Rust no desempenho do tempo de execução sobre o desempenho do tempo de compilação se torna bastante punitivo, mesmo em compilações de depuração. Isso afeta negativamente a experiência do desenvolvedor e é uma razão pela qual alguns desenvolvedores ainda não estão dispostos a experimentar o Rust.

De qualquer forma, os tempos de construção do Rust continuarão mais lentos no futuro próximo, especialmente para projetos maiores. Embora existam alguns ajustes que podem ser feitos para melhorar essa situação, configurá-los e mantê-los atualizados com novos desenvolvimentos, como sinalizadores e opções de configuração para tempos de compilação aprimorados, é complicado.

Neste artigo, exploraremos o Fleet , uma ferramenta de compilação que é essencialmente uma solução de ferramenta única para melhorar os tempos de compilação do Rust, tanto para desenvolvimento local quanto para pipelines de CI/CD.

Começando com o Fleet?

O foco do Fleet é a facilidade de uso. O Fleet não visa necessariamente reinventar a roda e revisar ou reestruturar completamente a maneira como as compilações do Rust funcionam, mas envolve as ferramentas de compilação existentes, aprimorando as otimizações em uma ferramenta configurável e intuitiva que cuida da aceleração das compilações. Funciona em Linux, Windows e Mac OS.

Infelizmente, no momento em que escrevo, o Fleet ainda está na versão beta e suporta apenas arquivos rustc. No entanto, ele está sendo desenvolvido ativamente e movê-lo para a cadeia de stableferramentas está na pequena lista de melhorias futuras. Dito isso, se você não se sentir confortável usando o Fleet imediatamente, ou se as configurações atuais do seu projeto forem incompatíveis com o Fleet, há boas notícias. Você pode fazer a maioria das otimizações manualmente. Mais adiante neste artigo, vamos analisá-los rapidamente, compartilhando alguns recursos onde você pode aprender mais sobre eles.

Primeiro, vamos começar aprendendo como instalar o Fleet e usá-lo em um projeto.

Instalando e usando o Fleet

Para instalar o Fleet, você precisará do Rust instalado em sua máquina. Feito isso, basta abrir seu terminal e executar o respectivo script de instalação:

Para Linux:

curl -L get.fleet.rs | sh

Para Windows:

iwr -useb windows.fleet.rs | iex

Feito isso, você pode configurar o Fleet com um dos quatro argumentos de linha de comando:

• -h / --help: Imprimir informações de ajuda
• -V, / --version: Informações da versão de impressão
• build: Construir um projeto de frota
• run: Executar um projeto de frota

Você pode conferir os argumentos opcionais adicionais para rune nos documentosbuild do Fleet . Eles são um pouco semelhantes ao Cargo, mas não são uma substituição 1:1 , portanto, verifique as diferentes opções de configuração se você tiver necessidades específicas em termos de seu projeto.

Se você planeja comparar os tempos de compilação com e sem o Fleet, certifique-se de executar compilações limpas e manter o armazenamento em cache e o pré-carregamento em mente. Embora o Fleet afirme ser até cinco vezes mais rápido do que o Cargo em algumas compilações, o tamanho dos ganhos reais de desempenho do seu projeto em termos de velocidade de compilação dependerá de muitos fatores diferentes, incluindo o código que você está tentando compilar e suas dependências como bem como seu hardware, SSD vs. WSL (Sistema Windows para Linux).

De qualquer forma, se você acha que seu projeto está sendo compilado muito lentamente, instale o Fleet e experimente para ver se isso melhora a situação. Em termos de configuração, o Fleet não leva tempo.

Além das melhorias no desenvolvimento local, outro objetivo importante do Fleet é melhorar os pipelines de CI/CD. Se você estiver interessado em experimentar o Fleet para suas compilações automatizadas, verifique os documentos sobre como configurá-lo com o GitHub para Linux e Windows .

Otimizações

No momento da redação deste artigo, o Fleet se concentra em quatro otimizações diferentes: Ramdisk, otimizando a compilação por meio de configurações, Sccache e um vinculador personalizado. Você pode encontrar uma breve descrição neste ticket do GitHub , mas é provável que essa lista mude com o tempo, especialmente quando o Fleet mudar para stablee for desenvolvido.

Vamos examinar as diferentes otimizações uma a uma e ver o que elas realmente fazem. A seguir não será uma descrição extensa, mas sim uma visão superficial das diferentes técnicas com algumas dicas e recursos sobre como usá-las. No final deste artigo, há também um link para um artigo fantástico descrevendo como melhorar manualmente os tempos de compilação no Rust.

Ramdisk

Um Ramdisk, ou Ramdrive, é essencialmente apenas um bloco de RAM que está sendo usado como se fosse um disco rígido para melhorar a velocidade e, em alguns casos, colocar menos estresse nos discos rígidos.

A ideia dessa otimização é colocar a /targetpasta do seu build em um Ramdisk para acelerar o build. Se você já possui um SSD, isso melhorará apenas marginalmente os tempos de compilação. Mas, se você usa WSL (Windows Subsystem for Linux) ou um disco rígido não SSD, o Ramdisk tem o potencial de melhorar muito o desempenho.

Existem muitos tutoriais sobre como criar Ramdisks para os diferentes sistemas operacionais, mas como ponto de partida, você pode usar os dois artigos a seguir no Mac OS e no Linux .

Configuração de compilação

O Fleet manipula a configuração de compilação usando opções e sinalizadores do compilador para aumentar o desempenho.

Um exemplo disso está aumentando codegen-units. Isso basicamente aumenta o paralelismo no LLVM quando se trata de compilar seu código, mas tem um custo potencial de desempenho em tempo de execução.

Isso geralmente não é um problema para compilações de depuração, nas quais a experiência do desenvolvedor e compilações mais rápidas são importantes, mas definitivamente para compilações de lançamento. Você pode ler mais sobre esse sinalizador nos documentos .

Definir codegen-unitsmanualmente é bastante fácil, basta adicioná-lo ao rustflagsseu ~/.cargo/config.toml:

[target.x86_64-unknown-linux-gnu]
rustflags = ["-C", "codegen-units=256"]

No entanto, como mencionado acima, você definitivamente deve substituir isso de volta 1para compilações de lançamento.

Outra opção é diminuir o nível de otimização para suas compilações de depuração. Embora isso signifique que o desempenho em tempo de execução será prejudicado, o compilador terá menos trabalho a fazer, o que geralmente é o que você deseja para iterar em sua base de código. No entanto, pode haver exceções a isso; você pode ler mais sobre os níveis de otimização nos documentos .

Para definir o nível de otimização para a configuração mais baixa possível, adicione o código abaixo ao seu ~/.cargo/config.tomlarquivo:

[target.x86_64-unknown-linux-gnu]
rustflags = ["-C", "opt-level=0"]

Novamente, certifique-se de definir isso apenas para compilações de depuração e não para compilações de lançamento. Você não gostaria de ter um código totalmente não otimizado em seu binário de produção.

Para níveis de otimização mais baixos, como mencionado, você pode tentar adicionar o share-genericssinalizador, que permite o compartilhamento de genéricos entre várias caixas em seu projeto, potencialmente evitando que o compilador faça trabalho duplicado.

Por exemplo, para Linux, você pode adicionar isso ao seu ~/.cargo/config.toml:

[target.x86_64-unknown-linux-gnu]
rustflags = ["-Z", "share-generics=y"]

Sccache

A próxima otimização está usando o sccache do Mozilla . Sccache é uma ferramenta de armazenamento em cache do compilador, o que significa que tenta armazenar em cache os resultados da compilação, por exemplo, em projetos ou caixas, armazenando-os em um disco, localmente ou em armazenamento em nuvem.

Isso é particularmente útil se você tiver vários projetos com muitas e, às vezes, grandes dependências. O armazenamento em cache dos resultados da compilação desses diferentes projetos pode impedir que o compilador duplique o trabalho.

Especialmente no contexto de pipelines de CI/CD, em que as compilações geralmente são executadas no contexto de uma instância ou contêiner recém-gerado sem nenhum cache existente localmente, o sccache baseado em nuvem pode melhorar drasticamente os tempos de compilação. Sempre que uma compilação é executada, o cache é atualizado e pode ser reutilizado por compilações subsequentes.

O Fleet introduz perfeitamente o sccache em suas compilações, mas fazer isso manualmente também não é particularmente difícil. Basta seguir as instruções para instalação e uso do sccache.

Vinculador personalizado

Por fim, o Fleet também configura e usa um vinculador personalizado para melhorar o desempenho da compilação. Especialmente para projetos grandes com árvores de dependências profundas, o compilador gasta muito tempo vinculando. Nesses casos, usar o vinculador mais rápido possível pode melhorar muito os tempos de compilação.

A lista abaixo inclui o vinculador correto a ser usado para cada sistema operacional:

• Linux: clang + lldno entanto, o Linux pode potencialmente usar  molde em breve
• Janelas:rust-lld.exe
• Mac OS:zld

A configuração de um vinculador personalizado não é particularmente difícil. Essencialmente, tudo se resume a instalar o vinculador e, em seguida, configurar o Cargo para usá-lo. Por exemplo, o uso zldno Mac OS pode ser implementado adicionando a seguinte configuração ao seu ~/.cargo/config:

[target.x86_64-apple-darwin]
rustflags = ["-C", "link-arg=-fuse-ld=<path to zld>"]

No Linux, lld ou mold, são as melhores opções para Rust. O Fleet ainda não é usado molddevido a problemas de licença , mas você pode usá-lo em sua compilação localmente, simplesmente seguindo as etapas para Rust nos documentos do molde .

Após esta breve visão geral, outro recurso fantástico para melhorar seus tempos de construção se você estiver relutante em usar o Fleet neste momento é a postagem no blog de Matthias Endler sobre o tópico.

Conclusão

O Fleet tem um grande potencial, especialmente para desenvolvedores que não gostam de se preocupar com pipelines de compilação ou processos de compilação em geral. Ele fornece um pacote poderoso e completo de otimizações multiplataforma e multiambiente para velocidade de compilação, portanto, vale a pena tentar se você estiver enfrentando dificuldades com os tempos de compilação.

Além disso, abordamos algumas das otimizações que o Fleet realiza em segundo plano e como elas ajudarão a aliviar sua dor de velocidade de compilação se você estiver disposto a dedicar um pouco de tempo para descobrir o que elas fazem e como apresentá-las em seu configurar.

Dito isto, muitas vezes, a razão por trás dos tempos de construção lentos é que um projeto depende de muitos ou grandes caixotes.

Gerenciar bem suas dependências e com uma mentalidade minimalista, o que significa introduzir apenas a versão mínima do que você precisa ou construir a funcionalidade necessária do zero em vez de adicionar uma caixa existente, não apenas manterá seus tempos de compilação baixos, mas também reduzirá a complexidade e aumentará o manutenção do seu código.

Fonte: https://blog.logrocket.com/introducing-fleet-improving-rusts-cargo/

#rust #cargo 

Fleet : Un Outil De Construction Pour Améliorer La Cargaison De Rust

Selon le Rust Survey 2021 , le long temps de compilation de Rust est toujours une grande préoccupation pour les développeurs et un domaine à améliorer. Surtout lorsqu'il s'agit de grands projets ou de caisses avec de nombreuses dépendances, l'accent mis par Rust sur les performances d'exécution plutôt que sur les performances de compilation devient plutôt pénible, même dans les versions de débogage. Cela a un impact négatif sur l'expérience des développeurs et c'est la raison pour laquelle certains développeurs ne veulent toujours pas essayer Rust.

Dans tous les cas, les temps de construction de Rust continueront d'être plus lents dans un avenir prévisible, en particulier pour les projets plus importants. Bien qu'il y ait quelques ajustements que l'on peut apporter pour améliorer cette situation, les configurer et se tenir au courant des nouveaux développements, comme les drapeaux et les options de configuration pour améliorer les temps de construction, est fastidieux.

Dans cet article, nous allons explorer Fleet , un outil de build qui est essentiellement une solution à un seul outil pour améliorer vos temps de build Rust, à la fois pour le développement local et pour les pipelines CI/CD.

Vous débutez avec Fleet ?

Fleet se concentre sur la facilité d'utilisation. Fleet ne vise pas nécessairement à réinventer la roue et à réviser ou restructurer complètement le fonctionnement des builds Rust, mais plutôt à encapsuler les outils de build existants, en ajustant les optimisations ensemble dans un outil configurable et intuitif qui s'occupe d'accélérer les builds. Il fonctionne sous Linux, Windows et Mac OS.

Malheureusement, au moment de la rédaction de cet article, Fleet est toujours en version bêta et ne prend en charge que la nuit rustc. Cependant, il est activement développé et son transfert vers la chaîne d' stableoutils figure sur la courte liste des améliorations à venir. Cela dit, si vous ne vous sentez pas à l'aise avec Fleet tout de suite, ou si les configurations de votre projet actuel sont incompatibles avec Fleet, il y a de bonnes nouvelles. Vous pouvez effectuer la plupart des optimisations manuellement. Plus loin dans cet article, nous les passerons rapidement en revue, en partageant quelques ressources où vous pourrez en apprendre davantage à leur sujet.

Tout d'abord, commençons par apprendre à installer Fleet et à l'utiliser dans un projet.

Installation et utilisation de Fleet

Pour installer Fleet, vous aurez besoin de Rust installé sur votre machine. Une fois cela fait, ouvrez simplement votre terminal et exécutez le script d'installation correspondant :

Pour Linux :

curl -L get.fleet.rs | sh

Pour les fenêtres:

iwr -useb windows.fleet.rs | iex

Une fois cela fait, vous pouvez configurer Fleet avec l'un des quatre arguments de ligne de commande :

• -h / --help: Imprimer les informations d'aide
• -V, / --version: Imprimer les informations de version
• build: Construire un projet de flotte
• run : exécuter un projet de flotte

Vous pouvez consulter les arguments supplémentaires et facultatifs pour runet dans les documentsbuild Fleet . Celles-ci sont quelque peu similaires à Cargo, mais il ne s'agit pas d'un remplacement 1: 1 , alors assurez-vous de vérifier les différentes options de configuration si vous avez des besoins particuliers en termes de projet.

Si vous envisagez de comparer les temps de build avec et sans Fleet, assurez-vous d'exécuter des builds propres et de garder à l'esprit la mise en cache et le préchargement. Alors que Fleet prétend être jusqu'à cinq fois plus rapide que Cargo sur certaines versions, la taille des gains de performances réels pour votre projet en termes de vitesse de compilation dépendra de nombreux facteurs différents, y compris le code que vous essayez de compiler et ses dépendances comme ainsi que votre matériel, SSD vs WSL (Windows System for Linux).

Dans tous les cas, si vous pensez actuellement que votre projet se construit très lentement, installez Fleet et essayez-le pour voir s'il améliore la situation. En termes de configuration, Fleet ne prend pas de temps du tout.

En plus des améliorations du développement local, un autre objectif important de Fleet est d'améliorer les pipelines CI/CD. Si vous souhaitez essayer Fleet pour vos builds automatisés, assurez-vous de consulter leurs documents sur la configuration avec GitHub pour Linux et Windows .

Optimisations

Au moment de la rédaction de cet article, Fleet se concentre sur quatre optimisations différentes : Ramdisk, l'optimisation de la construction via les paramètres, Sccache et un éditeur de liens personnalisé. Vous pouvez trouver une brève description dans ce ticket GitHub , mais il est probable que cette liste changera avec le temps, en particulier lorsque Fleet passera stableet se développera davantage.

Passons en revue les différentes optimisations une par une et voyons ce qu'elles font réellement. Ce qui suit ne sera pas une description détaillée, mais plutôt un aperçu superficiel des différentes techniques avec quelques conseils et ressources sur la façon de les utiliser. À la fin de cet article, vous trouverez également un lien vers un article fantastique décrivant comment améliorer manuellement les temps de compilation dans Rust.

Disque virtuel

Un Ramdisk, ou Ramdrive, est essentiellement un bloc de RAM utilisé comme s'il s'agissait d'un disque dur pour améliorer la vitesse et, dans certains cas, réduire la pression sur les disques durs.

L'idée de cette optimisation est de mettre le /targetdossier de votre build sur un Ramdisk pour accélérer le build. Si vous avez déjà un SSD, cela n'améliorera que légèrement les temps de construction. Mais, si vous utilisez WSL (Windows Subsystem for Linux) ou un disque dur non SSD, Ramdisk a le potentiel d'améliorer considérablement les performances.

Il existe de nombreux tutoriels sur la création de disques RAM pour les différents systèmes d'exploitation, mais comme point de départ, vous pouvez utiliser les deux articles suivants sur Mac OS et sur Linux .

Construire la configuration

Fleet manipule la configuration de construction en utilisant les options et les indicateurs du compilateur pour améliorer les performances.

Un exemple de ceci augmente codegen-units. Cela augmente essentiellement le parallélisme dans LLVM lorsqu'il s'agit de compiler votre code, mais cela se fait au détriment des performances d'exécution.

Ce n'est généralement pas un problème pour les versions de débogage, où l'expérience du développeur et des versions plus rapides sont importantes, mais certainement pour les versions de version. Vous pouvez en savoir plus sur ce drapeau dans les docs .

Le réglage codegen-unitsmanuel est assez facile, il suffit de l'ajouter au rustflagsdans votre ~/.cargo/config.toml:

[target.x86_64-unknown-linux-gnu]
rustflags = ["-C", "codegen-units=256"]

Cependant, comme mentionné ci-dessus, vous devez absolument remplacer cela 1pour les versions de version.

Une autre option consiste à réduire le niveau d'optimisation de vos versions de débogage. Bien que cela signifie que les performances d'exécution en souffriront, le compilateur a moins de travail à faire, ce qui est généralement ce que vous voulez pour itérer sur votre base de code. Cependant, il pourrait y avoir des exceptions à cela; vous pouvez en savoir plus sur les niveaux d'optimisation dans la documentation .

Pour définir le niveau d'optimisation sur le paramètre le plus bas possible, ajoutez le code ci-dessous à votre ~/.cargo/config.tomlfichier :

[target.x86_64-unknown-linux-gnu]
rustflags = ["-C", "opt-level=0"]

Encore une fois, assurez-vous de ne définir ceci que pour les versions de débogage et non pour les versions de version. Vous ne voudriez pas avoir un code entièrement non optimisé dans votre binaire de production.

Pour les niveaux d'optimisation inférieurs, comme mentionné, vous pouvez essayer d'ajouter l' share-genericsindicateur, qui permet le partage de génériques entre plusieurs caisses dans votre projet, évitant ainsi au compilateur de faire un travail en double.

Par exemple, pour Linux, vous pouvez ajouter ceci à votre ~/.cargo/config.toml:

[target.x86_64-unknown-linux-gnu]
rustflags = ["-Z", "share-generics=y"]

Scache

La prochaine optimisation utilise sccache de Mozilla . Sccache est un outil de mise en cache du compilateur, ce qui signifie qu'il tente de mettre en cache les résultats de la compilation, par exemple, à travers des projets ou des caisses, en les stockant sur un disque, soit localement, soit dans un stockage en nuage.

Ceci est particulièrement utile si vous avez plusieurs projets avec de nombreuses et parfois importantes dépendances. La mise en cache des résultats de la compilation de ces différents projets peut empêcher le compilateur de dupliquer le travail.

Surtout dans le contexte des pipelines CI/CD, où les builds sont généralement exécutés dans le contexte d'une instance ou d'un conteneur fraîchement créé sans aucun cache existant localement, sccache basé sur le cloud peut considérablement améliorer les temps de build. Chaque fois qu'une génération s'exécute, le cache est mis à jour et peut être réutilisé par les générations suivantes.

Fleet introduit de manière transparente sccache dans ses versions, mais le faire manuellement n'est pas particulièrement difficile non plus. Suivez simplement les instructions d' installation et d'utilisation de sccache.

Lien personnalisé

Enfin, Fleet configure et utilise également un éditeur de liens personnalisé pour améliorer les performances de construction. Surtout pour les grands projets avec des arborescences de dépendances profondes, le compilateur passe beaucoup de temps à lier. Dans ces cas, l'utilisation de l'éditeur de liens le plus rapide possible peut grandement améliorer les temps de compilation.

La liste ci-dessous comprend le bon éditeur de liens à utiliser pour chaque système d'exploitation :

• Linux : clang + lldcependant, Linux pourrait  bientôt utiliser des moules
• Les fenêtres:rust-lld.exe
• Mac OS :zld

Configurer un éditeur de liens personnalisé n'est pas particulièrement difficile. Essentiellement, cela revient à installer l'éditeur de liens, puis à configurer Cargo pour l'utiliser. Par exemple, l'utilisation zldsur Mac OS peut être implémentée en ajoutant la configuration suivante à votre ~/.cargo/config:

[target.x86_64-apple-darwin]
rustflags = ["-C", "link-arg=-fuse-ld=<path to zld>"]

Sous Linux, lld ou mold, est le meilleur choix pour Rust. Fleet n'est pas moldencore utilisé en raison de problèmes de licence , mais vous pouvez l'utiliser localement dans votre build en suivant simplement les étapes de Rust dans la documentation du moule .

Après ce bref aperçu, une autre ressource fantastique pour améliorer vos temps de construction si vous hésitez à utiliser Fleet à ce stade est le billet de blog de Matthias Endler sur le sujet.

Conclusion

Fleet a un grand potentiel, en particulier pour les développeurs qui n'aiment pas s'occuper des pipelines de construction ou des processus de construction en général. Il fournit un package puissant et tout-en-un d'optimisations multi-plateformes et multi-environnements pour la vitesse de construction, donc cela vaut la peine d'essayer si vous avez des difficultés avec les temps de construction.

Au-delà de cela, nous avons abordé certaines des optimisations que Fleet effectue en arrière-plan et comment celles-ci vous aideront à atténuer votre problème de vitesse de compilation si vous êtes prêt à consacrer un peu de temps pour comprendre ce qu'ils font et comment les introduire dans votre mettre en place.

Cela dit, souvent, la raison de la lenteur des temps de construction est qu'un projet dépend de très nombreuses ou de grandes caisses.

Bien gérer vos dépendances et avec un état d'esprit minimaliste, c'est-à-dire introduire uniquement la version minimale de tout ce dont vous avez besoin ou créer la fonctionnalité requise à partir de zéro au lieu d'ajouter une caisse existante, non seulement réduira vos temps de construction, mais réduira également la complexité et augmentera le maintenabilité de votre code.

Source : https://blog.logrocket.com/introducing-fleet-improving-rusts-cargo/

#rust #cargo 

Fleet：用于改进 Rust 的 Cargo 的构建工具

根据2021 Rust 调查，Rust 的长编译时间仍然是开发人员的一个大问题，也是需要进一步改进的领域。尤其是当涉及到具有许多依赖项的大型项目或 crate 时，Rust 对运行时性能而非编译时性能的关注变得相当不利，即使在调试构建中也是如此。这会对开发人员的体验产生负面影响，这也是一些开发人员仍然不愿意尝试 Rust 的原因。

无论如何，在可预见的未来，Rust 的构建时间将继续变慢，尤其是对于大型项目。虽然可以进行一些调整来改善这种情况，但设置它们并与新的开发保持同步，例如用于改进构建时间的标志和配置选项，是很麻烦的。

在本文中，我们将探索Fleet，这是一个构建工具，它本质上是一种用于改进 Rust 构建时间的单一工具解决方案，适用于本地开发和 CI/CD 管道。

开始使用舰队？

Fleet 的重点是易用性。Fleet 不一定旨在重新发明轮子并彻底改革或重组 Rust 构建工作的方式，而是将现有的构建工具包装起来，将优化调整到一个可配置的、直观的工具中，以加快构建速度。它适用于 Linux、Windows 和 Mac OS。

不幸的是，在撰写本文时，Fleet 仍处于测试阶段，仅支持 nightly rustc。但是，它正在积极开发中，将其移至stable工具链是即将进行的改进的短名单。也就是说，如果您对立即使用 Fleet 感到不舒服，或者您当前的项目设置与 Fleet 不兼容，那么有一些好消息。您可以手动进行大部分优化。在本文后面，我们将快速浏览它们，分享一些资源，您可以在其中了解更多关于它们的信息。

首先，让我们从学习如何安装 Fleet 并在项目中使用它开始。

安装和使用 Fleet

要安装 Fleet，你需要在你的机器上安装 Rust。完成后，只需打开终端并执行相应的安装脚本：

对于 Linux：

curl -L get.fleet.rs | sh

对于 Windows：

iwr -useb windows.fleet.rs | iex

完成后，您可以使用以下四个命令行参数之一设置 Fleet：

• -h / --help：打印帮助信息
• -V, / --version：打印版本信息
• build: 建立一个舰队项目
• run: 运行一个 Fleet 项目

您可以在 Fleet docsrun中查看附加的可选参数。这些有点类似于 Cargo，但它不是 1:1 的替代品，因此如果您对项目有特殊需求，请务必查看不同的配置选项。build

如果您计划在有和没有 Fleet 的情况下对构建时间进行基准测试，请务必运行干净的构建并牢记缓存和预加载。虽然 Fleet 声称在某些构建上比 Cargo 快五倍，但您的项目在编译速度方面的实际性能提升的大小将取决于许多不同的因素，包括您尝试编译的代码及其依赖项以及您的硬件、SSD 与 WSL（适用于 Linux 的 Windows 系统）。

无论如何，如果您目前觉得您的项目构建非常缓慢，请安装 Fleet 并尝试一下，看看它是否能改善这种情况。在设置方面，Fleet 完全不需要时间。

除了本地开发改进之外，Fleet 的另一个重要目标是改进 CI/CD 管道。如果您有兴趣尝试 Fleet 进行自动化构建，请务必查看他们的文档，了解如何使用 GitHub for Linux 和 Windows 进行设置。

优化

在撰写本文时，Fleet 专注于四种不同的优化：Ramdisk、通过设置优化构建、Sccache 和自定义链接器。你可以在这个GitHub ticket中找到一个简短的描述，但是这个列表很可能会随着时间的推移而改变，尤其是当 Fleet 迁移到stable并进一步开发时。

让我们一个一个地回顾不同的优化，看看它们实际上做了什么。以下不会是详尽的描述，而是对不同技术的肤浅概述，并提供一些关于如何使用它们的技巧和资源。在本文的末尾，还有一篇精彩文章的链接，该链接描述了如何在 Rust 中手动改进编译时间。

内存盘

Ramdisk 或 Ramdrive 本质上只是一块 RAM，它被用作硬盘，以提高速度并在某些情况下减轻硬盘的压力。

这种优化的想法是将/target构建的文件夹放到 Ramdisk 上以加快构建速度。如果您已经拥有 SSD，这只会略微缩短构建时间。但是，如果您使用 WSL（Linux 的 Windows 子系统）或非 SSD 硬盘，Ramdisk 有可能大幅提高性能。

有很多关于如何为不同操作系统创建 Ramdisk 的教程，但作为起点，您可以在Mac OS和Linux上使用以下两篇文章。

构建配置

Fleet 通过使用编译器选项和标志来操纵构建配置以提高性能。

这方面的一个例子是增加codegen-units。在编译代码时，这从本质上提高了 LLVM 中的并行性，但它以潜在的运行时性能为代价。

这通常不是调试版本的问题，开发人员的经验和更快的构建很重要，但对于发布版本来说绝对是。您可以在 docs 中阅读有关此标志的更多信息。

手动设置codegen-units相当简单，只需将其添加到rustflags您的~/.cargo/config.toml：

[target.x86_64-unknown-linux-gnu]
rustflags = ["-C", "codegen-units=256"]

但是，如上所述，您绝对应该将其重写1为发布版本。

另一种选择是降低调试版本的优化级别。虽然这意味着运行时性能会受到影响，但编译器要做的工作更少，这通常是您在代码库上迭代所需要的。但是，这可能有例外；您可以在文档中阅读有关优化级别的更多信息。

要将优化级别设置为尽可能低的设置，请将以下代码添加到您的~/.cargo/config.toml文件中：

[target.x86_64-unknown-linux-gnu]
rustflags = ["-C", "opt-level=0"]

同样，请确保仅为调试版本设置此选项，而不是为发布版本设置。您不希望在生产二进制文件中有完全未优化的代码。

如前所述，对于较低的优化级别，您可以尝试添加share-generics标志，它可以在项目中的多个 crate 之间共享泛型，从而可能使编译器免于重复工作。

例如，对于 Linux，您可以将其添加到您的~/.cargo/config.toml:

[target.x86_64-unknown-linux-gnu]
rustflags = ["-Z", "share-generics=y"]

高速缓存

下一个优化是使用 Mozilla 的sccache。Sccache 是一个编译器缓存工具，这意味着它尝试缓存编译结果，例如，跨项目或 crate，将它们存储在本地或云存储中的磁盘上。

如果您有几个项目具有许多甚至很大的依赖关系，这将特别有用。缓存这些不同项目的编译结果可以防止编译器重复工作。

特别是在 CI/CD 管道的上下文中，通常在没有任何本地缓存的新生成实例或容器的上下文中执行构建，云支持的 sccache 可以显着缩短构建时间。每次构建运行时，缓存都会更新，并且可以被后续构建重用。

Fleet 将 sccache 无缝地引入其构建中，但手动执行此操作也不是特别困难。只需按照sccache的安装和使用说明进行操作。

自定义链接器

最后，Fleet 还配置和使用自定义链接器来提高构建性能。尤其是对于依赖树很深的大型项目，编译器会花费大量时间链接。在这些情况下，使用尽可能快的链接器可以大大缩短编译时间。

下面的列表包括用于每个操作系统的正确链接器：

• Linux：clang + lld不过，Linux 可能 很快就会使用霉菌
• 视窗：rust-lld.exe
• 苹果系统：zld

配置自定义链接器并不是特别困难。本质上，它归结为安装链接器，然后配置 Cargo 以使用它。例如，zld在 Mac OS 上使用可以通过将以下配置添加到您的来实现~/.cargo/config：

[target.x86_64-apple-darwin]
rustflags = ["-C", "link-arg=-fuse-ld=<path to zld>"]

在 Linux 上，lld ormold是 Rust 的最佳选择。mold由于许可证问题， Fleet 尚未使用，但您可以在本地构建中使用它，只需按照模具文档中的 Rust 步骤即可。

在这个简短的概述之后，如果您此时不愿意使用 Fleet，那么另一个可以缩短构建时间的绝佳资源是 Matthias Endler关于该主题的博客文章。

结论

Fleet 具有巨大的潜力，特别是对于不喜欢在一般的构建管道或构建过程上大惊小怪的开发人员而言。它为构建速度提供了一个强大的、多平台和多环境优化的一体化包，因此如果您正在为构建时间而苦苦挣扎，那么它非常值得一试。

除此之外，我们还谈到了 Fleet 在后台执行的一些优化，以及如果您愿意花一点时间来弄清楚它们的作用以及如何将它们引入您的设置。

也就是说，很多时候，构建时间缓慢的原因是一个项目依赖于非常多或大的 crate。

以极简主义的心态很好地管理你的依赖关系，这意味着只引入你需要的任何东西的最小版本，或者从头开始构建所需的功能，而不是添加现有的 crate，不仅可以缩短构建时间，还可以降低复杂性并增加代码的可维护性。

资料来源：https ://blog.logrocket.com/introducing-fleet-improving-rusts-cargo/

#rust #cargo 

Fleet: A Build Tool for Improving Rust’s Cargo

According to the 2021 Rust Survey, Rust’s long compile time is still a big concern for developers and an area for further improvement. Especially when it comes to large projects or crates with many dependencies, Rust’s focus on runtime performance over compile time performance becomes rather punishing, even in debug builds. This negatively impacts developer experience and is a reason why some developers are still unwilling to try Rust.

In any case, Rust’s build times will continue to be on the slower side for the foreseeable future, especially for larger projects. While there are some tweaks one can make to improve this situation, setting them up and keeping up-to-date with new developments, like flags and configuration options for improved build times, is cumbersome.

In this article, we’ll explore Fleet, a build tool that is essentially a one-tool-solution for improving your Rust build times, both for local development and for CI/CD pipelines.

See more at: https://blog.logrocket.com/introducing-fleet-improving-rusts-cargo/

#rust #cargo 

¿Eres Un Programador De Cargo Cult?

¿Qué es un culto de carga?

Se remonta a la Segunda Guerra Mundial. Como parte del esfuerzo bélico, las fuerzas aliadas tuvieron que construir bases de suministro en lugares estratégicos. Algunos de estos lugares eran islas remotas que nunca se habían topado con las innovaciones tecnológicas del siglo XX. Eso significa que los aviones, los jeeps y especialmente las cajas de carga que se lanzaban en paracaídas desde los aviones parecían magia.

Naturalmente, las tribus indígenas que vivían en esas islas estaban extasiadas. ¿A quién no le gusta la magia y la comida gratis?

El problema comenzó cuando terminó la Segunda Guerra Mundial (no es una frase que escuche todos los días).

Las tropas se fueron y la comida dejó de llover del cielo. Los líderes de la tribu deben haberse reunido para descubrir cómo recuperar la magia. ¿Su solución?

Recrea el escenario que acompañó a los sucesos mágicos antes mencionados. Después de todo, hay causa y efecto en el mundo.

Lamentablemente, eso no funcionó. Aparentemente, construir aviones de bambú no hace que la comida caiga del cielo.

El concepto se resume muy bien en esta excelente cita de Feynman:

“En los Mares del Sur , hay un culto de carga de personas. Durante la guerra, vieron aterrizar aviones con muchos buenos materiales, y querían que sucediera lo mismo ahora. Así que hicieron arreglos para imitar cosas como pistas de aterrizaje, poner fuegos a lo largo de los lados de las pistas, hacer una cabaña de madera para que se sentara un hombre, con dos piezas de madera en la cabeza como auriculares y barras de bambú que sobresalían como antenas. él es el controlador, y esperan a que aterricen los aviones.

Estaban haciendo todo bien. La forma es perfecta. Se ve exactamente como se veía antes. Pero no funciona. No aterrizan aviones. Entonces, llamo a estas cosas ciencia de culto de carga, porque siguen todos los preceptos aparentes y formas de investigación científica, pero les falta algo esencial, porque los aviones no aterrizan”. —Richard Feynman

Programación de culto de carga

Entonces, hemos terminado con la lección de historia. El único problema es que la historia tiende a repetirse. Espero como el infierno que no estemos al borde de la Tercera Guerra Mundial, pero Cargo Cults se ha extendido por todas partes, incluso en los reinos de la ingeniería de software.

¿Qué es la programación de culto Cargo?

En pocas palabras, significa hacer cosas sin entender realmente por qué.
Estoy seguro de que te has topado con estos casos e incluso has participado en ellos tú mismo. Analicemos algunos ejemplos comunes.

El temido copiar y pegar

En algún momento de tu carrera, probablemente copiaste y pegaste el código de otra persona. Sé que lo hice. No voy a discutir el plagio, así que supongamos que el código está destinado a compartirse libremente.

Y, de hecho, en cierto sentido, cada vez que usa una biblioteca, "copia y pega" su código y lo usa como parte de su base de código. Eso aún podría generar problemas , pero eso se considera legítimo. Las bibliotecas están destinadas a ser utilizadas por otras personas. Los ingenieros que lo diseñaron trabajaron arduamente para hacerlo accesible y lo más libre de errores posible.

Los problemas surgen cuando copia y pega desde alguna respuesta de desbordamiento de pila, o desde otras partes en su base de código, sin tener la menor idea de lo que realmente está haciendo ese código. Funcionó para esa persona, así que ¿por qué no iba a funcionar para ti?

Bueno, eso es pensamiento Cargo-Cult. Estás lidiando con el escenario (el código parece similar) sin comprender realmente la causa raíz (cómo se usa en ese contexto particular).

Digamos que logras terminar la tarea. El código funciona, obtuviste el premio (carga), pero luego las circunstancias cambian. Aparece una nueva solicitud, por lo que debe modificar ese código que realmente no entendió. Y entonces te das cuenta: el avión está hecho de bambú. Su código no es el verdadero negocio.

Abusar de la herencia en programación orientada a objetos

La primera vez que aprendes sobre la herencia, parece mágico.

Con menos de una línea de código, puede obtener casi todas las propiedades y funciones de la clase principal. Y no me hagan empezar con el polimorfismo, eso es mágico. Lo único que no te enseñan en la escuela es que la herencia introduce un acoplamiento muy estrecho.

Cada vez que heredas de una clase, creas una dependencia muy fuerte en su implementación concreta. Peor aún, cada usuario de su clase tiene una dependencia transitiva de la clase base. Eso significa que si alguien cambia la clase base, que incluso podría pertenecer a una biblioteca sobre la que no tiene control, su código puede romperse. Y eso significa que todas las clases que dependen de su clase también pueden romperse, eso no es fácil, especialmente si sucede al final de su semana laboral.

Por lo tanto, es necesario pensar detenidamente antes de introducir la herencia. Debe considerar tanto los pros como los contras de la herencia, y averiguar si su caso de uso específico realmente lo justifica. La mayoría de las veces, debería favorecer la composición . En este contexto, recomiendo leer esta discusión muy interesante, comenzando con una respuesta del propio tío Bob .

Seguir ciegamente las “mejores prácticas”

El último ejemplo que voy a dar es un poco más específico. Está relacionado con el código de copiar y pegar, pero es mucho más elusivo. Se trata de usar código/anotaciones que no entiende completamente, porque es la "mejor práctica".

Un buen ejemplo es el uso desordenado de la anotación transaccional en aplicaciones que usan Spring.

Parece que mágicamente resuelve algunos errores, por lo que la gente piensa (y algunos probablemente incluso afirman abiertamente) que es una buena práctica usarlo todo el tiempo.

Lo complicado de esto es que el 90% de las veces tendrán razón.
Los errores se resuelven y la carga sigue cayendo en paracaídas desde el aire.

Todo el mundo está contento hasta que algo cambia y surge un error de producción con toda su majestuosidad. Mira el siguiente ejemplo furtivo:

@Transactional
public void changeName(long id, String name) {
  User user = userRepository.getById(id);
  user.setName(name);
  if (StringUtils.isNotEmpty(name)) {
    userRepository.save(user);
  }
}// All rights reserved to this fantastic article

Un ingeniero con buen ojo puede ver que hay algo sospechoso aquí. ¿Por qué establecer el nombre antes de validar?

Sin embargo, un revisor de código apresurado puede pasar por alto esto, y si no está familiarizado con la anotación transaccional, podría pensar que no se hizo daño.

Y luego comienza a ver registros sobre registros de usuarios con nombres vacíos. Mierda, algo debe estar mal, ¿es esto un ataque cibernético?

No, es solo nuestra querida anotación transaccional haciendo su trabajo.

Verá, hay otro efecto secundario pasado por alto de esta anotación: cada entidad declarada en su alcance está en un estado administrado. Por lo tanto, cada cambio que realice en este ámbito se conserva automáticamente en la base de datos, incluso sin llamar explícitamente a "guardar".

En este caso, significa que está guardando los registros independientemente de si la validación tuvo éxito o no.

Cómo evitar la programación de Cargo Cult

• Mira debajo del capó. Lleva tiempo y, a veces, puede parecer inútil, pero en el futuro, lo ayudará a ahorrar muchas semanas de lucha contra errores que desafían la razón.
• Cuestionar las "mejores prácticas". La mayoría de ellos probablemente estén justificados. Pero al cuestionarlos, tienes la oportunidad de saber por qué surgieron en primer lugar, lo que te convierte en un ingeniero mucho mejor.
• Trabaja en entender las cosas profundamente. Esto puede parecer trivial, pero a menudo nos conformamos con un conocimiento superficial. Confundimos saber algo con saber el nombre de algo.

Algo de esto puede parecer un conocimiento común trivial. Pero recuerde, el conocimiento común no siempre es una práctica común.

Sea consciente de su trabajo y pase más tiempo aprendiendo las complejidades de su oficio. Estaras contento de haberlo hecho.

Esta historia se publicó originalmente en https://betterprogramming.pub/are-you-a-cargo-cult-programmer-be361217c030

#cargo #programmers 

あなたはカーゴカルトプログラマーですか？

カーゴカルトとは

それは第二次世界大戦に戻ります。戦争努力の一環として、連合軍は戦略的な場所に補給基地を建設しなければなりませんでした。これらの場所のいくつかは、20世紀の技術革新に出くわしたことのない離島でした。つまり、飛行機、ジープ、そして特に飛行機からパラシュートで降下する貨物ボックスはすべて魔法のように見えました。

当然、これらの島々に住む先住民族は恍惚状態でした。魔法と無料の食べ物が嫌いな人はいますか？

問題は第二次世界大戦が終わったときに始まりました（あなたが毎日聞くフレーズではありません）。

軍隊は去り、食べ物は空から雨が降らなくなった。部族のリーダーは、魔法を取り戻す方法を理解するために集まったに違いありません。彼らの解決策は？

前述の不思議な出来事に伴う風景を再現します。結局のところ、世界には原因と結果があります。

悲しいことに、それはうまくいきませんでした。どうやら、竹の飛行機を作ることは空から食べ物を雨に降らせません。

この概念は、この素晴らしいファインマンの引用にうまくまとめられています。

「南洋には、人々のカーゴカルトがあります。戦争中、彼らは飛行機がたくさんの良い材料で着陸するのを見ました、そして彼らは今同じことが起こることを望みました。そこで彼らは、滑走路のようなものを模倣したり、滑走路の側面に火をつけたり、男性が座れる木造の小屋を作ったり、ヘッドホンのように頭に2つの木片を置き、アンテナのように竹の棒を突き出したりするように手配しました。彼はコントローラーです—そして彼らは飛行機が着陸するのを待ちます。

彼らはすべてを正しくやっていた。形は完璧です。以前とまったく同じように見えます。しかし、それは機能しません。飛行機は着陸しません。ですから、私はこれらをカーゴカルトサイエンスと呼んでいます。なぜなら、それらはすべての明白な教訓と科学的調査の形式に従っているからですが、飛行機が着陸しないため、本質的な何かが欠けています。」—リチャード・ファインマン

カーゴカルトプログラミング

これで、歴史のレッスンは終わりです。唯一の問題は—歴史は繰り返される傾向があるということです。私たちが第三次世界大戦の危機に瀕していないことを願っていますが、カーゴカルトはソフトウェアエンジニアリングの分野にまで広がっています。

カーゴカルトプログラミングとは何ですか？

一言で言えば、それは本当に理由を理解せずに物事を行うことを意味します。
あなたはそのような事件に出くわし、自分でそれらに参加したことさえあると確信しています。いくつかの一般的な例について説明しましょう。

恐ろしいコピーペースト

あなたのキャリアのある部分では、おそらく他の誰かのコードをコピーして貼り付けました。私はやったことを知っています。盗用については説明しませんので、コードが自由に共有されることを意図していると仮定しましょう。

実際、ある意味では、ライブラリを使用するたびに、そのコードを「コピーアンドペースト」して、コードベースの一部として使用します。それでも問題が発生する可能性がありますが、それは正当なことと見なされます。ライブラリは、他の人が使用することを目的としています。それを設計したエンジニアは、アクセス可能で可能な限りバグのないものにするために一生懸命働きました。

Stack Overflowの回答から、またはコードベースの他の部分からコピーアンドペーストすると、そのコードが実際に何をしているのかを少しも理解せずに問題が発生します。それはその人のために働いたのに、なぜそれはあなたのために働かないのですか？

まあ、それはカーゴカルトの考え方です。根本的な原因（特定のコンテキストでどのように使用されているか）を実際に理解せずに、風景（コードは似ているように見えます）を扱っています。

タスクをなんとか完了したとしましょう。コードは機能し、賞品（貨物）を獲得しましたが、状況は変化します。新しいリクエストが出てきたので、あなたは本当に理解していなかったそのコードを修正する必要があります。そして、それはあなたを襲います—飛行機は竹でできています。あなたのコードは本物ではありません。

OOPでの継承の乱用

初めて継承について学ぶとき、それは魔法のようです。

1行未満のコードで、親クラスのほとんどすべてのプロパティと関数を取得できます。そして、私にポリモーフィズムを始めさせないでください。それは魔法です。彼らが学校であなたに教えていない唯一のことは、継承が非常に緊密な結合をもたらすということです。

クラスから継承するたびに、その具体的な実装に非常に強い依存関係を作成します。さらに悪いことに、クラスのすべてのユーザーは、基本クラスに推移的に依存しています。つまり、誰かが基本クラスを変更した場合、それはあなたが制御できないライブラリに属している可能性もあり、コードが破損する可能性があります。そして、それはあなたのクラスに依存するすべてのクラスが同様に壊れるかもしれないことを意味します、それはピクニックではありません、特にそれがあなたの仕事の週の終わりに起こるならば。

したがって、継承を導入する前に慎重に考える必要があります。継承の長所と短所の両方を考慮し、特定のユースケースが実際にそれを正当化するかどうかを判断する必要があります。多くの場合、実際には構成を優先する必要があります。この文脈では、ボブおじさん自身からの回答から始めて、この非常に興味深い議論を読むことをお勧めします。

「ベストプラクティス」を盲目的にフォローする

最後に紹介する例は、もう少し具体的です。これはコードのコピー貼り付けに関連していますが、はるかにわかりにくいです。これは、「ベストプラクティス」であるため、完全には理解していないコード/注釈を使用することです。

良い例は、Springを使用するアプリケーションでのTransactionalアノテーションの無計画な使用法です。

それは魔法のようにいくつかのバグを解決するように見えるので、人々はそれを常に使用することがベストプラクティスであると考えています（そしておそらく完全に主張する人さえいます）。

それについてのトリッキーなことは、90％の時間、彼らは正しいだろうということです。
バグは解決され、貨物は空中からパラシュートを続けます。

何かが変わり、生産のバグがその威厳のすべてに現れるまで、誰もが幸せです。次の卑劣な例を見てください。

@Transactional
public void changeName(long id, String name) {
  User user = userRepository.getById(id);
  user.setName(name);
  if (StringUtils.isNotEmpty(name)) {
    userRepository.save(user);
  }
}// All rights reserved to this fantastic article

鋭い目を持つエンジニアは、ここの何かが怪しいことを見ることができます。検証する前に名前を設定するのはなぜですか？

ただし、急いでいるコードレビューアはこれを見逃す可能性があり、Transactionalアノテーションに精通していない場合は、害がなかったと考える可能性があります。

そして、名前が空のユーザーのレコードにレコードが表示されるようになります。クラップ、何かが間違っているに違いない、これはサイバー攻撃ですか？

いいえ、それは私たちの最愛のTransactionalアノテーションがその仕事をしているだけです。

ご覧のとおり、このアノテーションには見落とされがちな別の副作用があります。スコープ内で宣言されたすべてのエンティティは管理された状態です。したがって、このスコープで行うすべての変更は、明示的に「保存」を呼び出さなくても、データベースに自動的に保持されます。

この場合、検証が成功したかどうかに関係なく、レコードを保存していることを意味します。

カーゴカルトプログラミングを回避する方法

• ボンネットの下を見てください。時間はかかり、無意味に感じることもありますが、将来的には、理由に反するバグと戦う何週間も節約するのに役立ちます。
• 「ベストプラクティス」について質問します。それらのほとんどはおそらく正当化されます。しかし、彼らに質問することで、そもそもなぜ彼らが生まれたのかを知る機会が得られ、それはあなたをはるかに優れたエンジニアにします。
• 物事を深く理解するように努めます。これは些細なことのように聞こえるかもしれませんが、私たちはしばしば浅い知識に落ち着きます。私たちは何かを知ることと何かの名前を知ることを混同します。

これのいくつかは、些細な常識のように見えるかもしれません。ただし、一般的な知識は必ずしも一般的な慣習ではないことを忘れないでください。

あなたの仕事に気をつけて、あなたの技術の複雑さを学ぶことにもっと時間を費やしてください。あなたはあなたがしたことをうれしく思うでしょう。

このストーリーは、もともとhttps://betterprogramming.pub/are-you-a-cargo-cult-programmer-be361217c030で公開されました

#cargo #programmers 

Desmitificando La Carga En Rust

Rust es un lenguaje increíble para trabajar. Sin embargo, viene con una herramienta a menudo incomprendida conocida como Cargo .

Muchas personas, cuando comienzan a usar Rust, tienen problemas para comprender qué hace Cargo y cómo funciona. Quizás se pregunte, por ejemplo, por qué necesita ejecutar su código Rust con cargo run. ¿Por qué necesita Cargo para ejecutar su programa Rust? ¿Por qué hay tantas cargoactividades en un programa de Rust?

En este tutorial, nuestro objetivo es aclarar el misterio que rodea a Rust Cargo.

¿Qué es Cargo en Rust?

Cargo es el sistema de compilación y administrador de paquetes de Rust. Con esta herramienta, obtendrá una compilación repetible porque permite que los paquetes de Rust declaren sus dependencias en el manifiesto, Cargo.toml. Cuando instala Rust a través rustupde , Cargo también se instala.

Por ejemplo, cuando ejecuta el siguiente comando en Linux o macOS para instalar Rust, Cargo también se instala:

rizo https://sh.rustup.rs -sSf | sh

Cargo te ayuda a compilar tu programa Rust con éxito. Descarga dependencias, compila sus paquetes y los carga en el registro del proyecto Rust, crates.io .

Cómo funciona Cargo

Cargo permite que los paquetes de Rust declaren sus dependencias. Esto se hace en el Cargo.tomlarchivo. Todo lo que tiene que hacer es declarar las dependencias requeridas para ejecutar su programa en el Cargo.toml archivo. A continuación, Cargo extrae toda la información necesaria sobre sus dependencias y crea información en el Cargo.lockarchivo.

La función del Cargo.lockarchivo es permitir una compilación repetible. Por lo tanto, no debería haber casos de compilaciones diferentes, incluso cuando comparte su proyecto.

Quizás se pregunte en qué se diferencian los archivos Cargo.tomly . es un manifiesto , que es un documento que contiene información detallada sobre pasajeros, mercancías, etc. En Rust, el manifiesto contiene información detallada sobre un proyecto determinado, como el nombre del proyecto, la versión, las dependencias, etc. El manifiesto le dice a Cargo qué dependencia necesita descargar para compilar su proyecto con éxito.Cargo.lockCargo.toml

¿Qué es Cargo.lock?

Cuando construye su proyecto y lo comparte con otros, ¿cómo se asegura Rust de que usted y sus amigos no tengan una compilación diferente con diferentes versiones de dependencias? Aquí es donde Cargo.lockentra.

Cargo.locksimplemente contiene información de compilación de su proyecto. Cuando su proyecto se compila correctamente, toda la información de compilación se almacena en su Cargo.lockarchivo. Esto incluye la versión exacta de las dependencias para su compilación. Quizás se pregunte por qué esto es importante cuando ya ha especificado la versión de sus dependencias en Cargo.toml.

¿Qué sucede cuando la versión de sus dependencias se actualiza y hace que su programa funcione de forma inesperada? Dado que tiene la versión exacta de las dependencias en Cargo.toml, todo lo que Cargo hará es descargarlas mientras intenta compilar su programa, incluso si se actualiza. Sin embargo, si tiene un Cargo.lockarchivo, Cargo utilizará la copia exacta de la dependencia en el Cargo.lockarchivo. No tendrá que arriesgarse a que una de las dependencias de SemVer rompa su programa incluso después de una compilación inicial exitosa con Cargo.lock.

Cargo.lockcontraCargo.toml

Lo primero que debe tener en cuenta sobre Cargo.locky Cargo.tomles que ambos contienen dependencias para su proyecto. Sin embargo, Cargo.tomlestá escrito por el desarrollador mientras Cargo.lockque Cargo lo mantiene.

La razón para usar un Cargo.lockarchivo además de un Cargo.tomlarchivo es permitir compilaciones repetibles en todas las máquinas. Si bien Cargo.tomlel archivo almacena las versiones de SemVer, Cargo.lockalmacena la versión exacta de la dependencia durante una compilación exitosa.

Para entender esto mejor, imaginemos que no hay ningún Cargo.lockarchivo y las restricciones de SemVer para nuestras dependencias son:

[dependencies]
serde = "1.0"
serde json = "1.0"

Cuando compila su proyecto, la serdeversión exacta que se compila correctamente es serde = "1.0.124". Si serdeestá actualizado y comparte su proyecto con un colega, es posible que se produzcan algunos errores porque la serdeactualización puede no ser compatible con su proyecto. Cargo.lockresuelve problemas de dependencia al permitir que Cargo compare la información en el Cargo.lockarchivo.

Carga y perfiles

Con perfiles en Rust , es fácil cambiar algunas configuraciones del compilador. Por ejemplo, puede cambiar el nivel de optimización con solo especificarlo en el Cargo.tomlarchivo:

    [profile.dev
    opt-level = 1 # Use basic optimizations. 

Esto le dice a Cargo que use un nivel de optimización 1mientras compila su proyecto.

Rust tiene cuatro perfiles incorporados : dev, testy . El comando que se ejecuta depende del perfil a elegir. Puede cambiar la configuración del compilador en la tabla de su archivo.benchrelease[profile]Cargo.toml

Veamos los perfiles predeterminados, así como los comandos y los indicadores de línea de comandos asociados con cada uno.

DEV

Cuando ejecuta el comando cargo build, el compilador usa el devperfil. Este perfil se utiliza para el desarrollo y la depuración normales.

       [profile.dev]
        opt-level = 0
        debug = true
        debug-assertions = true
        overflow-checks = true
        lto = false
        panic = 'unwind'
        incremental = true
        codegen-units = 256
        rpath = false

RELEASE

El RELEASEperfil se utiliza para lanzamientos y en producción. Cuando utilice el cargo installcomando o -- release flag, se utilizará este perfil.

        [profile.release]
        opt-level = 3
        debug = false
        debug-assertions = false
        overflow-checks = false
        lto = false
        panic = 'unwind'
        incremental = false
        codegen-units = 16
        rpath = false

TEST

El TESTperfil se usa cuando ejecuta el cargo buildcomando para puntos de referencia en modo de depuración o cuando crea pruebas.

    [profile.test]  
    opt-level = 0
    debug = 2
    debug-assertions = true
    overflow-checks = true
    lto = false
    panic = 'unwind' 
    incremental = true
    codegen-units = 256
    rpath = false            

BENCH

BENCHentra en juego cuando crea puntos de referencia o crea pruebas con --release flag.

    [profile.bench]            
    opt-level = 3
    debug = false
    debug-assertions = false
    overflow-checks = false
    lto = false
    panic = 'unwind'    
    incremental = false
    codegen-units = 16
    rpath = false                       

Carga y espacios de trabajo

En Rust, puede crear una colección de paquetes que comparten un Cargo.lockarchivo, un directorio de salida y otras configuraciones, como perfiles. Esta colección se llama a workspacey los paquetes que componen el espacio de trabajo son workspace members.

Los espacios de trabajo se especifican en el Cargo.tomlarchivo. Esto generalmente se hace de dos maneras: usando el root packageo virtual manifest.

El root packagemétodo implica agregar una [workspace]tabla a su Cargo.tomlarchivo. La [workspace]tabla se puede agregar a un Cargo.tomlarchivo donde [package]ya se ha declarado si [package]es el paquete raíz del espacio de trabajo.

Por el virtual manifestmétodo, puede crear un Cargo.tomlarchivo y agregar una [workspace]tabla. Sin embargo, ninguna [package]tabla estará en el Cargo.tomlarchivo. Esta puede ser una buena opción cuando desea mantener todos los paquetes juntos en un directorio diferente o cuando no hay un paquete "primario".

Comandos de carga

A continuación se muestran los comandos de carga más populares. Para su comodidad, los hemos agrupado en las siguientes categorías: comandos de compilación, comandos de manifiesto, comandos de paquete y comandos de publicación:

    # Build commands          
    cargo bench \[options\] [benchname] 
    cargo build [options]
    cargo check [options]
    cargo clean [options]
    cargo doc [options]
    cargo fetch [options]
    cargo fix [options]
    cargo run \[options\] [-- args]
    cargo rustc \[options\] [-- args]
    cargo rustdoc \[options\] [-- args]
    cargo test \[options\] [testname]

    # Analysis commands
    cargo clippy

    # Manifest commands
    cargo generate-lockfile [options]
    cargo locate-project [options]
    cargo metadata [options]
    cargo pkgid \[options\] [spec]
    cargo tree [options]
    cargo update [options]
    cargo vendor \[options\] [path]
    cargo verify-project [options]

    # Package commands
    cargo init \[options\] [path]
    cargo install [options]
    cargo new [options] path
    cargo search \[options\] [query...]
    cargo uninstall \[options\] [spec...]

    # Publishing commands
    cargo login \[options\] [token]
    cargo owner [options]
    cargo package [options]
    cargo publish [options]
    cargo yank [options] --vers version [crate]                  

Para obtener más información sobre los comandos de Cargo, consulte la documentación oficial de Rust .

Conclusión

La creación de una aplicación Rust es imposible sin Cargo. Además, necesita comandos de Cargo para publicar su proyecto. En pocas palabras, Cargo organiza una compilación, una compilación y un tiempo de ejecución fluidos para su proyecto de Rust.

Espero que esta guía le haya dado una mejor comprensión de qué es Cargo, cómo funciona y por qué es una parte tan crucial de cualquier proyecto de Rust. Si desea obtener más información sobre Cargo, la documentación de Rust es un gran recurso.

Fuente: https://blog.logrocket.com/demystifying-cargo-in-rust/

#rust #cargo 

Rustで貨物をわかりやすく説明する

Rustは素晴らしい言語です。ただし、 Cargoと呼ばれる誤解されがちなツールが付属しています。

多くの人は、最初にRustを使い始めたとき、Cargoが何をし、どのように機能するかを理解するのに苦労しています。たとえば、なぜRustコードをで実行する必要があるのか​​疑問に思われるかもしれませんcargo run。Rustプログラムを実行するためにCargoが必要なのはなぜですか？cargoRustプログラムにこれほど多くの活動があるのはなぜですか？

このチュートリアルでは、RustCargoを取り巻く謎を解き明かすことを目指しています。

Rustの貨物とは何ですか？

CargoはRustのビルドシステムおよびパッケージマネージャーです。このツールを使用すると、Rustパッケージがマニフェストで依存関係を宣言できるため、繰り返し可能なビルドが得られますCargo.toml。Rust throughをインストールするrustupと、Cargoもインストールされます。

たとえば、LinuxまたはmacOSで次のコマンドを実行してRustをインストールすると、Cargoもインストールされます。

curl https://sh.rustup.rs -sSf | sh

Cargoは、Rustプログラムを正常にコンパイルするのに役立ちます。依存関係をダウンロードし、パッケージをコンパイルして、Rustプロジェクトレジストリcrates.ioにアップロードします。

貨物のしくみ

Cargoを使用すると、Rustパッケージで依存関係を宣言できます。これはCargo.tomlファイルで行われます。あなたがしなければならないのは、Cargo.toml ファイルでプログラムを実行するために必要な依存関係を宣言することです。次に、Cargoは依存関係に関する必要な情報をすべて抽出し、情報をCargo.lockファイルに組み込みます。

ファイルの機能はCargo.lock、繰り返し可能なビルドを可能にすることです。したがって、プロジェクトを共有する場合でも、ビルドが異なる場合はありません。

Cargo.tomlとCargo.lockファイルがどのように違うのか疑問に思われるかもしれません。Cargo.tomlはマニフェストです。これは、乗客や商品などに関する詳細情報を含むドキュメントです。Rustでは、マニフェストには、プロジェクト名、バージョン、依存関係など、特定のプロジェクトに関する詳細情報が含まれます。マニフェストは、Cargoにどの依存関係かを通知します。プロジェクトを正常にコンパイルするには、ダウンロードする必要があります。

何Cargo.lockですか？

プロジェクトをビルドして他の人と共有するとき、Rustはどのようにして、あなたとあなたの友人が異なるバージョンの依存関係で異なるビルドを持っていないことを確認しますか？これがCargo.lock出番です。

Cargo.lockプロジェクトのビルド情報が含まれているだけです。プロジェクトが正常にビルドされると、すべてのビルド情報がCargo.lockファイルに保存されます。これには、ビルドの依存関係の正確なバージョンが含まれます。で依存関係のバージョンをすでに指定しているのに、なぜこれが重要なのか不思議に思うかもしれませんCargo.toml。

依存関係のバージョンが更新され、プログラムが予期せず機能するようになるとどうなりますか？に依存関係の正確なバージョンがあるのでCargo.toml、Cargoが行うのは、プログラムが更新されたとしても、プログラムのコンパイルを試みている間にそれらをダウンロードすることだけです。ただし、ファイルがある場合Cargo.lock、CargoはCargo.lockファイル内の依存関係の正確なコピーを使用します。を使用して最初にビルドが成功した後でも、 SemVer依存関係の1つがプログラムを壊すリスクを冒す必要はありませんCargo.lock。

Cargo.lock対。Cargo.toml

最初に注意することはCargo.lock、Cargo.toml両方にプロジェクトの依存関係が含まれていることです。ただし、Cargoによって保守されCargo.tomlている間、開発者によって作成されます。Cargo.lock

Cargo.lockファイルに加えてファイルを使用する理由は、Cargo.tomlすべてのマシンで繰り返し可能なビルドを有効にするためです。Cargo.tomlファイルにはSemVerバージョンが保存されますが、Cargo.lockビルドが成功すると、依存関係の正確なバージョンが保存されます。

これをよりよく理解するために、Cargo.lockファイルがなく、依存関係に対するSemVerの制限が次のようになっていると想像してみましょう。

[dependencies]
serde = "1.0"
serde json = "1.0"

プロジェクトをビルドするとき、serde正常にビルドされる正確なバージョンはですserde = "1.0.124"。が更新され、プロジェクトを同僚と共有する場合、更新がプロジェクトと互換性がない可能性があるserdeため、同僚がエラーに遭遇する可能性があります。Cargoがファイル内の情報を比較できるようにすることで、依存関係の問題を解決します。serdeCargo.lockCargo.lock

貨物とプロファイル

Rustのプロファイルを使用すると、一部のコンパイラ設定を簡単に変更できます。たとえば、Cargo.tomlファイルで指定するだけで最適化レベルを変更できます。

    [profile.dev
    opt-level = 1 # Use basic optimizations. 

1これは、プロジェクトのコンパイル中にの最適化レベルを使用するようにCargoに指示します。

Rustには、、、およびの4つの組み込みプロファイルがdevありtestます。実行されるコマンドは、選択するプロファイルによって異なります。ファイルのテーブルでコンパイラ設定を変更できます。benchrelease[profile]Cargo.toml

デフォルトのプロファイルと、それぞれに関連付けられているコマンドおよびコマンドラインフラグを見てみましょう。

DEV

コマンドを実行するcargo buildと、コンパイラーはdevプロファイルを使用します。このプロファイルは、通常の開発とデバッグに使用されます。

       [profile.dev]
        opt-level = 0
        debug = true
        debug-assertions = true
        overflow-checks = true
        lto = false
        panic = 'unwind'
        incremental = true
        codegen-units = 256
        rpath = false

RELEASE

プロファイルは、RELEASEリリースおよび本番環境で使用されます。cargo installコマンドまたはを使用する-- release flagと、このプロファイルが使用されます。

        [profile.release]
        opt-level = 3
        debug = false
        debug-assertions = false
        overflow-checks = false
        lto = false
        panic = 'unwind'
        incremental = false
        codegen-units = 16
        rpath = false

TEST

プロファイルは、デバッグモードでベンチマークTESTのコマンドを実行するとき、またはテストをビルドするときに使用されます。cargo build

    [profile.test]  
    opt-level = 0
    debug = 2
    debug-assertions = true
    overflow-checks = true
    lto = false
    panic = 'unwind' 
    incremental = true
    codegen-units = 256
    rpath = false            

BENCH

BENCHでベンチマークを作成したり、テストを作成したりすると、効果があり--release flagます。

    [profile.bench]            
    opt-level = 3
    debug = false
    debug-assertions = false
    overflow-checks = false
    lto = false
    panic = 'unwind'    
    incremental = false
    codegen-units = 16
    rpath = false                       

貨物とワークスペース

Rustでは、Cargo.lockファイル、出力ディレクトリ、およびプロファイルなどの他の設定を共有するパッケージのコレクションを作成できます。このコレクションはaworkspaceと呼ばれ、ワークスペースを構成するパッケージはworkspace membersです。

ワークスペースはファイルで指定されCargo.tomlます。root packageこれは通常、またはのいずれかを使用する2つの方法で行われますvirtual manifest。

このroot package方法では、ファイルに[workspace]テーブルを追加しCargo.tomlます。がワークスペースのルートパッケージである場合、[workspace]テーブルはすでに宣言されているCargo.tomlファイルに追加できます。[package][package]

このvirtual manifest方法では、Cargo.tomlファイルを作成して[workspace]テーブルを追加できます。ただし、ファイル[package]にはテーブルはありませんCargo.toml。これは、すべてのパッケージを別のディレクトリにまとめたい場合、または「プライマリ」パッケージがない場合に適したオプションです。

貨物コマンド

以下は最も人気のあるCargoコマンドです。便宜上、これらを次のカテゴリにグループ化しました：ビルドコマンド、マニフェストコマンド、パッケージコマンド、および公開コマンド：

    # Build commands          
    cargo bench \[options\] [benchname] 
    cargo build [options]
    cargo check [options]
    cargo clean [options]
    cargo doc [options]
    cargo fetch [options]
    cargo fix [options]
    cargo run \[options\] [-- args]
    cargo rustc \[options\] [-- args]
    cargo rustdoc \[options\] [-- args]
    cargo test \[options\] [testname]

    # Analysis commands
    cargo clippy

    # Manifest commands
    cargo generate-lockfile [options]
    cargo locate-project [options]
    cargo metadata [options]
    cargo pkgid \[options\] [spec]
    cargo tree [options]
    cargo update [options]
    cargo vendor \[options\] [path]
    cargo verify-project [options]

    # Package commands
    cargo init \[options\] [path]
    cargo install [options]
    cargo new [options] path
    cargo search \[options\] [query...]
    cargo uninstall \[options\] [spec...]

    # Publishing commands
    cargo login \[options\] [token]
    cargo owner [options]
    cargo package [options]
    cargo publish [options]
    cargo yank [options] --vers version [crate]                  

Cargoコマンドの詳細については、Rustの公式ドキュメントをご覧ください。

結論

Rustアプリケーションの構築はCargoなしでは不可能です。さらに、プロジェクトを公開するにはCargoコマンドが必要です。簡単に言えば、Cargoは、Rustプロジェクトのスムーズなビルド、コンパイル、およびランタイムを調整します。

このガイドが、Cargoとは何か、Cargoがどのように機能するか、そしてなぜそれがRustプロジェクトの非常に重要な部分であるかについての理解を深めてくれることを願っています。Cargoについて詳しく知りたい場合は、Rustのドキュメントが優れたリソースです。

出典：https ：//blog.logrocket.com/demystifying-cargo-in-rust/

 #rust #cargo 

Introduction to Rust | Rust Tutorials - 01

Check out the entire playlist here: https://www.youtube.com/playlist?list=PLkO5ggdQuRaaeFke7nWS4ajhFVZ1biE7_

In this video, we will be going over Rust, its package manager Cargo and a simple hello world program.

#rust #cargo

Rust Crash Course - Mutability

Mutability of Variables in Rust

#Rust #mutability #rustlang #cargo

#rust #mutability #rustlang #cargo

My top 7 Rust commands for using Cargo

I’ve been using Rust for a little over six months now. I’m far from an expert, but I have stumbled across many, many gotchas and learned many, many things along the way; things that I hope will be of use to those who are learning what is easily my favourite programming language.

This is the third article in my miniseries for Rust newbs like me. You can find my other excursions into Rust in:

#rust #cargo