Researchers from Inria and Microsoft have developed a system to automatically convert specific types of C programming code into memory-safe Rust code, addressing growing cybersecurity concerns about memory vulnerabilities in software systems.

The technique, detailed in a new paper, requires programmers to use a restricted version of C called "Mini-C" that excludes features like pointer arithmetic. The researchers successfully tested their conversion system on two major code libraries, including the 80,000-line HACL* cryptographic library. Parts of the converted code have already been integrated into Mozilla's NSS and OpenSSH security systems, according to the researchers. Memory safety errors account for 76% of Android vulnerabilities in 2019.

Software development is entering an "autopilot era" with AI coding assistants, but the industry needs to prepare for full autonomy, argues former Salesforce co-CEO Bret Taylor. Drawing parallels with self-driving cars, he suggests the role of software engineers will evolve from code authors to operators of code-generating machines. Taylor, a board member of OpenAI and who once rewrote Google Maps over a weekend, calls for new programming systems, languages, and verification methods to ensure AI-generated code remains robust and secure. From his post: In the Autonomous Era of software engineering, the role of a software engineer will likely transform from being the author of computer code to being the operator of a code generating machine. What is a computer programming system built natively for that workflow?

If generating code is no longer a limiting factor, what types of programming languages should we build?

If a computer is generating most code, how do we make it easy for a software engineer to verify it does what they intend? What is the role of programming language design (e.g., what Rust did for memory safety)? What is the role of formal verification? What is the role of tests, CI/CD, and development workflows?

Today, a software engineer's primary desktop is their editor. What is the Mission Control for a software engineer in the era of autonomous development?

Berlin-based T2 Linux developer René Rebe is also long-time Slashdot reader ReneR — and popped by with a special announcement for the holidays: The T2 Linux team has unveiled T2 Linux SDE 24.12, codenamed "Sky's the Limit!", delivering a massive update for this highly portable source-based Linux distribution... With 3,280 package updates, 206 new features, and the ability to boot on systems with as little as 512MB RAM, this release further strengthens T2 Linux's position as the ultimate tool for developers working across diverse hardware and embedded systems.
Some highlights from Rene's announcement:

• "The release includes 37 pre-compiled ISOs with Glibc, Musl, and uClibc, supporting 25 CPU architectures like ARM(64), RISCV(64), Loongarch64, SPARC(64), and vintage retro computing platforms such as M68k, Alpha, and even initial Nintendo Wii U support added."

• " The Cosmic Desktop, a modern Rust-based environment, debuts alongside expanded application support for non-mainstream RISC architectures, now featuring LibreOffice, OpenJDK, and QEMU."

And T2sde.org gives this glimpse of the future:

"While initially created for the Linux kernel, T2 already has proof-of-concept support for building 'home-brew' pkg for Other OS, including: BSDs, macOS and Haiku. Work on alternative micro kernels, such as L4, Fuchsia, RedoxOS or integrating building 'AOSP' Android is being worked on as well."

"The Rust Foundation is dedicated to ensuring a healthy Rust ecosystem," according to a new announcement today, " which depends on a growing pool of well-trained developers to thrive." The latest SlashData Developer Nation survey found Rust to be the fastest-growing programming language, doubling its users over the past two years. As Rust's adoption continues to accelerate, the demand for a multifaceted ecosystem of quality training will too.
Their blog post highlights three examples of the Rust community "creating new pathways for learning Rust" and "addressing the critical need for Rust training in academic settings..." Rust-Edu operates as a non-profit through Portland State University, with funding from Futurewei. Their mission is to "spread Rust use and development through academic curricula and communities throughout the world, making Rust the language of choice for 'systems programming' in its broadest sense through shared efforts of faculty, students and the Rust community." They focus on three main areas: curriculum development, educational tools, and language improvements...

teach-rs, pronounced "teachers," is a modular and reusable university course designed for in-person teaching in Rust. Its mission is to introduce Rust in higher education and ensure that more students enter the job market with considerable Rust experience. The teach-rs project provides ready-to-use Rust teaching materials, including slide decks and exercises that can be adapted to various teaching contexts... As an open source permissively licensed project, teach-rs enables educators to share and improve resources, making introducing Rust instruction into their programs more accessible. Many institutions now use teach-rs in their courses, including the Slovak University of Technology, RustIEC (a collaboration between Vrije Universiteit Brussel and KU Leuven), and the University Politehnica of Bucharest. At the time of this writing, teach-rs has nearly 3000 stars on GitHub...

