"The Rust for Linux project, sponsored by Google, has advanced..." reported the Register earlier this week: A new set of patches submitted to the Linux kernel mailing list summarizes the progress of the project to enable Rust to be used alongside C for implementing the Linux kernel. The progress is significant.

- ARM and RISC-V architectures are now supported, thanks to work on rustc_codgen_gcc, which is a GCC codegen for rustc. This means that rustc does the initial compilation of Rust code but GCC (the GNU Compiler Collection) does the backend compilation, enabling support for the architectures that GCC supports...

- Overall, "the Rust support is still to be considered experimental. However, as noted back in April, support is good enough that kernel developers can start working on the Rust abstractions for subsystems and write drivers and other modules," continued project leader Miguel Ojeda, a computer scientist at CERN in Geneva, Switzerland, now working full time on Rust for Linux...

There is substantial support for the project across the industry. Google said in April "we feel that Rust is now ready to join C as a practical language for implementing the kernel" and that it would reduce the number of potential bugs and security vulnerabilities. Google is sponsoring Ojeda to work full time on the project for a year, via the ISRG (Internet Security Research Group), which said last month that it is part of "efforts to move the internet's critical software infrastructure to memory safe code," under the project name Prossimo. The ISRG is also the nonprofit organisation behind Let's Encrypt free security certificates. Ojeda also mentioned that Microsoft's Linux Systems Group is contributing and hopes to submit "select Hyper-V drivers written in Rust." Arm is promising assistance with Rust for Linux on ARM-based systems. IBM has contributed Rust kernel support for its PowerPC processor.

More detail is promised at the forthcoming Linux Plumber's Conference in September. In the meantime, the project is on GitHub here.
"In addition, we would like to announce that we are organizing a new conference that focuses on Rust and the Linux kernel..." Ojeda posted. "Details will be announced soon." And for context, the Register adds: Linus Torvalds has said on several occasions that he welcomes the possibility of using Rust alongside C for kernel development, and told IT Wire in April that it is "getting to the point where maybe it might be mergeable for 5.14 or something like that."

mrflash818 writes: The Internet Security Research Group (ISRG) -- parent organization of the better-known Let's Encrypt project -- has provided prominent developer Miguel Ojeda with a one-year contract to work on Rust in Linux and other security efforts on a full-time basis. Rust is a low-level programming language offering most of the flexibility and performance of C -- the language used for kernels in Unix and Unix-like operating systems since the 1970s -- in a safer way. Efforts to make Rust a viable language for Linux kernel development began at the 2020 Linux Plumbers conference, with acceptance for the idea coming from Linus Torvalds himself. Torvalds specifically requested Rust compiler availability in the default kernel build environment to support such efforts -- not to replace the entire source code of the Linux kernel with Rust-developed equivalents, but to make it possible for new development to work properly. Using Rust for new code in the kernel -- which might mean new hardware drivers or even replacement of GNU Coreutils -- potentially decreases the number of bugs lurking in the kernel. Rust simply won't allow a developer to leak memory or create the potential for buffer overflows -- significant sources of performance and security issues in complex C-language code.

"Google said Thursday it's funding a project to increase Linux security by writing parts of the operating system's core in the Rust programming language, a modernization effort that could bolster the security of the internet and smartphones," reports CNET: If the project succeeds, it'll be possible to add new elements written in Rust into the heart of Linux, called the kernel. Such a change would mark a major technological and cultural shift for an open-source software project that's become foundational to Google's Android and Chrome operating systems as well as vast swaths of the internet. Miguel Ojeda, who's written software used by the Large Hadron Collider particle accelerator and worked on programming language security, is being contracted to write software in Rust for the Linux kernel. Google is paying for the contract, which is being extended through the Internet Security Research Group, a nonprofit that's also made it easier to secure website communications through the Let's Encrypt effort.

Adding Rust modules to the Linux kernel would improve security by closing some avenues for hackers can use to attack phones, computers or servers. Since it was launched in 1991, Linux has been written solely in the powerful but old C programming language. The language was developed in 1972 and is more vulnerable to hacks than contemporary programming languages...

Google credits the Linux community programmers who began the Rust for Linux project. "The community had already done and continues to do great work toward adding Rust support to the Linux kernel build system," Google said in a blog post...

