{"id":16376576,"url":"https://github.com/killercup/presentation-rust-approach","last_synced_at":"2025-07-30T12:07:35.177Z","repository":{"id":66475149,"uuid":"161644460","full_name":"killercup/presentation-rust-approach","owner":"killercup","description":null,"archived":false,"fork":false,"pushed_at":"2018-12-15T14:29:54.000Z","size":11332,"stargazers_count":6,"open_issues_count":1,"forks_count":0,"subscribers_count":4,"default_branch":"master","last_synced_at":"2025-04-07T17:47:00.447Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"https://killercup.github.io/presentation-rust-approach/index.html","language":"CSS","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/killercup.png","metadata":{"files":{"readme":"Readme.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2018-12-13T13:38:53.000Z","updated_at":"2018-12-17T13:02:29.000Z","dependencies_parsed_at":"2023-06-01T13:00:48.387Z","dependency_job_id":null,"html_url":"https://github.com/killercup/presentation-rust-approach","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/killercup/presentation-rust-approach","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/killercup%2Fpresentation-rust-approach","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/killercup%2Fpresentation-rust-approach/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/killercup%2Fpresentation-rust-approach/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/killercup%2Fpresentation-rust-approach/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/killercup","download_url":"https://codeload.github.com/killercup/presentation-rust-approach/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/killercup%2Fpresentation-rust-approach/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":267662209,"owners_count":24123842,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-07-29T02:00:12.549Z","response_time":2574,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-10-11T03:25:10.673Z","updated_at":"2025-07-29T09:32:29.811Z","avatar_url":"https://github.com/killercup.png","language":"CSS","funding_links":[],"categories":[],"sub_categories":[],"readme":"---\ntitle: \"Rust’s approach of getting things right\"\nauthor: Pascal Hertleif\ndate: 2018-12-15\ncategories:\n- rust\n- presentation\nprogress: true\nslideNumber: true\nhistory: true\nnavigation: false\ncontrols: 0\nheight: 600\nwidth: 800\n---\n# Hi, I'm Pascal Hertleif\n\n- Dev tools team\n- [CLI WG]\n- {[twitter],[github]}.com/killercup\n- Rust-centric blog: [deterministic.space]\n\n[CLI WG]: https://rust-lang-nursery.github.io/cli-wg/\n[twitter]: https://twitter.com/killercup\n[github]: https://github.com/killercup\n[deterministic.space]: https://deterministic.space/\n\n::: notes\n\nI've been working with Rust since early 2014,\nand I've been loving every minute of it.\n\nRight now, I'm leading the CLI working group.\nOur goal is to make writing command line applications in Rust _amazing_!\n\nOkay.\n\nFirst things first.\n\n:::\n\n- - -\n\n\u003e […] getting things right\n\u003e\n\u003e \u003ccite\u003e– Pascal, writing presumptuous talk titles\u003c/cite\u003e\n\n::: notes\n\nWow, such a presumptuous title!\nWhat was I thinking?\nCan I deliver a talk on how to write the _perfect_ program?\n\nOf course not.\nThis is not even a technical talk in these sense that it'll contain code!\nI'll talk about a bunch of cool projects,\nbut what I want to get at is:\nHow can we make more of those?\n\nWhy?\nWe are still trying to figure out how to write great Rust code.\nThere are some big ambitious projects in it that work;\nbut there is no 5 Steps guide to making one of those.\n\n:::\n\n- - -\n\n# What is Rust?\n\n\u003e A systems programming language\n\u003e that runs blazingly fast,\n\u003e prevents segfaults,\n\u003e and guarantees thread safety.\n\n::: notes\n\nThat's cool, but what does that mean _for me_?\n\n:::\n\n- - -\n\n# What is Rust?\n\n\u003e Empowering everyone to build reliable and efficient software.\n\n::: notes\n\nLess of a feature checklist,\ntells you how it helps _you_.\n\nThis is the slogan right next to the Rust logo on the current website.\nI know it took quite a while to settle on this,\nand I think it's super good.\n\n:::\n\n- - -\n\n## What is Rust?\n\n\u003e Technology from the past come to save the future from itself\n\u003e\n\u003e \u003ccite\u003e– Graydon Hoare, inventor of Rust\u003c/cite\u003e\n\n. . .\n\n\u003cimg src=\"images/travolta.gif\" alt=\"confused travolta\" style=\"border: 0; width: 50%; box-shadow: none;\" /\u003e\n\n::: notes\n\nWoah, that's a completely different spin on it.\n\nWhat did Graydon mean by it?\n\nBy the way, he goes on to say:\n\n\u003e Many older languages \\[are\\] better than new ones.\n\u003e We keep forgetting already-learned lessons.\n\n:::\n\n- - -\n\n## Prior art\n\n\u003e all information\n\u003e that has been made available to the public\n\u003e in any form\n\u003e before a given date\n\u003e that might be relevant\n\u003e to a patent's claims of originality.\n\u003e\n\u003e – [Wikipedia](https://en.wikipedia.org/wiki/Prior_art)\n\n::: notes\n\nThis talk is on how the Rust community embraces the idea of\nlooking at \"prior art\".\n\nIf you don't know this phrase, here is how Wikipedia defines it.\nAs you can see it's originally from patent laws.\n\n:::\n\n- - -\n\n![](images/copy-cup.jpg)\n\n::: notes\n\nLuckily,\na lot of the concepts we use\nand the software we write\nis open source.\n\nAnd it turns out that stealing software (or ideas)\nis not really possible,\nsince the original doesn't just vanish.\n\n:::\n\n- - -\n\n## We don't need to re-invent everything\n\nEmbrace existing ideas and put them into our current context.\n\n. . .\n\n~~Not invented here~~\n\n::: notes\n\nSome people I know have this tendency\nto try to work through problem all on their own.\nThey sit down,\nthink real hard,\nand come up with a solution.\nThat is a good idea when it comes to very domain-specific problems\nbut more general concepts\nit really pays off to look at what is already out there.\n\n:::\n\n- - -\n\n## This is not a \"Rewrite it in Rust\" talk\n\n. . .\n\nIt's more of a \"be curious and try out weird things\" kind of talk\n\n::: notes\n\nBut I don't mean this in the sense of:\nLook at an existing piece of software\nand rewrite it in Rust,\njust because you think it being Rust makes it better.\n\nWe should always make sure to adapt to the current context.\nWhat have we learned in the meantime?\nWhat were the original designers not happy with?\n\n:::\n\n- - -\n\n# For example:\u003cbr/\u003eThe borrow checker\n\nProblem: Write memory-safe high-performance code\n\n::: notes\n\nI'll talk about some projects, as well as some people, and their stories.\nThe first one is about the borrow checker.\nOr, the Ownership and Borrowing system\nthat is arguably the main features that differentiates Rust\nfrom other mainstream languages.\n\nThe problem was writing memory-safe high-performance code.\nC/C++ allow writing high-performance code but getting it right is very hard.\n\nRust is a try at making a language\nthat allowed both:\nHigh performance, and memory safety.\n\n:::\n\n- - -\n\n## Prior art\n\n. . .\n\n[Cyclone] (2002)\n\n- \"safe C\"\n- never-NULL pointers\n- region analysis\n\n. . .\n\n[ATS] (2005)\n\n- ML-inspired language \n- built-in theorem prover\n\n[Cyclone]: https://en.wikipedia.org/wiki/Cyclone_(programming_language)\n[ATS]: https://en.wikipedia.org/wiki/ATS_(programming_language)\n\n::: notes\n\nI specifically said \"mainstream languages\":\nBecause there are other languages that tried that before!\n\nAt AT\u0026T Labs, the Cyclone language was developed as a \"safe C\" dialect.\nIf you look at its features you'll see a bunch of similarities with Rust:\n\n- pointer types that are guaranteed to be not-NULL\n- pointers must be initialized before they can be used\n- only safe casts\n\nAnother language is ATS (Applied Type System).\nIt's inspired by ML,\nand its main feature is the built-in theorem prover.\nUsing this, it can,\nat compile-time,\nprove the absence of buffer overflows and memory corruptions,\nbut also other properties like division by zero. \n\n:::\n\n- - -\n\n## Prior art\n\n[Affine logic](https://en.wikipedia.org/wiki/Affine_logic)\n\n::: notes\n\nThose languages seem interesting\nbut let's have a little wider of a look.\n\n\u003e The logicians usually get there before the computer scientists.\n\u003e\n\u003e – Philip Wadler on [Corecursive #21](https://corecursive.com/021-gods-programming-language-with-philip-wadler/)\n\n(Philip Wadler is Professor of Theoretical Computer Science at University of Edinburgh)\n\n\u003e 1. can be used any number of times (default)\n\u003e 2. can't be used more than once (affine)\n\u003e 3. must be used at least once (relevant)\n\u003e 4. must be used exactly once (linear)\n\u003e\n\u003e – Gankro in [The Pain Of Real Linear Types in Rust](https://gankro.github.io/blah/linear-rust/)\n\n:::\n\n- - -\n\n## Prior art\n\n\u003e This work is about a functional language \\(Λ_{LA}\\), with a typable sub-set \\(Λ^{T}_{LA}\\). The types for \\(Λ^{T}_{LA}\\) are polymorphic formulas of Intuitionistic Light Affine Logic […]\n\u003e\n\u003e \u003ccite\u003e– Roversi, Luca. \"Light affine logic as a programming language: a first contribution.\" _International Journal of Foundations of Computer Science_ 11.01 (2000): 113-152.\u003c/cite\u003e\n\n::: notes\n\nPeople tried to define programming languages based on affine logic before.\nRoversi describes \\(Λ^{T}_{LA}\\) (\"Lambda L.A. T.\") in 2000.\n\nSimilar to ATS and Cyclone this doesn't become recognized by mainstream programmers.\n\n:::\n\n- - -\n\n\u003e […] Rust finally nailed it down in a way that is accessible to everyone.\n\u003e\n\u003e \u003ccite\u003e– Stjepan Glavina\u003c/cite\u003e\n\n::: notes\n\nAnd this is where Rust made the break-through:\nIt is based on the same, old concept of affine logic,\nbut packages it up in a practical and attractive way.\n\nThat Rust makes this (somewhat) approachable\nis probably why we are here, at a Rust conference.\n\n:::\n\n- - -\n\n## Adapting to the current context\n\nOriginal `borrowck` doesn't understand all valid programs\n\n. . .\n\nNon-lexical lifetimes\n\n. . .\n\nBorrow parts of a struct, self-references\n\n::: notes\n\nJust adapting affine logic is not enough,\nwe need to make it actually usable.\nThe first iteration was good,\nbut had known cases it didn't support.\n\nThis is where new research is being done.\nNon-lexical lifetimes refined what the scope of an owned resource is.\n\nBut this is not the end, either.\nBorrowing/mutating parts of structs can still be made smoother.\nSee Niko's thoughts on [After NLL](http://smallcultfollowing.com/babysteps/blog/2018/11/01/after-nll-interprocedural-conflicts/).\n\n:::\n\n- - -\n\n# Another example: ripgrep\n\n[super fast](https://blog.burntsushi.net/ripgrep/)\ncompetitor to `grep` and `ag`\n\nuses Rust's regex crate\n\n- - -\n\n## Prior art (regex)\n\n\u003e - Pike VM\n\u003e - Boyer-Moore \u0026 Aho-Corasick\n\u003e - Lazy DFA\n\u003e - Teddy\n\n::: notes\n\n- Pike VM: executes regular expressions using deterministic finite automaton\n- Find literal prefixes faster using Aho-Corasick or Boyer-Moore\n- lazy: Build DFA as you go, and cache states, inspired by Russ Cox writing on this\n- Teddy: Use SIMD instructions for substring matching, from Hyperscan project\n\ncf. [Hacking](https://github.com/rust-lang/regex/blob/master/HACKING.md) doc in regex repo\n\n:::\n\n- - -\n\n## Adapting to the current context\n\n\u003e - Bringing it all together\n\u003e - Unicode support\n\u003e - Highly concurrent\n\n::: notes\n\nThis is all interesting,\nbut why is ripgrep so successful?\n\n(bringing it all together, unicode, concurrency)\n\nSo far we've seen two big examples\nof cool Rust projects;\nwhich are arguably also the most famous ones.\n\nBut let's look at another story.\nI've quoted Stjepan Glavia before.\nYou might know him as the author of `crossbeam-channel`\nbut Stjepan also wrote the implementation of `[T]::sort()`.\n\n:::\n\n- - -\n\n# Why `sort()` is like it is\n\n\u003e I was reading the previous implementation of `sort`,\n\u003e just out of curiosity,\n\u003e and thought \"wait, this could be done better\".\n\u003e\n\u003e \u003ccite\u003e– Stjepan Glavina\u003c/cite\u003e\n\n::: notes\n\nThe most important part in this quote,\nfor me,\nis \"out of curiosity\".\nBeing curious is an amazing trait!\nWe should embrace it,\nand help people be curious.\n\n:::\n\n- - -\n\n## Prior art\n\n- current impl\n- regular merge sort\n- blocksort\n- timsort\n- …\n\n(See [Rust PR #38192](https://github.com/rust-lang/rust/pull/38192) for details)\n\n::: notes\n\nSorting algorithms are one of the introductory topics in computer science.\nThat doesn't make them boring, though!\nThere a bunch of real-world considerations\nthat are discussed on little in academia,\nlike cache locality.\n\n:::\n\n- - -\n\n## Community\n\nThis was Stjepan's first PR for Rust!\n\n. . .\n\nIt took just three days to get into `std`!\n\n. . .\n\nHe followed this up with a RFC to add `sort_unstable`\n\n::: notes\n\nImagine this:\nYou check the implementation of a standard library function for fun.\n(Who doesn't click on \"src\" in the docs for fun?)\nYou write a 200 line PR (plus comments and benchmarks).\nAnd three days later this is part of the std lib!\n\n:::\n\n- - -\n\n# Where to find inspiration: Other ecosystems\n\n- - -\n\n## crossbeam-channel\n\nAn improvement for the channels in `std`\n\n. . .\n\nTake inspiration from Go's implementation\n\n. . .\n\nbounded/unbounded, MPMC, fancy `select!` macro\n\n::: notes\n\nStjepan's next project was crossbeam-channels.\n\n- `std::sync::mpsc`: single consumer, no stable `select!`, slow\n- idea: bounded and unbounded mpmc channels\n- [Designing a channel](https://stjepang.github.io/2017/08/13/designing-a-channel.html)\n- [Lessons to be taken from channels in Go?](https://github.com/crossbeam-rs/crossbeam-channel/issues/39) - [design doc from go](https://docs.google.com/document/d/1yIAYmbvL3JxOKOjuCyon7JhW4cSv1wy5hC0ApeGMV9s/pub)\n- [crossbeam-channel select macro](https://github.com/crossbeam-rs/crossbeam-channel/pull/41)\n- [perf](https://i.imgur.com/tRI4HMO.png) ([src](https://twitter.com/stjepang/status/1006202765499125760))\n    - avoid lock contention as much as possible - the typical \"happy path\" is lock-free.\n    - Plus, there is a lot of small optimizations that add up.\n\n:::\n\n- - -\n\n## Other examples\n\n- [parking_lot](https://github.com/rust-lang/rust/pull/56410)\n- [hashbrown](https://github.com/rust-lang/rust/pull/56241)\n\n::: notes\n\nparking_lot contains user-space synchronization primitives, taken from Webkit\n\nhashbrown is a port of Google's SwissTable, a super fast hash table implementation\n\nthey work as drop-in replacements! both have open PRs to be used in `std`\n\n:::\n\n- - -\n\n# Where to find inspiration: Academia\n\n::: notes\n\nHow many of you studied something related to computer science?\n\nHow many of you liked reading papers? I know it's not easily accessible.\n\nBut…\n\n:::\n\n- - -\n\n\u003e So many awesome engineering projects can be pulled off by\n\u003e just taking a quick glance at where current research is at in a\n\u003e particular field.\n\u003e \n\u003e Often, implementations are lagging by several decades.\n\u003e \n\u003e \u003ccite\u003e– Tyler Neely\u003c/cite\u003e\n\n::: notes\n\nThere is a huge opportunity here,\nand I feel like not enough people know about it!\n\n:::\n\n- - -\n\n## Where to find interesting papers\n\n- [Papers We Love](https://paperswelove.org/) (paperswelove.org)\n- [the morning paper](https://blog.acolyer.org/) (blog.acolyer.org)\n\n::: notes\n\nYou can find a lot of research on a huge variety of topics\nfor free.\nThe problem is most often curating.\nFor example, check PapersWeLove.org or \"the morning paper\" blog.\n\nReading papers is not easy, though.\nThe same Tyler also told me this story of how he is a really slow reader\nand this means that he can't just read a paper on his lunch break\nand get anything usable from it.\n\nI feel the same way,\nand I'd like to share with you some common approaches\nto reading academic works.\nFirst reading the abstract, i.e., the summary at the beginning of the paper,\nis a good idea.\nI then tend to skip right to the conclusion,\nwhich often has the same content\nbut put into different words and described from a different perspective.\nJust having read that is a great way to judge if this paper is interesting to you.\nAfter that, you also have a better understanding of the context\nthe paper was written in.\nAnd you might be able to identify the sections that are most interesting to you.\n\n:::\n\n- - -\n\n\u003e Most of the things I read have no useful application for me right away.\n\u003e I need to let them simmer for a while.\n\u003e\n\u003e \u003ccite\u003e– Geoffroy Couprie\u003c/cite\u003e\n\n::: notes\n\nSo can you act like a machine that consumes research papers\nand produce awesome Rust projects?\nProbably not.\nThat's not how people or research work.\n\n:::\n\n- - -\n\n\u003e Whenever something interesting comes out of academia, I try to think:\n\u003e How do we make this more practical?\n\u003e Can we reach a little bit farther?\n\u003e Can we bend the curve somewhere?\n\u003e\n\u003e \u003ccite\u003e– Stjepan Glavina\u003c/cite\u003e\n\n::: notes\n\nYou can approach this with a certain point of view, though.\nLike: What can we do with this that wasn't possible before?\n\n\u003e […] we still have to make compromises *somewhere* […],\n\u003e but we try to bend the curve as far as possible,\n\u003e to reach into areas that were previously thought of as unimaginable.\n\u003e\n\u003e \u003ccite\u003e– Stjepan Glavina\u003c/cite\u003e\n\n:::\n\n- - -\n\n## \"bend the curve\"\n\nThe community is trying to find a way to overcome traditional trade-offs\n\n. . .\n\nincl. putting brand-new research into non-intimidating Rust-flavored packages!\n\n::: notes\n\n- memory safety without garbage collection\n- abstraction without overhead\n\nbut also:\n\n\u003e expert-only, researchy concurrency in a non-intimidating Rust-flavored package\n\n(Stjepan)\n\n:::\n\n- - -\n\n# Another tale: Green threads\n\n\u003e - Rust used green threads for async I/O\n\u003e - They were removed\n\u003e - Not the easy thing to do, but pays off in the long run\n\n::: notes\n\nTo allow nice async I/O,\ngreen threads and global event loop are good ideas.\nThere was a lot of prior art on this.\nSo that is what Rust had in 2014.\n\nBut:\nIt didn't fit well with the direction the language was being developed in.\n\nSo despite not having an alternative ready,\ngreen threads were removed.\n\nThis is why now we're seeing futures and async/await being implemented\nin totally different styles,\nbased on state machines and generators.\n\nThis wasn't the easy way,\nbut it was the one that gives Rust much of the flexibility it has today.\n\nIf you want to hear more about that,\ngo to Katharina's keynote later today.\n\n:::\n\n- - -\n\n## It's okay to iterate on ideas\n\nThe first version might not be perfect\n\n. . .\n\nand that's totally okay\n\n::: notes\n\n- too complicated\n- too weird/not a good fit\n- not powerful enough\n\nThis is one of the reasons why there are so many features in Rust\nthat are marked as 'unstable'\n-- people know/think that we can still do better!\n\n:::\n\n- - -\n\n\u003e I think of Rust as fertile ground for growing cool stuff.\n\u003e\n\u003e \u003ccite\u003e– Stjepan Glavina\u003c/cite\u003e\n\n- - -\n\n# Do ambitious things!\n\n\u003e 1. Be curious!\n\u003e 2. Try to bend the curve!\n\u003e 3. Help people discover awesome things!\n\n::: notes\n\nLet's recap.\n\nThis is the part of the talk where\nI need to put a lot of exclamation marks on the slide.\n\nRust is in a very good place\nfor you to try and do ambitious things.\nWe are all trying to figure out how to use Rust.\nThere is much to be explored!\n\n:::\n\n- - -\n\n# Where to look for inspiration\n\n\u003e 1. Other ecosystems\n\u003e 2. Academia\n\u003e 3. Completely different areas?\n\n::: notes\n\n\n\n:::\n\n- - -\n\n# Thank you!\n\nI'm Pascal and I want you to talk to me!\n\n{[twitter],[github]}.com/killercup\n\nSlides: [git.io/rust-approach](https://git.io/rust-approach)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fkillercup%2Fpresentation-rust-approach","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fkillercup%2Fpresentation-rust-approach","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fkillercup%2Fpresentation-rust-approach/lists"}