Under the guidance of The Rust Foundation's Global Rust Coordinator and Rust Nation UK's organizer Ernest Kissiedu, Mordecai Etukudo (Mart) has developed a guide to help educational institutions adopt Rust in their systems. This resource walks organizations through the entire implementation process, from initial assessment to community engagement.

Greg Kroah-Hartman noted some coming changes in Linux 6.13 will make it possible to create "way more" Rust-based kernel drivers. "The veteran kernel developer believes we're at a tipping point of seeing more upstream Rust drivers ahead," reports Phoronix: These Rust char/misc changes are on top of the main Rust pull for Linux 6.13 that brought 3k lines of code for providing more Rust infrastructure. Linux 6.13 separately is also bringing Rust file abstractions.
"Sorry for doing this at the end of the merge window," Greg Kroah-Hartman wrote in the pull request, explaining that "conference and holiday travel got in the way on my side (hence the 5am pull request emails...)" Loads of things in here...

— Rust misc driver bindings and other rust changes to make misc drivers actually possible. I think this is the tipping point, expect to see way more rust drivers going forward now that these bindings are present.

Next merge window hopefully we will have pci and platform drivers working, which will fully enable almost all driver subsystems to start accepting (or at least getting) rust drivers. This is the end result of a lot of work from a lot of people, congrats to all of them for getting this far, you've proved many of us wrong in the best way possible, working code :)

The Rust community has "recognized the unsafety of Rust (if used incorrectly)," according to a blog post by Amazon Web Services.

So now AWS and the Rust Foundation are "crowdsourcing an effort to verify the Rust standard library," according to an article at DevClass.com, "by setting out a series of challenges for devs and offering financial rewards for solutions..." Rust includes ways to bypass its safety guarantees though, with the use of the "unsafe" keyword... The issue AWS highlights is that even if developers use only safe code, most applications still depend on the Rust standard library. AWS states that there are approximately 7.5K unsafe functions in the Rust Standard Library and notes that 57 "soundness issues" and 20 CVEs (Common Vulnerabilities and Exposures) have been reported in the last three years. [28% of the soundness issues were discovered in 2024.]

Marking a function as unsafe does not mean it is vulnerable, only that Rust does not guarantee its safety. AWS plans to reduce the risk by using tools and techniques for formal verification of key library code, but believes that "a single team would be unable to make significant inroads" for reasons including the lack of a verification mechanism in the Rust ecosystem and what it calls the "unknowns of scalable verification." The plan therefore is to turn this over to the community, by posing challenges and rewarding developers for solutions.... A GitHub repository provides a fork of the Rust code and includes a set of challenges, currently 13 of them... The Rust Foundation says that there is a financial reward tied to each challenge, and that the "challenge rewards committee is responsible for reviewing activity and dispensing rewards." How much will be paid though is not stated.

Despite the wide admiration for Rust, there is no formal specification for the language, an issue which impacts formal verification efforts.
Thanks to Slashdot reader sean-it-all for sharing the news.

The goal? "Make C++ and Rust interoperability easily accessible and approachable to the widest possible audience." And the Rust Foundation's "Interop Initiative" is specifically focused on the goal of interoperability "within the same executable," through either inline embedding that allows "integrated compilation", or foreign function interfaces.

To that end, a statement addressing "the challenges and opportunities in C++ and Rust interoperability" was announced this week by the Rust Foundation. Pointing out that the "Interop Initiative" was launched in February 2024 with a $1M contribution from Google, it now "proposes a collaborative, problem-space approach engaging key stakeholders from both language communities.

"Rather than prescribing specific solutions, this problem statement serves as a foundation for community input and participation in shaping both the strategic direction and tactical implementation of improved C++/Rust interoperability."

Their official problem statement outlines three "key strategic approaches."

- Improve existing tools and address tactical issues to reduce interoperability friction and risk in the short term.

- Build consensus around long-term goals requiring changes to Rust itself and develop the tactical approaches to begin pursuing them.