[Rust] has been the most loved programming language for five years running in Stack Overflow's annual developer survey. "Rust represents the best alternative to C and C++ currently available," Microsoft's security team concluded in 2019. The team said Rust would have prevented memory problems at fault in 70% of its significant security issues. And because Rust's checks happen while software is being built, the safety doesn't come at the expense of performance when the software is running.

The goal of the Linux on Rust project isn't to replace all of Linux's C code but rather to improve selective and new parts.

Google said Thursday it's funding a project to increase Linux security by writing parts of the operating system's core in the Rust programming language, a modernization effort that could bolster the security of the internet and smartphones. From a report: If the project succeeds, it'll be possible to add new elements written in Rust into the heart of Linux, called the kernel. Such a change would mark a major technological and cultural shift for an open-source software project that's become foundational to Google's Android and Chrome operating systems as well as vast swaths of the internet.

Miguel Ojeda, who's written software used by the Large Hadron Collider particle accelerator and worked on programming language security, is being contracted to write software in Rust for the Linux kernel. Google is paying for the contract, which is being extended through the Internet Security Research Group, a nonprofit that's also made it easier to secure website communications through the Let's Encrypt effort. Adding Rust modules to the Linux kernel would improve security by closing some avenues for hackers can use to attack phones, computers or servers. Since it was launched in 1991, Linux has been written solely in the powerful but old C programming language. The language was developed in 1972 and is more vulnerable to hacks than contemporary programming languages.

Python's creator Guido van Rossum shared his opinions on other programming languages during a new hour-long interview with Microsoft's principle cloud advocate manager. Some of the highlights:

• Rust: "It sounds like it's a great language — for certain things. Rust really improves on C++ in one particular area — it makes it much harder to bypass the checks in the compiler. And of course it solves the memory allocation problem in a near perfect way... if you wrote the same thing in C++, you could not be as sure, as compared to Rust, that you've gotten all your memory allocation and memory management stuff right. So Rust is an interesting language."

• Go and Julia: "I still think that Go is a very interesting language too. Of all the new languages, Go is probably the most Python-ic — or at least the general-purpose new languages. There's also Julia, which is sort of an interesting sort of take on something Python-like. It has enough details that look very similar to Python that then when you realize, 'Oh, but all the indexing is one-based and ranges are inclusive instead of exclusive,' you think, 'Argh!' Nobody should ever try to code in Julia and in Python on the same day.
  
  "My understanding is that Julia is sort of much more of a niche language, and if you're in that niche, it is superior because the compiler optimizes your code for you in a way that Python probably never will. On the other hand, it is much more limited in other areas, and I wouldn't expect that anybody ever is going to write a web server in Julia and get a lot of mileage out of it. And I'm sure in five minutes that will be on Hacker News with a counterexample."

• TypeScript: "TypeScript is a great language. You might have noticed that in the past six or seven years, we've been adding optional static typing to Python, also known as gradual typing. I wasn't actually aware of TypeScript when we started that project, so I can't say that we were inspired by TypeScript initially. TypeScript, because it sort of jumped on the JavaScript bandwagon — and because Anders is a really smart guy — TypeScript did a few things that Python is still waiting to figure out. So nowadays, we definitely look at TypeScript for examples. We have a typing SIG where we discuss extensions of the typing syntax and semantics and the type system in general for Python, and we definitely sometimes propose new features because we know that certain features were also originally initially lacking in TypeScript, and then added to TypeScript based on user demand, and [became] very successful in TypeScript. And so now we can see we are in that same situation.
  
  "Because JavaScript and Python are relatively similar... Much more so than Python and say C++ or Rust or Java. So we are learning from TypeScript, and occasionally, from my conversations with Anders, it sounds like TypeScript is also learning from Python, just like JavaScript has learned from Python in a few areas."

An anonymous reader quotes a report from Ars Technica: Seagate has been working on dual-actuator hard drives -- drives with two independently controlled sets of read/write heads -- for several years. Its first production dual-actuator drive, the Mach.2, is now "available to select customers," meaning that enterprises can buy it directly from Seagate, but end-users are out of luck for now. Seagate lists the sustained, sequential transfer rate of the Mach.2 as up to 524MBps -- easily double that of a fast "normal" rust disk and edging into SATA SSD territory. The performance gains extend into random I/O territory as well, with 304 IOPS read / 384 IOPS write and only 4.16 ms average latency. (Normal hard drives tend to be 100/150 IOPS and about the same average latency.)

