Alan D. Salewski salewski

This document is the result of conversations that came out of this tweet: https://twitter.com/withoutboats/status/814201265575981056

Rust's module system is too confusing

Empirically, very many new users of Rust are confused by Rust's module system. This is unfortunate: Rust's module system is not particularly innovative or powerful; it is intended only to provide fairly standard privacy and namespacing support. Too much of new users' attention is being pulled by this system as it exists today.

This document presents an hypothesis of the cause of the confusion, and an attempt to mitigate that confusion by instituting a practice that is more similar to mainstream languages. We believe this problem is caused by the confluence of a several well-motivated design decisions that have created a very unusual system, and the solution is to require less declarations by leveraging ambient information in a manner more similar to how other languages' module systems work.

Rust requires users to build an explicit

Compressing the Unicode names lists

Perhaps the most prominent, if not the most important, property of any Unicode character is its name. These immutable labels are much more descriptive than their hexadecimal codes.

But these names aren’t used often in most programming languages. Why is that? Perhaps the biggest reason why is the [sheer size of the list of names][UnicodeData.txt], weighing 1.769 MB; embedding such a file in every language runtime would impose a large burden on resource-constrained environments such as mobile devices. But can this burden be mitigated with data compression? How compressible is this list? Can we create a [succinct data structure][succinct] from this list?

Precedent for this project comes from GNU Uniname, a GNU Project utility, written by Bill Poser of British Columbia, which can look up the characters of names and the names of characters. Its source may be read in [uniname.c][] and [test-uninames.c][]. According to its documentation, the size of the compiled program

	use std::thread;
	use std::sync::mpsc::{Receiver, channel};
	use std::time::Duration;

	struct MyJoin<T> {
	handle: thread::JoinHandle<T>,
	signal: Receiver<()>
	}

	impl<T> MyJoin<T> {

	'''
	Title: SSHtranger Things
	Author: Mark E. Haase <[email protected]>
	Homepage: https://www.hyperiongray.com
	Date: 2019-01-17
	CVE: CVE-2019-6111, CVE-2019-6110
	Advisory: https://sintonen.fi/advisories/scp-client-multiple-vulnerabilities.txt
	Tested on: Ubuntu 18.04.1 LTS, OpenSSH client 7.6p1

	We have nicknamed this "SSHtranger Things" because the bug is so old it could be

	! --------------------------------------------------------------------------------
	! This example configuration shows what WE did to get Amazon VPC working with our
	! ASAs. We use version 8.3(1). This config has not been reviewed or otherwise
	! blessed in any way by anyone at Amazon. YMMV.
	!
	! It differs from Amazon's supplied config by using two different sets of
	! crypto maps and ACLs, so it brings both tunnels up simultaneously.
	!
	! For the purposes of the example, the physical datacenter network is 172.16.1.0/24
	! and the VPC is 10.0.0.0/16.

	#define _XOPEN_SOURCE 700
	#include <signal.h>
	#include <unistd.h>

	int main()
	{
	sigset_t set;
	int status;

	if (getpid() != 1) return 1;

	#!/bin/awk -f
	# ▌ ▜ ▌
	# ▛▌▐ ▀▌▌▌▌▙▘
	# ▙▌▐▖█▌▚▚▘▛▖ - Draw an image using block characters and ImageMagick
	#===============================================================================

	# USAGE:
	# blawk [columns lines] file [imagemagick_arguments]

	BEGIN {

	aws ec2 register-image --ena-support --sriov-net-support simple --virtualization-type hvm --name ami-base-centos --block-device-mappings '[{"DeviceName":"/dev/sda1","Ebs":{"SnapshotId":"snap-05168016823a3fc9f"}}]' --root-device-name /dev/sda1 --architecture x86_64 --profile rdc-com-production

	aws ec2 create-tags --tags Key=OS,Value=CentOS Key=Application,Value=base --resources ami-423a593d --profile rdc-com-production