It takes a new grad software engineer between 1 and 3 years to master a programming language. Why do you believe that knowing any particular programming language is a barrier? In 2022 it’s unusual for experienced engineers not to know multiple languages.
I take it you haven’t seen Brainfuck yet? Rust is pretty straightforward and I was able to submit PRs fixing several bugs within an hour. I can’t write new code, but grasping what is going on is pretty easy. For a language to be “challenging” I’d say that it shouldn’t be easy to tell what is going on without knowing a bunch of language specific-ish operators (aka, Haskell).
Rust is actually quite easy to use, that's literally one of its selling points. It's supposed to allow you to use nicer syntax than C AND also gives you guardrails to prevent you from introducing memory unsafety.
>> POSIX is not linked to C. POSIX is a specification and that can be implemented in any language.
Here is an excerpt from the introduction to the POSIX standard:
"POSIX.1-2017 defines a standard operating system interface and environment, including a command interpreter (or "shell"), and common utility programs to support applications portability at the source code level. It is intended to be used by both application developers and system implementors.
POSIX.1-2017 comprises four major components (each in an associated volume):
General terms, concepts, and interfaces common to all volumes of POSIX.1-2017, including utility conventions and C-language header definitions, are included in the Base Definitions volume of POSIX.1-2017.
Definitions for system service functions and subroutines, language-specific system services for the C programming language, function issues, including portability, error handling, and error recovery, are included in the System Interfaces volume of POSIX.1-2017.
Definitions for a standard source code-level interface to command interpretation services (a "shell") and common utility programs for application programs are included in the Shell and Utilities volume of POSIX.1-2017.
Extended rationale that did not fit well into the rest of the document structure, containing historical information concerning the contents of POSIX.1-2017 and why features were included or discarded by the standard developers, is included in the Rationale (Informative) volume of POSIX.1-2017."
Implementing POSIX in Rust would require implementing C-language interfaces so that programs written in C could compile and call into the implemented interfaces the same way that POSIX-compliant implementations work today.
Do you really want to re-implement POSIX C APIs in Rust?
Or would it make more sense to have a redesigned, Rust-native API that replaces POSIX?
Is rust in Linux a good opportunity to review the Linux licensing?
For example, go Gplv2+ instead of just GPLv2?
Or maybe just forcing developers to subscribe their DCO (Developers Certificate Of Origin)
I remember a lot of kernel developers signing additional declarations to clear up some licensing issue, I remember it was not all of them and can't find the reference.
Basically any cleanup on the licensing side, so that you know that rust also means "the correct way"? Sure, it will take decades, but at least you would not be stuck with current "gplv2-only-dco-maybe-additional-guarantees"
FWIW, Rust has a strong "MIT or Apache" culture. These contributions to the kernel are "MIT or Apache," because what if the BSDs want to use these cool language bits for their OS?
15 comments
[ 4.9 ms ] story [ 50.2 ms ] threadDays before the entire kernel is written in rust.
I feel for the kernel devs who know just plain old unsecure/horrible C ;)
You guys had better start learning rust.
It was more a comment on the religious/naked fanboy-ism of rust. (like apple... like java... like vb...)
I think the dude that posted the message is way up there in the kernel tree. So I am assuming he/she knows what they are doing.
But it would be funny to have a countdown.
Given its similarities to c/c++, I’d expect someone to come up to speed in a quarter of the time or less.
The guardrails make it harder to shoot the proverbial foot, but also to get code to compile at all.
Well, at least at the beginning. One becomes used to the so-called "compiler-driven development", at which point it becomes a breeze.
Much of POSIX design is strongly linked to C and the Unix philosophy and conventions.
Rust follows different conventions so implementing POSIX in Rust seems like an impedance mismatch (see https://devblogs.microsoft.com/oldnewthing/20180123-00/?p=97...)
Edit: downvotes, but no replies? If you disagree, why? I would love to hear your thoughts.
What POSIX is is outside of the control of Linux. Linux wants to be POSIX compliant for compatibility. Changing POSIX would not make sense.
Here is an excerpt from the introduction to the POSIX standard:
"POSIX.1-2017 defines a standard operating system interface and environment, including a command interpreter (or "shell"), and common utility programs to support applications portability at the source code level. It is intended to be used by both application developers and system implementors.
POSIX.1-2017 comprises four major components (each in an associated volume):
General terms, concepts, and interfaces common to all volumes of POSIX.1-2017, including utility conventions and C-language header definitions, are included in the Base Definitions volume of POSIX.1-2017.
Definitions for system service functions and subroutines, language-specific system services for the C programming language, function issues, including portability, error handling, and error recovery, are included in the System Interfaces volume of POSIX.1-2017.
Definitions for a standard source code-level interface to command interpretation services (a "shell") and common utility programs for application programs are included in the Shell and Utilities volume of POSIX.1-2017.
Extended rationale that did not fit well into the rest of the document structure, containing historical information concerning the contents of POSIX.1-2017 and why features were included or discarded by the standard developers, is included in the Rationale (Informative) volume of POSIX.1-2017."
Source: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...
Implementing POSIX in Rust would require implementing C-language interfaces so that programs written in C could compile and call into the implemented interfaces the same way that POSIX-compliant implementations work today.
Do you really want to re-implement POSIX C APIs in Rust?
Or would it make more sense to have a redesigned, Rust-native API that replaces POSIX?
For example, go Gplv2+ instead of just GPLv2?
Or maybe just forcing developers to subscribe their DCO (Developers Certificate Of Origin)
I remember a lot of kernel developers signing additional declarations to clear up some licensing issue, I remember it was not all of them and can't find the reference.
Basically any cleanup on the licensing side, so that you know that rust also means "the correct way"? Sure, it will take decades, but at least you would not be stuck with current "gplv2-only-dco-maybe-additional-guarantees"
Can someone @Greg or even @Linus on this?
Doubt GPLv2+ has much resonance here.