The added performance requires additional power; Mach.2 drives are rated for 7.2 W idle, while Seagate's standard Ironwolf line is rated at 5 W idle. It gets more difficult to compare loaded power consumption because Seagate specs the Mach.2 differently than the Ironwolf. The Mach.2's power consumption is explicitly rated for several random I/O scenarios, while the Ironwolf line is rated for an unhelpful "average operating power," which isn't defined in the data sheet. Still, if we assume -- probably not unreasonably -- a similar expansion of power consumption while under load, the Mach.2 represents an excellent choice for power efficiency since it offers roughly 200% of the performance of competing traditional drives at roughly 144% of the power budget. Particularly power-conscious users can also use Seagate's PowerBalance mode -- although that feature decreases sequential performance by 50% and random performance by 10%.

This week Linus Torvalds continued a long email interview with Jeremy Andrews, founding partner/CEO of Tag1 (a global technology consulting firm and the second all-time leading contributor to Drupal). In the first part Torvalds had discussed everything from Apple's ARM64 chips and Rust drivers, to his own Fedora-based home work environment — and reflections on the early days of Linux.

But the second part offers some deeper insight into the way Torvalds thinks, some personal insight, what he'd share with other project maintainers — and some thoughts on getting corporations to contribute to open source development: While open source has been hugely successful, many of the biggest users, for example corporations, do nothing or little to support or contribute back to the very open source projects they rely on. Even developers of surprisingly large and successful projects (if measured by number of users) can be lucky to earn enough to buy coffee for the week. Do you think this is something that can be solved? Is the open source model sustainable?

Linus Torvalds: I really don't have an answer to this, and for some reason the kernel has always avoided the problem. Yes, there are companies that are pure "users" of Linux, but they still end up wanting support, so they then rely on contractors or Linux distributions, and those obviously then end up as one of the big sources of kernel developer jobs.

And a fair number of big tech companies that use the kernel end up actively participating in the development process. Sometimes they end up doing a lot of internal work and not being great at feeding things back upstream (I won't name names, and some of them really are trying to do better), but it's actually very encouraging how many big companies are very openly involved with upstream kernel development, and are major parts of the community.

So for some reason, the kernel development community has been pretty successful about integrating with all the commercial interests. Of course, some of that has been very much conscious: Linux has very much always been open to commercial users, and I very consciously avoided the whole anti-corporate mindset that you can most definitely find in some of the "Free Software" groups. I think the GPLv2 is a great license, but at the same time I've been very much against some of the more extreme forms of "Free Software", and I — and Linux — was very much part of the whole rebranding to use "Open Source".

Because frankly, some of the almost religious overtones of rms and the FSF were just nutty, and a certain portion of the community was actively driving commercial use away.

And I say that as somebody who has always been wary of being too tainted by commercial interests... I do think that some projects may have shot themselves in the foot by being a bit too anti-commercial, and made it really hard for companies to participate...

But is it sustainable? Yes. I'm personally 100% convinced that not only is open source sustainable, but for complex technical issues you really need open source simply because the problem space ends up being too complex to manage inside one single company. Even a big and competent tech company.

But it does require a certain openness on both sides. Not all companies will be good partners, and some developers don't necessarily want to work with big companies.
In the interview Torvalds also thanks the generous education system in Finland, and describes what it was like moving from Finland to America. And as for how long he'll continue working on Linux, Torvalds says, "I do enjoy what I do, and as long as I feel I'm actually helping the project, I'll be around...

"in the end, I really enjoy what I do. I'd be bored to tears without kernel development."

Analyst firm SlashData surveyed over 19,000 respondents from 155 countries for its "State of the Developer Nation" survey — and now estimates that there's 24.3 million active developers worldwide.

TechRadar reports: The report pegs JavaScript as the most popular language that, together with variants including TypeScript and CoffeeScript, is used by almost 14 million developers around the world. Based on SlashData's observations over the past several years, more than 4.5 million JavaScript developers have joined the ranks between Q4 2017 and Q1 2021. This is the highest growth in terms of absolute numbers across all programming languages...

Next up is Python with just over 10 million users, followed by Java with 9.4 million, and C/C++ with 7.3 million. The report notes that Python added 1.6 million new developers in the past year, recording a growth rate of 20%.
From ZDNet: SlashData estimates the next three largest developer communities are using C/C++ (7.3 million), Microsoft's C# (6.5 million), and PHP (6.3 million). Other large groups of developers are fans of Kotlin, Swift, Go, Ruby, Objective C, Rust and Lua...

SlashData, however, notes that Rust and Lua were the two fastest growing programming language communities in the past 12 months, albeit from a lower base than Python.
And Visual Studio magazine couldn't resist emphasizing that C# "has ticked up a notch in popularity, overtaking PHP for No. 5 on that ranking..." "C# lost three places in the rankings of language communities between Q3 2019 and Q3 2020, but it regained its lead over PHP in the past six months after adding half a million developers," the report states... "C# is traditionally popular within the desktop developer community, but it's also the most broadly used language among AR/VR and game developers, largely due to the widespread adoption of the Unity game engine in these areas..."

It was a different story one year ago, when the 18th edition of the report said: "C# lost about 1M developers during 2019... [I]t seems to be losing its edge in desktop development — possibly due to the emergence of cross-platform tools based on web technologies."

The language might see more desktop development inroads as new initiatives from Microsoft such as Blazor Desktop (one of those "cross-platform tools based on web technologies") and .NET MAUI provide a wide array of desktop approaches.

Linus Torvalds gave a long new email interview to Jeremy Andrews, founding partner/CEO of Tag1 (a global technology consulting firm and the second all-time leading contributor to Drupal). Torvalds discusses everything from the creation of Git, licenses, Apple's ARM64 chips, and Rust drivers, to his own Fedora-based home work environment — and how proud he is of the pathname lookup in Linux's virtual filesystem. ("Nothing else out there comes even close.")

But with all that, early on Torvalds also reflects that Linux began as a personal project at the age of 21, "not out of some big dream to create a new operating system." Instead it "literally grew kind of haphazardly from me initially just trying to learn the in-and-outs of my new PC hardware.

"So when I released the very first version, it was really more of a 'look at what I did', and sure, I was hoping that others would find it interesting, but it wasn't a real serious and usable OS. It was more of a proof of concept, and just a personal project I had worked on for several months at that time..."

This year, in August, Linux will celebrate its 30th anniversary! That's amazing, congratulations! At what point during this journey did you realize what you'd done, that Linux was so much more than "just a hobby"?

Linus Torvalds: This may sound a bit ridiculous, but that actually happened very early. Already by late '91 (and certainly by early '92) Linux had already become much bigger than I had expected.