- Engage with the C++ community and committee to improve the quality of interoperation for both languages to help realize the mutual goals of safety and performance.

And it argues that interoperability "is essential to pursuing safety and performance which is maintainable and scalable." A significant amount of development has gone into libraries to facilitate interoperability with both C and C++, but from the language and compiler level, the situation remains largely unchanged from the early days of Rust. As the desire to integrate Rust into more C++ codebases increases, the value of making C++/Rust interoperability safer, easier, and more efficient is rapidly increasing. While each language takes a different overall approach, both view safety as an essential concern in modern systems. Both Rust and C++ have language- and standard-library-level facilities to improve safety in seemingly compatible ways, but significant benefits are lost when transiting the foreign function interfaces (FFI) boundary using the C ABI...

The consequence of this increased cost to interoperate means both C++ and Rust codebases are less able to access valuable code that already exists in the other language, and the ability to transition system components from one language to another is reduced outside of existing C-like interface boundaries. Ultimately, this reduction in freedom leads to worse outcomes for all users since technologists are less free to choose the most effective solutions.

The Tiobe index tries to track the popularity of programming languages by counting the number of search results for the language's name followed by the word "programming" (on 25 different search engines). And this month there were some surprises...

By TIOBE's reckoning, compared to a year ago PHP has now fallen from #7 to #12, while Delphi/Object Pascal shot up five spots from #16 to #11. In that same year, Fortran jumped from #12 to #8 — while both Visual Basic and SQL dropped down a single rank. Toward the top of the list, C actually fell from the #2 spot over the last 12 months to the #4 spot.

And Go just reached the #7 rank on the TIOBE's ranking of programming language popularity — "an all time high for Go," according to TIOBE CEO Paul Jansen. In this month's note, he explains what he thinks is unusual about this — starting by saying that Go programs are both fast, and easy in many ways — easy to deploy, easy to learn, and easy to understand. Python for instance is easy to learn but not fast, and deployment for larger Python programs is fragile due to dependencies on all kind of versioned libraries in the environment.

If compared to Rust for instance (another contender for a top position), Go is a tiny bit slower, but the Go programs are much easier to understand. The next hurdle for Go in the TIOBE index is JavaScript at position #6. That will be a tough one to pass. JavaScript is ubiquitous in software development, although for larger JavaScript systems we see a shift to TypeScript nowadays.
"If annual trends continue this way, Go will bypass JavaScript within 3 years," TIOBE's CEO predicts. (Adding "Let's see what the future has in store for Go...") Although the Go team actually has specific plans for the future, according to a blog post this week celebrating Go's 15th anniversary: We're working on making Go better for AI — and AI better for Go — by enhancing Go's capabilities in AI infrastructure, applications, and developer assistance. Go is a great language for building production systems, and we want it to be a great language for building production AI systems, too... For AI applications, we will continue building out first-class support for Go in popular AI SDKs, including LangChainGo and Genkit. And from its very beginning, Go aimed to improve the end-to-end software engineering process, so naturally we're looking at bringing the latest tools and techniques from AI to bear on reducing developer toil, leaving more time for the fun stuff — like actually programming!
TIOBE's top 10 programming language rankings for the month of November:

1. Python
2. C++
3. Java
4. C
5. C#
6. JavaScript
7. Go
8. Fortran
9. Visual Basic
10. SQL

Nathan Sobo "joined GitHub in late 2011 to build the Atom text editor," according to an online biography, "and he led the Atom team until 2018." Max Brunsfeld joined the Atom team in 2013, and "While driving Atom towards its 1.0 launch during the day, Max spent nights and weekends building Tree-sitter, a blazing-fast and expressive incremental parsing framework that currently powers all code analysis at GitHub."

Last year they teamed up with Antonio Scandurra (another Atom alumnus) to launch a new startup called Zed (which in 2023 raised $10 million, according to TechCrunch). And today the open source blog It's FOSS checks in on their open-source code editor — "Zed Editor". Mainly written in Rust, it supports running in CLI, diagnosing project-wide errors, split panes, and markdown previews: By default, any added content is treated as plain text. I used the language switcher to change it to Rust so that I would get proper syntax highlighting, indentation, error detection, and other useful language-specific functions. The switch highlighted all the Rust elements correctly, and I then focused on Zed Editor's user interface. The overall feel of the editor was minimal, with all the important options being laid out nicely.

