This presentation is about making small hosted executable using 
Rust programming langage.

This presentation, source codes and this speech are published on my server.

# Part 1: bloated programs
## Typical bloated program

When you look at a modern compiled program, you typically see a 1MB+ executable.

Of those megabytes, the code author of the program actually typed by hands
typically consist of minority of the bytes.

The rest is either some static constant size that gets embedded into every program,
dependency code (where sometimes big chunks of dependencies are included even when, not really needed)
and debugging support (or maybe handlers of some corner case scenarios, like,
for example, the code to handle error that happens when we start the 
program with `--help`, but it cannot write the help bytes to stdout)


## Tradeoffs

Here are typical tradeoffs that affect file size.
The first and the main one is compilation speed - it takes longer
for the compiler to make better code.

Often the same optimisations that make code faster also make code smaller.
Just dead code removal and inlining trivial or sole uses can go long way.

Another tradeoffs is debuggability (and some UX aspects).

## Reasons why big

Here are main reasons according to me why Rust programs are big.

## Reasons why big: No dynamic linking

Operating system can afford to have big libraries with debugging symbols,
special support for edge cases and so on.

This removes one of the tradeoffs.

## Reasons why big: Monomorphisation

The same function can be compiled multiple times with
different compile-time parameters.

This can improve speed at the expense of bloat.

`cargo bloat` - the main tool of minsize fighter - can help finding out
such cases and `dyn` can help acting on them.

## Reasons why big: Debugging features

Debug symbols that `strip` remove is not the only debugging thing that
takes up size in the executable.

There are various panic messages, error messages, source files and line numbers
and other things; also the code for unwinding and displaying backtraces.

## Reasons why big: stdlib algorithms

Standard library contains some amount of algorithms that can be implemented
in various ways, with speed vs compactness tradeoff.

## Reasons for pursuing minsized

Small executable size is not the only reason to take up the challenge.

The process of shrining is gamified dependency review. It helps you
to get to the core ...


# Part 2A: Shrinking challenge

## Sample project"

## Basic version source code

## Basic version's metrics

## Other languages (for a comparison)

## "Free beer" optimisations

Not researched: how PGO affects size

## "Free beer" reduction

## Deeper compilation mode changes

## Other notable unstable settings

## Lean build results

## Offending crates


## Easy measure: limit `clap`'s features



## Replacing "clap" with "argh"


## argh results


## Limiting Tokio's features



## Removing `anyhow`


## What remains?




## Part 2B: Shrinking challenge


## Unportable trick: no_main


## no_main results

## Honourable mention: eyra



## Worse UX: only basic output



## Investigating why fmt



## Victory over fmt?


## Extinguishing the last remnant of fmt



## Manual implementation: no tokio


# Outro

## Helpful link

## Shrinking methods review

## What typical Rust executable contains


# The end
.