And yeah, considering that by that point, there were probably just a few hundred users (and even "users" may be too strong — people were tinkering with it), it probably sounds odd considering how Linux then later ended up growing much bigger. But in many ways for me personally, the big inflection point was when I realized that other people are actually using it, and interested in it, and it started to have a life of its own. People started sending patches, and the system was actually starting to do much more than I had initially really envisioned....

That "anybody can maintain their own version" worried some people about the GPLv2, but I really think it's a strength, not a weakness. Somewhat unintuitively, I think it's actually what has caused Linux to avoid fragmenting: everybody can make their own fork of the project, and that's OK. In fact, that was one of the core design principles of "Git" — every clone of the repository is its own little fork, and people (and companies) forking off their own version is how all development really gets done.

So forking isn't a problem, as long as you can then merge back the good parts. And that's where the GPLv2 comes in. The right to fork and do your own thing is important, but the other side of the coin is equally important — the right to then always join back together when a fork was shown to be successful...

I very much don't regret the choice of license, because I really do think the GPLv2 is a huge part of why Linux has been successful.

Money really isn't that great of a motivator. It doesn't pull people together. Having a common project, and really feeling that you really can be a full partner in that project, that motivates people, I think.

Facebook has joined the Rust Foundation, the organization driving the Rust programming language, alongside Amazon Web Services, Google, Huawei, Microsoft, and Mozilla. From a report: Facebook is the latest tech giant to ramp up its adoption of Rust, a language initially developed by Mozilla that's become popular for systems programming because of its memory safety guarantees compared to fast languages C and C++. Rust is appealing for writing components like drivers and compilers.

The Rust Foundation was established in February with initial backing from Amazon Web Services, Google, Huawei, Microsoft, and Mozilla. Microsoft is exploring Rust for some components of Windows and Azure while Google is using Rust to build new parts of the Android operating system and supporting an effort to bring Rust to the Linux kernel. Facebook's engineering team has now detailed its use of Rust beginning in 2016, a year after Rust reached its 1.0 milestone. "For developers, Rust offers the performance of older languages like C++ with a heavier focus on code safety. Today, there are hundreds of developers at Facebook writing millions of lines of Rust code," Facebook's software engineering team said.