[Its status bar] had some interesting panels. The first one I checked was the Terminal Panel, which, as the name suggests, lets you run commands, scripts, and facilitates interaction with system files or processes directly from within the editor. I then moved to the Assistant Panel, which is home to various large language models that can be integrated into Zed Editor. There are options like Anthropic, GitHub Copilot Chat, Ollama, OpenAI, and Google AI... The Zed Editor team has also recently introduced Zed AI in collaboration with Anthropic for assisting with coding, allowing for code generation, advanced context-powered interactions, and more...

The real-time collaboration features on Zed Editor are quite appealing too. To check them out, I had to log in with my GitHub account. After logging in, the Collab Panel opened up, and I could see many channels from the official Zed community. I could chat with others, add collaborators to existing projects, join a call with the option to share my screen and track other collaborators' cursors, add new contacts, and carry out many other collaborative tasks.

One can also use extensions and themes to extend what Zed Editor can do. There are some nice pre-installed themes as well.

"The Rust trademark policy has been updated and a new draft is available to view," announced the Rust Foundation this week.

The last proposed trademark policy (in April of 2023) was criticized by open source advocate Bruce Perens in The Register as "far awry of fair use which is legally permitted." The Rust Foundation says this new version has "incorporated a number of suggestions from the Rust community," in a blog post that summarizes the feedback and enumerates specific ways it's been addressed: 1. We primarily plan to lean on community reports for enforcement and have no intention of spending our limited resources policing the work of small creators.

2. We have removed the non-legal language summary and instead have clarified wording throughout as best we can while keeping the policy valid.

3. The Rust trademark does not cover use of the word "Rust" in general and instead pertains to its use in relevant technical settings.

4. We have updated the logo usage policy. Color modifications are allowed.

5. The non-endorsement rule is about managing perception of official affiliation with the Foundation and Rust Project, and is thus subjective.

6. We removed restrictions on the use of "Rust" and "Cargo" in package names. The crates prefixes "rust-" and "cargo-" are no longer reserved to the Rust Project.

7. We will usually allow the community to use the marks on limited merchandise (more details in the updated draft)....

[T]he central purpose of these updates is to empower all Rustaceans to engage with the Rust language ecosystem more confidently. As a final step in this process, we invite you to review the updated policy and share any blocking concerns you might have... Thank you to everyone who weighed in with helpful suggestions on the initial trademark policy draft we shared. The level of engagement and passion within the Rust community is inspiring to all of us at the Rust Foundation.
The tech news site Heise Online writes "It is noticeable that the language is much clearer and dispenses with a lot of legal jargon," in a piece which argues the new draft "should calm the waves and create clarity." The new draft is not only formulated more simply, but is also significantly shorter. Some restrictions have been softened in the new rules or have disappeared completely...

Meanwhile, the Foundation has also adapted its logo so that it is clear which logo stands for the programming language and which for the Foundation. The use of the name Rust is explicitly permitted to identify projects that are either written in the programming language or are compatible with it...

Before the new trademark rules come into force, the Rust Foundation is collecting feedback on the current draft. The web form is open until November 20, 2024.

GitHub released its annual "State of the Octoverse" report this week. And while "Systems programming languages, like Rust, are also on the rise... Python, JavaScript, TypeScript, and Java remain the most widely used languages on GitHub."

In fact, "In 2024, Python overtook JavaScript as the most popular language on GitHub." They also report usage of Jupyter Notebooks "skyrocketed" with a 92% jump in usage, which along with Python's rise seems to underscore "the surge in data science and machine learning on GitHub..." We're also seeing increased interest in AI agents and smaller models that require less computational power, reflecting a shift across the industry as more people focus on new use cases for AI... While the United States leads in contributions to generative AI projects on GitHub, we see more absolute activity outside the United States. In 2024, there was a 59% surge in the number of contributions to generative AI projects on GitHub and a 98% increase in the number of projects overall — and many of those contributions came from places like India, Germany, Japan, and Singapore...

Notable growth is occurring in India, which is expected to have the world's largest developer population on GitHub by 2028, as well as across Africa and Latin America... [W]e have seen greater growth outside the United States every year since 2013 — and that trend has sped up over the past few years.
Last year they'd projected India would have the most developers on GitHub #1 by 2027, but now believe it will happen a year later. This year's top 10?

