5 ms·

Investing in Rust

47 points by 0xedb 2y ago

blastonico 2y ago
[flagged]
- j-pb 2y ago
  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 2y ago
    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 2y ago
    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.
    - pornel 2y ago
      Rust is already popular and old enough to have terrible Enterprise Rust code bases. There are a few things working in Rust's favor: * unsafe code is used to build safe abstractions around it, so most users don't have to write unsafe code themselves. It is easy to forbid use of unsafe blocks in your own codebase. You can flag unsafe code during code reviews, and have a policy who is allowed to write unsafe code. * Rust leans on open-source dependencies a lot. Commonly used libraries are decent, since the community can band together to improve or replace them. This makes Rust applications mostly "glue" code, where there's less room to mess up in novel ways. * the language allows defining strict library APIs which are harder to misuse. There's Clippy checking for common mistakes and sloppy code. Rust already assumes that it will be written by less than prefect programmers.
    - ttfkam 2y ago
      What do YOU mean, "You people"? https://youtu.be/99IoN2pymfE?si=xF1me0YbEaK_bvlV https://youtu.be/99IoN2pymfE?si=xF1me0YbEaK_bvlV
- jenadine 2y ago
  > 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 2y ago
    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 2y ago
    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.
    - selfmodruntime 2y ago
      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.
      - blastonico 2y ago
        Rust in Linux kernel is a bold statement. It's a PoC, nothing relevant is implement in it yet.
- timeon 2y ago
  > I could bet that Chance of winning on betting is usually pretty small.
- selfmodruntime 2y ago
  You have no idea what you’re talking about. Unsafe doesn’t work this way.
wslh 2y ago
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 2y ago
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 2y ago
  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.
  - _orz_ 2y ago
    That’s just not true, Swift doesn’t use GC but reference counting.
    - super_flanker 2y ago
      Reference Counting is a type of GC.
    - bdjsiqoocwk 2y ago
      Stop using words you don't understand, it's dishonest.
      - _orz_ 2y ago
        Sorry? So obviously with GC one means managed GC. Otherwise the comment above doesn’t make any sense at all since then Rust itself would use GC because it also supports reference counting. Strictly speaking you could obviously say reference counting is a form of GC. So to avoid GC you then surely recommend people to use C since that, in contrast to Rust, Swift, C++ and many others, really doesn’t use any GC, neither managed nor reference counting based.
trealira 2y ago
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 proﬁted the most from open source software—its biggest consumers. The Open Source Trust can offer ﬁnancial support to open source communities, allow for more free-ﬂowing 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 ﬁrst 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 signiﬁcantly 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/ https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7959618/
selfmodruntime 2y ago
What I really, really need from Rust maintainers is a #[forbid(panic)] somewhen in the next releases.
- duped 2y ago
  What do you need it for? That would forbid tons of code, like array indexing and unreachable!(). There's the UnwindSafe marker trait that isn't exactly the same thing but addresses the only real case I've seen for forbidding panics which is FFI.
  - AlotOfReading 2y ago
    There's plenty of situations where telling developers to go change their code so it doesn't panic might be an appropriate lint. Think safety critical rust for example.
    - sshine 2y ago
      Adding to this argument: A lot of panics are placed instead of proper error handling as a cause of happy-path programming. (E.g. all cases of .unwrap()) Some panics are placed not knowing they’re panics. (E.g. indexing, calling a function that panics) Some panics are legitimately placed by people who want a program to panic at a given place; this may collide with the caller’s desire to use Result and error types. There are lots of situations where being notified about where the panics live can make your code more robust, because they do sneak in.
      - SkiFire13 2y ago
        But what about those panics for "I know this situation cannot possibly happen"?
        sshine 2y ago
        For those you have `unreachable!()` (a hope rather than a certainty): https://doc.rust-lang.org/std/macro.unreachable.html https://doc.rust-lang.org/std/macro.unreachable.html In those cases you strike a deal with the devil. The type system won't help you. Maybe it's an acceptable tradeoff for readability and efficiency. Maybe you could have modelled the code so it wasn't necessary. I think you can divide the use of `unreachable!()` in two cases: 1) As a consequence of style (applying LEM to code) 2) As a consequence of low-level abstractions One can be avoided by remodelling. The other can be tucked away behind safe interfaces.
edgarvaldes 2y ago
Is there currently public funding for any other programming languages?
- foresto 2y ago
  The Sovereign Tech Fund lists Fortran and PHP among its investments. https://www.sovereigntechfund.de/tech https://www.sovereigntechfund.de/tech
- Yoric 2y ago
  At least OCaml, Haskell, SML.
  - sshine 2y ago
    Futhark is being developed at a university, so at least there is partially public funding.
up2isomorphism 2y ago
The author does not seem to have written much code. Also trying to get government funding for a particular language seems like a lobbying to me.