From Mike Melanson's "This Week in Programming" column: "The Rustening at Microsoft has begun," tweeted Microsoft distinguished engineer Miguel de Icaza.

What de Icaza is referring to is a newly-offered course by Microsoft on taking the first steps with Rust, which much of the Twitterverse of Rust devotees sees as a sign that the company is further increasing its favor for their crab-themed language of choice. Of course, this isn't the first we've heard of Microsoft looking to Rust to handle the 70% of Microsoft vulnerabilities that it says come from using the memory-unsafe C++ programming language in its software. A few years back now, Microsoft launched Project Verona, a research programming language that takes a bite from Rust in the realm of ownership and is said to be inspired by Rust, among others.

More recently, however, Microsoft announced the preview of Rust for Windows, which "lets you use any Windows API (past, present, and future) directly and seamlessly via the windows crate (crate is Rust's term for a binary or a library, and/or the source code that builds into one)." With Rust for Windows, developers can now not only use Rust on Windows, they can also write apps for Windows using Rust...

According to the project description, the Windows crate "lets you call any Windows API past, present, and future using code generated on the fly directly from the metadata describing the API and right into your Rust package where you can call them as if they were just another Rust module" and that, along with the introduction of a course for learning Rust, is precisely what has all those Rust devotees so excited.
InfoWorld has more information...

Google's Android team supports Rust for developing the Android operating system. Now they're also helping evaluate Rust for Linux kernel development. Their hopes, among other things, are that "New code written in Rust has a reduced risk of memory safety bugs, data races and logic bugs overall," that "abstractions that are easier to reason about," and "More people get involved overall in developing the kernel, thanks to the usage of a modern language."

Linus Torvalds responded in a new interview with IT Wire (shared by Slashdot reader juul_advocate): The first patches for Rust support in the Linux kernel have been posted and the man behind the kernel says the fact that these are being discussed is much more important than a long post by Google about the language. Linus Torvalds told iTWire in response to queries that Rust support was "not there yet", adding that things were "getting to the point where maybe it might be mergeable for 5.14 or something like that..." Torvalds said that it was still early days for Rust support, "but at least it's in a 'this kind of works, there's an example, we can build on it'."

Asked about a suggestion by a commenter on the Linux Weekly News website, who said, during a discussion on the Google post, "The solution here is simple: just use C++ instead of Rust", Torvalds could not restrain himself from chortling. "LOL," was his response. "C++ solves _none_ of the C issues, and only makes things worse. It really is a crap language.

"For people who don't like C, go to a language that actually offers you something worthwhile. Like languages with memory safety and [which] can avoid some of the dangers of C, or languages that have internal GC [garbage collection] support and make memory management easier. C++ solves all the wrong problems, and anybody who says 'rewrite the kernel in C++' is too ignorant to even know that."

He said that when one spoke of the dangers of C, one was also speaking about part of what made C so powerful, "and allows you to implement all those low-level things efficiently".
Torvalds added that, while garbage collection is "a very good thing in most other situations," it's "generally not necessarily something you can do in a low-level system programming."

For the past few years, Google has been encouraging developers to write Android apps with Kotlin. The underlying OS still uses C and C++, though Google today announced Android Open Source Project (AOSP) support for Rust. From a report: This is part of Google's work to address memory safety bugs in the operating system: "We invest a great deal of effort and resources into detecting, fixing, and mitigating this class of bugs, and these efforts are effective in preventing a large number of bugs from making it into Android releases. Yet in spite of these efforts, memory safety bugs continue to be a top contributor of stability issues, and consistently represent ~70% of Android's high severity security vulnerabilities."

The company believes that memory-safe languages, like Rust, are the "most cost-effective means for preventing memory bugs" in the bootloader, fastboot, kernel, and other low-level parts of the OS. Unlike C and C++, where developers manage memory lifetime, Rust "provides memory safety guarantees by using a combination of compile-time checks to enforce object lifetime/ownership and runtime checks to ensure that memory accesses are valid." Google has been working to add this support to AOSP for the past 18 months. Performance is equivalent to the existing languages, while increasing the effectiveness of current sandboxing and reducing the overall need for it. This allows for "new features that are both safer and lighter on resources." Other improvements include data concurrency, a more expressive type system, and safer integer handling.

