[HN Gopher] Investing in Rust
___________________________________________________________________
Investing in Rust
Author : 0xedb
Score : 29 points
Date : 2024-07-20 16:54 UTC (6 hours ago)
(HTM) web link (www.lawfaremedia.org)
(TXT) w3m dump (www.lawfaremedia.org)
| blastonico wrote:
| Evangelists are using this CrowdStrike problem to preach about
| Rust. No, I don't have 10 minutes to hear about your lord. I
| could bet that most of these "new Rust safe programs" will start
| like this:
|
| unsafe { // your code goes here }
| j-pb wrote:
| Unsafe doesn't operate on that scope, and it's not about the
| language primitives but the features that let you to ensure
| things about their usage.
|
| Something I've just realized recently is that while not all
| Rust programs are safe and sane, Rust is one of the few
| langages with a type system powerful enough that you can
| actually specify and build safe and sane programs with it.
|
| Languages like C/C++ and friends don't have more inherently
| dangerous primitives they just lack that type system. Same
| floor, lower ceiling.
| Proziam wrote:
| It's not _just_ the type system either. It also helps that
| rust has a great ecosystem of tools that catch all kinds of
| errors at build time. The compiler and clippy together
| genuinely do prevent _a lot_ of mistakes.
|
| This is a big part of why people often say "if it compiles,
| it works" in rust.
| blastonico wrote:
| You people seem to underestimate the average sloppy
| programmer. Rust is yet composed of people that take
| programming seriously. One day it will be as popular as C++
| or Java, and will you start seeing wonders in code bases
| around the world.
|
| I've seen it before with Java. That thing was pure OO,
| contained in a VM with GC, perfect world. Poor guy that has
| to maintain Java legacy code these days. Right, right, this
| time is different.
| jenadine wrote:
| > I could bet that most of these "new Rust safe programs" will
| start like this: unsafe { // your code goes here }
|
| I'll take your bet. Most Rust program I've seen don't use
| unsafe or when they do, it is fairly limited in scope.
| Proziam wrote:
| One step further, many rust libs use
| `#![forbid(unsafe_code)]` to explicitly disallow any unsafe.
| The rust community really likes that sort of thing, and for
| good reason.
| blastonico wrote:
| Rust is not widely adopted yet. When the mass of sloppy
| programmers are required to write code (applications,
| drivers, etc.) in Rust, you will take the bet back.
| j-krieger wrote:
| I disagree. Rust is more widely adopted than you think,
| more so in mission critical software. Every major player
| uses it. It runs on embedded, Android, iOS, in your
| browser, it's in the Linux kernel. Things will just be
| accelerating from here.
| timeon wrote:
| > I could bet that
|
| Chance of winning on betting is usually pretty small.
| j-krieger wrote:
| You have no idea what you're talking about. Unsafe doesn't work
| this way.
| wslh wrote:
| I wonder if you have any experience or opinions about dealing
| with the Rust Foundation itself. My personal observation from
| small talks with them is that Rust decentralized communities are
| the driving force.
| diffxx wrote:
| I support the push towards memory safe languages but emphasizing
| Rust in the way this paper does seems misguided. It creates a
| false dichotomy between c style languages without safety
| guarantees and Rust as though there are no other alternatives.
| There are other approaches and models that can also achieve bare
| metal performance for many problems without taking in all of the
| complexity of Rust. Moreover, we will never settle on one
| language to rule them all (and if we do I am 100% sure it will
| not be Rust), so we should be emphasizing approaches to
| mitigating vulnerabilities rather than prescribing a particular
| tool.
| mmoskal wrote:
| Which alternatives exactly? Mainstream languages like Go and
| Swift use a GC and don't allow the same level of control over
| memory layout.
|
| There are probably some reasons Rust is only non-C language to
| get into Linux kernel.
| trealira wrote:
| In its own words, this paper calls for:
|
| - an addition to the critical infrastructure information
| technology sector,
|
| - a cloud computing tax to fund critical U.S. cyber defense
|
| - U.S.-sponsored governance for emerging cybersecurity solutions
| like Rust, and
|
| - a U.S.-sponsored open source library verification service.
|
| Some relevant quotes:
|
| - Cloud sales tax:
|
| -- "A cloud computing tax is long overdue, and it must be
| collected to secure the software supply chain for American
| consumers."
|
| -- "A cloud sales tax would put the cost of securing open source
| for U.S. economic stability on the companies that have profited
| the most from open source software--its biggest consumers. The
| Open Source Trust can offer financial support to open source
| communities, allow for more free-flowing exploration of our
| technology frontier, and close a gaping hole in America's
| economic stability."
|
| - "A public-private partnership effort to build an actionable
| cookbook for memory-safety migration would be a better first step
| than urging technology manufacturers to use the one available
| today." ... "CISA should partner with early Rust adopters to
| identify their insights, costs, and wins and visibly incorporate
| that data into the roadmap guidance." ... "CISA should lead an
| initiative to create this cookbook for memory-safety migration
| starting with Rust, where there is little institutional knowledge
| available today, and this work should be funded by the Open
| Source Trust."
|
| - Because Rust's memory safety and analysis tools are limited,
| and because engineers "need education and tools to know when to
| use [unsafe Rust] and how to mitigate the risks 'unsafe Rust'
| introduces," CISA SEI should "receive Open Source Trust funding
| to continue their research and development and (a) reduce the
| limitations of the Rust compiler, (b) audit the Rust compiler's
| correctness in assessing the memory safety of Rust code, and (c)
| develop both static and dynamic analysis tools for safe and
| unsafe Rust."
|
| - Also, CISA should "receive additional Open Source Trust funding
| to support rapid, in-depth development of standards across
| package repositories, compilers, and build tools" to mitigate the
| the security problems that come from one person controlling a
| crate that thousands depend on.
|
| This isn't that important, but it's interesting, because I have
| often heard complaints here that Rust is hard to read.
|
| "Rust is also the easiest programming language to sight-read.
| Engineers reading new code are like musicians reading unfamiliar
| sheet music. There are always recognizable elements, but the
| theme, pace, and key may be outside of the player's experience.
| In software, those unfamiliar elements can take a developer
| through a complicated maze of dependencies and logic trees, and
| Rust makes the trail of logic in a program easier to follow.
| Researchers have concluded that Rust has a significantly lower
| cognitive complexity than C, C++, Python, JavaScript, and
| TypeScript (all languages studied), "meaning that [Rust] can
| guarantee the highest understandability of source code compared
| to all others." As a result, software maintainers can understand
| unfamiliar Rust code far more quickly than code wri0en in many
| other popular languages."
|
| They cite this study:
| https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7959618/
| j-krieger wrote:
| What I really, _really_ need from Rust maintainers is a
| #[forbid(panic)] somewhen in the next releases.
___________________________________________________________________
(page generated 2024-07-20 23:09 UTC)