Investing in Rust

47 points by 0xedb 2y ago

blastonico 2y ago

[flagged]

j-pb 2y ago
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 2y ago
  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 2y ago
  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.
  - pornel 2y ago
    Rust is already popular and old enough to have terrible Enterprise Rust code bases. There are a few things working in Rust's favor: * unsafe code is used to build safe abstractions around it, so most users don't have to write unsafe code themselves. It is easy to forbid use of unsafe blocks in your own codebase. You can flag unsafe code during code reviews, and have a policy who is allowed to write unsafe code. * Rust leans on open-source dependencies a lot. Commonly used libraries are decent, since the community can band together to improve or replace them. This makes Rust applications mostly "glue" code, where there's less room to mess up in novel ways. * the language allows defining strict library APIs which are harder to misuse. There's Clippy checking for common mistakes and sloppy code. Rust already assumes that it will be written by less than prefect programmers.
  - ttfkam 2y ago
    What do YOU mean, "You people"? https://youtu.be/99IoN2pymfE?si=xF1me0YbEaK_bvlV https://youtu.be/99IoN2pymfE?si=xF1me0YbEaK_bvlV
jenadine 2y ago
> 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 2y ago
  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 2y ago
  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.
  - selfmodruntime 2y ago
    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.
    - blastonico 2y ago
      Rust in Linux kernel is a bold statement. It's a PoC, nothing relevant is implement in it yet.
timeon 2y ago
> I could bet that Chance of winning on betting is usually pretty small.
selfmodruntime 2y ago
You have no idea what you’re talking about. Unsafe doesn’t work this way.

wslh 2y ago

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 2y ago

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 2y ago
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.
- _orz_ 2y ago
  That’s just not true, Swift doesn’t use GC but reference counting.
  - super_flanker 2y ago
    Reference Counting is a type of GC.
  - bdjsiqoocwk 2y ago
    Stop using words you don't understand, it's dishonest.
    - _orz_ 2y ago
      Sorry? So obviously with GC one means managed GC. Otherwise the comment above doesn’t make any sense at all since then Rust itself would use GC because it also supports reference counting. Strictly speaking you could obviously say reference counting is a form of GC. So to avoid GC you then surely recommend people to use C since that, in contrast to Rust, Swift, C++ and many others, really doesn’t use any GC, neither managed nor reference counting based.

trealira 2y ago

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 proﬁted the most from open source software—its biggest consumers. The Open Source Trust can offer ﬁnancial support to open source communities, allow for more free-ﬂowing 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 ﬁrst 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 signiﬁcantly 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/ https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7959618/

selfmodruntime 2y ago

What I really, really need from Rust maintainers is a #[forbid(panic)] somewhen in the next releases.

duped 2y ago
What do you need it for? That would forbid tons of code, like array indexing and unreachable!(). There's the UnwindSafe marker trait that isn't exactly the same thing but addresses the only real case I've seen for forbidding panics which is FFI.
- AlotOfReading 2y ago
  There's plenty of situations where telling developers to go change their code so it doesn't panic might be an appropriate lint. Think safety critical rust for example.
  - sshine 2y ago
    Adding to this argument: A lot of panics are placed instead of proper error handling as a cause of happy-path programming. (E.g. all cases of .unwrap()) Some panics are placed not knowing they’re panics. (E.g. indexing, calling a function that panics) Some panics are legitimately placed by people who want a program to panic at a given place; this may collide with the caller’s desire to use Result and error types. There are lots of situations where being notified about where the panics live can make your code more robust, because they do sneak in.
    - SkiFire13 2y ago
      But what about those panics for "I know this situation cannot possibly happen"?
      - sshine 2y ago
        For those you have `unreachable!()` (a hope rather than a certainty): https://doc.rust-lang.org/std/macro.unreachable.html https://doc.rust-lang.org/std/macro.unreachable.html In those cases you strike a deal with the devil. The type system won't help you. Maybe it's an acceptable tradeoff for readability and efficiency. Maybe you could have modelled the code so it wasn't necessary. I think you can divide the use of `unreachable!()` in two cases: 1) As a consequence of style (applying LEM to code) 2) As a consequence of low-level abstractions One can be avoided by remodelling. The other can be tucked away behind safe interfaces.

edgarvaldes 2y ago

Is there currently public funding for any other programming languages?

foresto 2y ago
The Sovereign Tech Fund lists Fortran and PHP among its investments. https://www.sovereigntechfund.de/tech https://www.sovereigntechfund.de/tech
Yoric 2y ago
At least OCaml, Haskell, SML.
- sshine 2y ago
  Futhark is being developed at a university, so at least there is partially public funding.

up2isomorphism 2y ago

The author does not seem to have written much code. Also trying to get government funding for a particular language seems like a lobbying to me.