Jeffrey Ullman and Alfred Aho developed many of the fundamental concepts that researchers use when they build new software. From a report: When Alfred Aho and Jeffrey Ullman met while waiting in the registration line on their first day of graduate school at Princeton University in 1963, computer science was still a strange new world. Using a computer required a set of esoteric skills typically reserved for trained engineers and mathematicians. But today, thanks in part to the work of Dr. Aho and Dr. Ullman, practically anyone can use a computer and program it to perform new tasks. On Wednesday, the Association for Computing Machinery, the world's largest society of computing professionals, said Dr. Aho and Dr. Ullman would receive this year's Turing Award for their work on the fundamental concepts that underpin computer programming languages. Given since 1966 and often called the Nobel Prize of computing, the Turing Award comes with a $1 million prize, which the two academics and longtime friends will split. Dr. Aho and Dr. Ullman helped refine one of the key components of a computer: the "compiler" that takes in software programs written by humans and turns them into something computers can understand.

Over the past five decades, computer scientists have built increasingly intuitive programming languages, making it easier and easier for people to create software for desktops, laptops, smartphones, cars and even supercomputers. Compilers ensure that these languages are efficiently translated into the ones and zeros that computers understand. Without their work, "we would not be able to write an app for our phones," said Krysta Svore, a researcher at Microsoft who studied with Mr. Aho at Columbia University, where he was chairman of the computer science department. "We would not have the cars we drive these days." The researchers also wrote many textbooks and taught generations of students as they defined how computer software development was different from electrical engineering or mathematics. "Their fingerprints are all over the field," said Graydon Hoare, the creator of a programming language called Rust. He added that two of Dr. Ullman's books were sitting on the shelf beside him. After leaving Princeton, both Dr. Aho, a Canadian by birth who is 79, and Dr. Ullman, a native New Yorker who is 78, joined the New Jersey headquarters of Bell Labs, which was then one of the world's leading research labs.

Sunday IT Wire counted up the number of signatories on two open letters, one opposing Richard Stallman's return to the FSF and one supporting it.

- The pro-Stallman letter had 3,632 individual signers
- The anti-Stallman letter had 2,812 individual signers (plus 48 companies and organizations).

But the question of Stallman's leadership has now also arisen in the GCC community:

A long-time developer of GCC, the compiler created by the GNU Project and used in Linux distributions, has issued a call for the removal of Free Software Founder Richard Stallman from the GCC steering committee. Nathan Sidwell [also a software engineer at Facebook] said in a post directed to the committee that if it was unwilling to remove Stallman, then the panel should explain why it was not able to do so.

Stallman is also the founder of the GNU Project and the original author of GCC.

"RMS [Stallman] is no longer a developer of GCC, the most recent commit I can find regards SCO in 2003," Sidwell wrote in a long email. "Prior to that there were commits in 1997, but significantly less than 1994 and earlier. GCC's implementation language is now C++, which I believe RMS neither uses nor likes.

"When was RMS' most recent positive input to the GCC project? Even if it was recent and significant, that doesn't mean his toxic behaviour should be accepted."
Meanwhile, the following groups have also issued statements opposing Stallman's return to the FSF:

- Mozilla: We can't demand better of the internet if we don't demand better of our leaders, colleagues and ourselves. We're with the Open Source Diversity Community, Outreachy & the Software Conservancy project in supporting this petition.
- The Tor Project: The Tor Project is joining calls for Richard M. Stallman to be removed from board, staff, volunteer, and other leadership positions in the FOSS community, including the Free Software Foundation and the GNU Project.
Rust creator Graydon Hoare: He's been saying sexist shit & driving women away for decades. He can't change, the FSF board knows it, is sending a "sexism doesn't matter" message. This is bad leadership and I'm sad about all of it, agree with calls to resign.

If someone is a public leader their public behaviour matters. I don't criticize private individuals here and I don't think twitter-justice is especially nuanced. But this is so far over the line, such a stupid and tone-deaf choice, and it is about community leadership.
The EFF: We at EFF are profoundly disappointed to hear of the re-election of Richard Stallman to a leadership position at the Free Software Foundation, after a series of serious accusations of misconduct led to his resignation as president and board member of the FSF in 2019. We are also disappointed that this was done despite no discernible steps taken by him to be accountable for, much less make amends for, his past actions or those who have been harmed by them. Finally, we are also disturbed by the secretive process of his re-election, and how it was belatedly conveyed to FSF's staff and supporters.