1. United States
2. India
3. China
4. Brazil
5. United Kingdom
6. Russia
7. Germany
8. Indonesia
9. Japan
10. Canada

Interestingly, the UK's population ranks #21 among countries of the world, while Germany ranks #19, and Canada ranks #36.)

GitHub's announcement argues the rise of non-English, high-population regions "is notable given that it is happening at the same time as the proliferation of generative AI tools, which are increasingly enabling developers to engage with code in their natural language." And they offer one more data point: GitHub's For Good First Issue is a curated list of Digital Public Goods that need contributors, connecting those projects with people who want to address a societal challenge and promote sustainable development...

Significantly, 34% of contributors to the top 10 For Good Issue projects... made their first contribution after signing up for GitHub Copilot.
There's now 518 million projects on GitHub — with a year-over-year growth of 25%...

This week's Ubuntu Summit 2024 was attended by Lproven (Slashdot reader #6,030). He's also a FOSS correspondent for the Register, where he's filed this report: One of the first full-length sessions was presented by David Morin, executive director of the Academy Software Foundation, introducing his organization in a talk about Open Source Software for Motion Pictures. Morin linked to the Visual Effects Society's VFX/Animation Studio Workstation Linux Report, highlighting the market share pie-chart, showing Rocky Linux 9 with at some 58 percent and the RHELatives in general at 90 percent of the market. Ubuntu 22 and 24 — the report's nomenclature, not this vulture's — got just 10.5 percent. We certainly didn't expect to see that at an Ubuntu event, with the latest two versions of Rocky Linux taking 80 percent of the studio workstation market...