Stallman's re-election sends a wrong and hurtful message to free software movement, as well as those who have left that movement because of Stallman's previous behavior.

Free software is a vital component of an open and just technological society: its key institutions and individuals cannot place misguided feelings of loyalty above their commitment to that cause. The movement for digital freedom is larger than any one individual contributor, regardless of their role. Indeed, we hope that this moment can be an opportunity to bring in new leaders and new ideas to the free software movement.

We urge the voting members of the FSF1 to call a special meeting to reconsider this decision, and we also call on Stallman to step down: for the benefit of the organization, the values it represents, and the diversity and long-term viability of the free software movement as a whole.
Finally, the Free Software Foundation itself has now pinned the following tweet at the top of its Twitter feed: No LibrePlanet organizers (staff or volunteer), speakers, award winners, exhibitors, or sponsors were made aware of Richard Stallman's announcement until it was public.

An anonymous reader shares an excerpt from a ZDNet article, written by Steven J. Vaughan-Nichols: Linux is the poster-child for the C language. But times change. The Rust language has been slowly gathering support for use as a system language in Linux. For example, at the 2020 Linux Plumbers Conference, developers gave serious thought to using the Rust language for new Linux inline code. So, where is it today? I asked Linux's creator, Linus Torvalds, and the Linux stable kernel maintainer Greg Kroah-Hartman for their thoughts. [...] What does Torvalds make of all this? He's in "the 'wait and see' camp -- I'm interested in the project, but I think it's driven by people who are very excited about Rust, and I want to see how it actually then ends up working in practice." "Personally," Torvalds is "in no way "pushing" for Rust, [but] I'm open to it considering the promised advantages and avoiding some safety pitfalls, but I also know that sometimes promises don't pan out."

Torvalds thinks "Rust's primary first target seems to be drivers, simply because that's where you find just a lot of different possible targets, and you have these individual parts of the kernel that are fairly small and independent. That may not be a very interesting target to some people, but it's the obvious one." Another point is taking on drivers first for "any initial trials to drivers is simply the architecture side," said Torvalds. "Lots of drivers are only relevant on a couple of target architectures, so the whole issue with Rust code not being supported on some architectures is less of an issue." Kroah-Hartman agrees that "drivers are probably the first place for an attempt like this as they are the 'end leafs' of the tree of dependencies in the kernel source. They depend on core kernel functionality, but nothing depends on them."

Torvalds knows some people don't like the idea of Rust in userspace at all. "People complain[ing] about "Rustification" in userspace isn't a great sign for any future kernel use, but hey, we'll see. The kernel is different from userspace projects -- more difficult in some respects (we use a lot of very odd header files that pushes the boundary of what can be called "C"), but easier in many other respects (mainly in the sense that the kernel is fairly self-contained, and then doesn't rely on other projects for the final binary)." From where Kroah-Hartman sits, "it will all come down to how well the interaction between the kernel core structures and lifetime rules that are written in C can be mapped into Rust structures and lifetime rules for drivers in Rust to be able to use them properly. That's going to take a lot of careful work by the developers wanting to hook this all up and I wish them the best of luck."

In his This Week in Programming column, Mike Melanson writes: Rustaceans' dreams of Rust's inclusion in the Linux kernel are one tiny, ever so slight step closer to becoming a reality, with this week's "intentionally bare-bones" inclusion in Linux-next, the development branch of the Linux kernel... Curb your enthusiasm, however, as this remains a rather tentative first step of many necessary steps before Rust fully lands in the Linux kernel.

A rather brief post on LWN.net summarizes where we are rather succinctly:

Followers of the linux-next integration tree may have noticed a significant addition: initial support for writing device drivers in the Rust language. There is some documentation in Documentation/rust, while the code itself is in the rust top-level directory. Appearance in linux-next generally implies readiness for the upcoming merge window, but it is not clear if that is the case here; this code has not seen a lot of wider review yet. It is, regardless, an important step toward the ability to write drivers in a safer language.

Indeed, Miguel Ojeda, a software developer and maintainer of the Rust for Linux project writes that the proposed inclusion "does not mean we will make it into mainline, of course, but it is a nice step to make things as smooth as possible," with some changes expected before any decision as to Rust's inclusion are made.