What also struck us over the next three quarters of an hour is that Linux and open source in general seem to be huge components of the movie special effects industry — to an extent that we had not previously realized.
There's a "sizzle reel" showing examples of how major motion pictures used OpenColorIO, an open-source production tool for syncing color representations originally developed by Sony Pictures Imageworks. That tool is hosted by a collaboration between the Linux Foundation with the Science and Technology Council of the Academy of Motion Picture Arts and Sciences (the "Academy" of the Academy Awards). The collaboration — which goes by the name of the Academy Software Foundation — hosts 14 different projects The ASWF hasn't been around all that long — it was only founded in 2018. Despite the impact of the COVID pandemic, by 2022 it had achieved enough to fill a 45-page history called Open Source in Entertainment [PDF]. Morin told the crowd that it runs events, provides project marketing and infrastructure, as well as funding, training and education, and legal assistance. It tries to facilitate industry standards and does open source evangelism in the industry. An impressive list of members — with 17 Premier companies, 16 General ones, and another half a dozen Associate members — shows where some of the money comes from. It's a big list of big names. [Adobe, AMD, AWS, Autodesk...]
The presentation started with OpenVBD, a C++ library developed and donated by Dreamworks for working with three-dimensional voxel-based shapes. (In 2020 they created this sizzle reel, but this year they've unveiled a theme song.) Also featured was OpenEXR, originally developed at Industrial Light and Magic and sourced in 1999. (The article calls it "a specification and reference implementation of the EXR file format — a losslessly compressed image storage format for moving images at the highest possible dynamic range.")

"For an organization that is not one of the better-known ones in the FOSS space, we came away with the impression that the ASWF is busy," the article concludes. (Besides running Open Source Days and ASWF Dev Days, it also hosts several working groups like the Language Interop Project works on Rust bindings and the Continuous Integration Working Group on CI tools, There's generally very little of the old razzle-dazzle in the Linux world, but with the demise of SGI as the primary maker of graphics workstations — its brand now absorbed by Hewlett Packard Enterprise — the visual effects industry moved to Linux and it's doing amazing things with it. And Kubernetes wasn't even mentioned once.

An anonymous reader quotes a report from InfoWorld: Select developers now are getting free access to JetBrains' WebStorm and Rider IDEs. The company on October 24 announced it has launched non-commercial licenses for its WebStorm JavaScript and TypeScript IDE and the Rider cross-platform .NET and game development IDE. As of now, developers using these IDEs for non-commercial purposes, such as open source project development or content creation, can use them for free. JetBrains views the move as expanding the availability of these IDEs to a broader swath of developer roles. More than two-thirds of developers code outside of work as a hobby and nearly 40% code for educational and learning purposes outside of work, the company said."Previously this year, JetBrains released other products under the same terms for non-commercial use, including RustRover, an IDE for Rust development, and Aqua, an IDE designed for test automation," notes InfoWorld. "JetBrains also provides community editions of IntelliJ and PyCharm, IDEs for Java and Python, respectively, which can be used to build proprietary and commercial software."

JetBrains has an FAQ section with additional details about the change.

"After two years of being beaten with the memory-safety stick, the C++ community has published a proposal to help developers write less vulnerable code," reports the Register.

"The Safe C++ Extensions proposal aims to address the vulnerable programming language's Achilles' heel, the challenge of ensuring that code is free of memory safety bugs..." Acknowledging the now deafening chorus of calls to adopt memory safe programming languages, developers Sean Baxter, creator of the Circle compiler, and Christian Mazakas, from the C++ Alliance, argue that while Rust is the only popular systems level programming language without garbage collection that provides rigorous memory safety, migrating C++ code to Rust poses problems. "Rust lacks function overloading, templates, inheritance and exceptions," they explain in the proposal. "C++ lacks traits, relocation and borrow checking. These discrepancies are responsible for an impedance mismatch when interfacing the two languages. Most code generators for inter-language bindings aren't able to represent features of one language in terms of the features of another."

Though DARPA is trying to develop better automated C++ to Rust conversion tools, Baxter and Mazakas argue telling veteran C++ developers to learn Rust isn't an answer... The Safe C++ project adds new technology for ensuring memory safety, Baxter explained, and isn't just a reiteration of best practices. "Safe C++ prevents users from writing unsound code," he said. "This includes compile-time intelligence like borrow checking to prevent use-after-free bugs and initialization analysis for type safety." Baxter said that rewriting a project in a different programming language is costly, so the aim here is to make memory safety more accessible by providing the same soundness guarantees as Rust at a lower cost. "With Safe C++, existing code continues to work as always," he explained. "Stakeholders have more control for incrementally opting in to safety."

The next step, Baxter said, involves greater participation from industry to help realize the Safe C++ project. "The foundations are in: We have fantastic borrow checking and initialization analysis which underpin the soundness guarantees," he said. "The next step is to comprehensively visit all of C++'s features and specify memory-safe versions of them. It's a big effort, but given the importance of reducing C++ security vulnerabilities, it's an effort worth making."

Last month C dropped from 3rd to 4th in TIOBE's ranking of programming language popularity (which tries to calculate each language's share of search engine results). Java moved up into the #3 position in September, reports TechRepublic, which notes that by comparison October "saw relatively little change" — though percentages of search results increased slightly. "At number one, Python jumped from 20.17% in September to 21.9% in October. In second place, C++ rose from 10.75% in September to 11.6%. In third, Java ascended from 9.45% to 10.51%..."

Is there a larger trend? TIOBE CEO Paul Jansen writes that the need to harvest more data increases demand for fast data manipulation languages. But they also need to be easy to learn ("because the resource pool of skilled software engineers is drying up") and secure ("because of continuous cyber threats.") King of all, Python, is easy to learn and secure, but not fast. Hence, engineers are frantically looking for fast alternatives for Python. C++ is an obvious candidate, but it is considered "not secure" because of its explicit memory management. Rust is another candidate, although not easy to learn. Rust is, thanks to its emphasis on security and speed, making its way to the TIOBE index top 10 now. [It's #13 — up from #20 a year ago]

The cry for fast, data crunching languages is also visible elsewhere in the TIOBE index. The language Mojo [a faster superset of Python designed for accelerated hardware like GPUs]... enters the top 50 for the first time. The fact that this language is only 1 year old and already showing up, makes it a very promising language.
In the last 12 months three languages also fell from the top ten:

• PHP (dropping from #8 to #15)

• SQL (dropping from #9 to #11)

• Assembly language (dropping from #10 to #16)

New research suggests that Mars' missing atmosphere may have been absorbed by minerals in the planet's clays, in a process similar to geological reactions on Earth. It may explain Mars' loss of its atmosphere and potential to support life, with methane possibly still present and usable as an energy source. Longtime Slashdot reader Baron_Yam writes: Conditions on early Mars were highly likely to have had CO2 carried down into the ground by water, where reactions with rock resulted in iron oxide (and Mars' rust-red surface) and released hydrogen, which in turn reacted with the water to form methane that was bound in smectite clays. It's all still there, just under the surface. The research has been published in the journal Science Advances.

The JavaScript runtime Bun is a Node.js/Deno alternative (that's also a bundler/test runner/package manager).

And Bun 1.1.28 now includes experimental support for ">compiling and running native C from JavaScript, according to this report from The New Stack: "From compression to cryptography to networking to the web browser you're reading this on, the world runs on C," wrote Jarred Sumner, creator of Bun. "If it's not written in C, it speaks the C ABI (C++, Rust, Zig, etc.) and is available as a C library. C and the C ABI are the past, present, and future of systems programming." This is a low-boilerplate way to use C libraries and system libraries from JavaScript, he said, adding that this feature allows the same project that runs JavaScript to also run C without a separate build step... "It's good for glue code that binds C or C-like libraries to JavaScript. Sometimes, you want to use a C library or system API from JavaScript, and that library was never meant to be used from JavaScript," Sumner added.

It's currently possible to achieve this by compiling to WebAssembly or writing a N-API (napi) addon or V8 C++ API library addon, the team explained. But both are suboptimal... WebAssembly can do this but its isolated memory model comes with serious tradeoffs, the team wrote, including an inability to make system calls and a requirement to clone everything. "Modern processors support about 280 TB of addressable memory (48 bits). WebAssembly is 32-bit and can only access its own memory," Sumner wrote. "That means by default, passing strings and binary data JavaScript WebAssembly must clone every time. For many projects, this negates any performance gain from leveraging WebAssembly."

The latest version of Bun, released Friday, builds on this by adding N-API (nap) support to cc [Bun's C compiler, which uses TinyCC to compile the C code]. "This makes it easier to return JavaScript strings, objects, arrays and other non-primitive values from C code," wrote Sumner. "You can continue to use types like int, float, double to send & receive primitive values from C code, but now you can also use N-API types! Also, this works when using dlopen to load shared libraries with bun:ffi (such as Rust or C++ libraries with C ABI exports)....

"TinyCC compiles to decently performant C, but it won't do advanced optimizations that Clang or GCC does like autovectorization or very specialized CPU instructions," Sumner wrote. "You probably won't get much of a performance gain from micro-optimizing small parts of your codebase through C, but happy to be proven wrong!"

The Rust vs C battle raging in Linux circles has left even Linus Torvalds scratching his head. "I'm not sure why Rust has been such a contentious area," the Linux creator mused at this week's Open Source Summit, likening the fervor to ancient text editor wars. "It reminds me of when I was young and people were arguing about vi versus Emacs."

The spat over integrating Rust into Linux has been brewing since 2022, with critics slamming it as an "insult" to decades of kernel work. One maintainer recently quit, fed up with the "nontechnical nonsense." Torvalds struck a surprisingly diplomatic tone. He praised how Rust has "livened up discussions" while admitting some arguments get "nasty." "C is, in the end, a very simple language," Torvalds said, explaining its appeal and pitfalls. "Because it's simple it's also very easy to make mistakes. And Rust is not." Torvalds remains upbeat about Rust's future in Linux, nonetheless. "Even if it were to become a failure -- and I don't think it will -- that's how you learn," he said.

An anonymous reader quotes a report from ZDNet, written by Steven Vaughan-Nichols: In a candid keynote chat at the Linux Foundation's Open Source Summit Europe, Linux creator Linus Torvalds shared his thoughts on kernel development, the integration of Rust, and the future of open source. Dirk Hohndel, Verizon's Open Source Program Office head and Torvalds friend, moderated their conversation about the Linux ecosystem. Torvalds emphasized that kernel releases, like the recent 6.11 version, are intentionally not exciting. "For almost 15 years, we've had a very good regular cadence of releases," he explained. With releases every nine weeks, this regularity aims for timeliness and reliability rather than flashy new features. The Linux creator noted that while drivers still make up the bulk of changes, core kernel development continues to evolve. "I'm still surprised that we're doing very core development," Torvalds said, mentioning ongoing work in virtual file systems and memory management. [...]

Shifting back to another contentious subject -- maintainer burnout and succession planning -- Hohndel observed that "maintainers are aging. Strangely, some of us have, you know, not quite as much or the right hair color anymore." (Torvalds interjected that "gray is the right color.") Hohndel continued, "So the question that I always ask myself: Is it about time to talk about there being a mini-Linus?" Torvalds turned the question around. True, the Linux maintainers are getting older and people do burn out and go away. "But that's kind of normal. What is not normal is that people actually stay around for decades. That's the unusual thing, and I think that's a good sign." At the same time, Torvalds admitted, it can be intimidating for a younger developer to join the Linux kernel team "when you see all these people who have been around for decades, but at the same time, we have many new developers. Some of those new developers come in, and three years later, they are top maintainers."

Hohndel noted that "to be the king of Linux, the main maintainer, you have to have a lot of experience. And the backup right now is Greg KH (Greg Kroah-Hartman, maintainer of the stable Linux kernel), who is about the same age as we are and has even less hair." True, Torvalds responded, "But the thing is, Greg hasn't always been Greg. Before Greg, there's been Andrew {Morton) and Alan (Cox). After Greg, there will be Shannon and Steve. The real issue is you have to have a person or a group of people that the development community can trust, and part of trust is fundamentally about having been around for long enough that people know how you work, but long enough does not mean to be 30 years." Hohndel made one last comment: "What I'm trying to say is, you've been doing this for 33 years. I don't want to be morbid, but I think in 33 years, you may no longer be doing this?" Torvalds, making motions as though he was using a walker, replied, "I would love to still do this conference with you." The report notes the contention around the integration of Rust, highlighted by the recent departure of Rust for Linux maintainer Wedson Filho. Despite resistance from some devs who prefer C and are skeptical of Rust, Torvalds remains optimistic about Rust's future in the kernel.

He said: "Rust is a very different thing, and there are a lot of people who are used to the C model. They don't like the differences, but that's OK. In the kernel itself, absolutely nobody understands everything. I don't. I rely heavily on maintainers of various subsystems. I think the same can be true of Rust and C. I think it's one of our strengths in the kernel that we can specialize. Clearly, some people just don't like the notion of Rust and having Rust encroach on their area. But we've only been doing Rust for a couple of years, so it's way too early to say Rust is a failure."

Meanwhile, Torvalds confirmed that the long-anticipated real-time Linux (RTLinux) project will finally be integrated into the kernel with the upcoming release of Linux 6.12.

The Rust foundation is making "considerable progress" on a complete security audit of the Rust ecosystem, according to the coding news site I Programmer, citing a newly-released report from the nonprofit Rust foundation: The foundation is investigating the development of a Public Key Infrastructure (PKI) model for the Rust language, including the design and implementation for a PKI CA and a resilient Quorum model for the project to implement, and the report says that language updates suggested by members of the Project were nearly ready for implementation.

Following the XZ backdoor vulnerability, the Security Initiative has focused on supply chain security, including work on provenance-tracking, verifying that a given crate is actually associated with the repository it claims to be. The top 5,000 crates by download count have been checked and verified.

Threat modeling has now been completed on the Crates ecosystem. Rust Infrastructure, crates.io and the Rust Project.

Two open source security tools, Painter and Typomania, have been developed and released. Painter can be used to build a graph database of dependencies and invocations between all crates within the crates.io ecosystem, including the ability to obtain 'unsafe' statistics, better call graph pruning, and FFI boundary mapping. Typomania ports typogard to Rust, and can be used to detect potential typosquatting as a reusable library that can be adapted to any registry.
They've also tightened admin privileges for Rust's package registry, according to the article. And "In addition to the work on the Security Initiative, the Foundation has also been working on improving interoperability between Rust and C++, supported by a $1 million contribution from Google."

According to the Rust foundation's technology director, they've made "impressive technical strides and developed new strategies to reinforce the safety, security, and longevity of the Rust programming language." And the director says the new report "paints a clear picture of the impact of our technical projects like the Security Initiative, Safety-Critical Rust Consortium, infrastructure and crates.io support, Interop Initiative, and much more."