For those of you less familiar with Rust, part of the appeal here comes with Rust's memory safety features, especially in comparison to C, which the Linux kernel is currently coded in. Part of the problem, however, is that Rust is compiled based on LLVM, as opposed to GCC, and subsequently supports fewer architectures. This is a problem we've seen play out recently, as the Python cryptography library has replaced some old C code with Rust, leading to a situation where certain architectures will not be supported. Presently, the proposal to include Rust in the Linux kernel limits this issue by saying that Rust would be used, at least initially, for writing drivers that, as noted in another LWN.net article on the topic, "would never be used on the more obscure architectures anyway."

RoccamOccam writes: The developers at Discord have seen success with Rust on their video encoding pipeline for Go Live and on their Elixir NIFs' server. Recently, they penned a post explaining how they have drastically improved the performance of a service by switching its implementation from Go to Rust.

From the post, "Remarkably, we had only put very basic thought into optimization as the Rust version was written. Even with just basic optimization, Rust was able to outperform the hyper hand-tuned Go version. This is a huge testament to how easy it is to write efficient programs with Rust compared to the deep dive we had to do with Go."

Ryan Dahl, creator of Node.js and Deno, gave a new interview this week to the IT outsourcing company Evrone: Evrone: You have hands-on experience with lots of programming languages: C, Rust, Ruby, JavaScript, TypeScript. Which one do you enjoy the most to work with?

Ryan: I have the most fun writing Rust these days. It has a steep learning curve and is not appropriate for many problems; but for the stuff I'm working on now it's perfect. It's a much better C++. I'm convinced that I will never start a new C++ project. Rust is beautiful in its ability to express low-level machinery with such simplicity.

JavaScript has never been my favorite language — it's just the most common language — and for that reason it is a useful way to express many ideas. I don't consider TypeScript a separate language; its beauty is that it's just marked up JavaScript. TypeScript allows one to build larger, more robust systems in JavaScript, and I'd say it's my go-to language for small everyday tasks.

With Deno we are trying to remove a lot of the complexity inherent in transpiling TypeScript code down to JavaScript with the hope this will enable more people to utilize it.

Evrone: Gradual typing was successfully added into core Python, PHP, and Ruby. What, in your opinion, is the main showstopper for adding types into JavaScript?

Ryan: Types were added to JavaScript (with TypeScript) far more successfully than has been accomplished in Python, PHP, or Ruby. TypeScript is JavaScript with types. The better question is: what is blocking the JavaScript standardization organization (TC39) from adopting TypeScript? Standardization, by design, moves slowly and carefully. They are first looking into proposing Types-As-Comments, which would allow the JavaScript runtimes to execute TypeScript syntax by ignoring the types. I think eventually TypeScript (or something like it) will be proposed as part of the JavaScript standard, but that will take time.

Evrone: As a respectable VIM user, what do you think of modern programmer editors like Visual Studio Code? Are they good enough for the old guard?

Ryan: Everyone I work with uses vscode and they love it. Probably most people should use that.

I continue to use VIM for two reasons. 1) I'm just very familiar and fast with it, I like being able to work over ssh and tmux and I enjoy the serenity of a full screen terminal. 2) It's important for software infrastructure to be text-based and accessible with simple tools. In the Java world they made the mistake of tying the IDEs too much into the worldflows of the language, creating a situation where practically one was forced to use an IDE to program Java. By using simple tooling myself, I ensure that the software I develop does not become unnecessarily reliant on IDEs. If you use grep instead of jump-to-definition too much indirection becomes intolerable. For what I do, I think this results in better software.

Rust -- the programming language, not the survival game -- now has a new home: the Rust Foundation. From a report: AWS, Huawei, Google, Microsoft and Mozilla banded together to launch this new foundation today and put a two-year commitment to a million-dollar budget behind it. This budget will allow the project to "develop services, programs, and events that will support the Rust project maintainers in building the best possible Rust." Rust started as a side project inside of Mozilla to develop an alternative to C/C++. Designed by Mozilla Research's Graydon Hore, with contributions from the likes of JavaScript creator Brendan Eich, Rust became the core language for some of the fundamental features of the Firefox browser and its Gecko engine, as well as Mozilla's Servo engine. Today, Rust is the most-loved language among developers. But with Mozilla's layoffs in recent months, many on the Rust team lost jobs and the future of the language became unclear without a main sponsor, though the project itself has thousands of contributors and a lot of corporate users, so the language itself wasn't going anywhere.