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."

Redmonk's latest programming language ranking (attempting to gauge "potential future adoption trends") has found evidence of "a landscape resistant to change." Outside of CSS moving down a spot and C++ moving up one, the Top 10 was unchanged. And even in the back half of the rankings, where languages tend to be less entrenched and movement is more common, only three languages moved at all... There are a few signs of languages following in TypeScript's footsteps and working their way up the path, both in the Top 20 and at the back end of the Top 100 as we'll discuss shortly, but they're the exception that proves the rule.

It's possible that we'll see more fluid usage of languages, and increased usage of code assistants would theoretically make that much more likely, but at this point it's a fairly static status quo. With that, some results of note:

- TypeScript (#6): technically TypeScript didn't move, as it was ranked sixth in our last run, but this is the first quarter in which is has been the sole occupant of that spot. CSS, in this case, dropped one place to seven leaving TypeScript just outside the Top 5. It will be interesting to see whether or not it has more momentum to expend or whether it's topped out for the time being.

- Kotlin (#14) / Scala (#14): both of these JVM-based languages jumped up a couple of spots — two spots in Scala's case and three for Kotlin. Scala's rise is notable because it had been on something of a downward trajectory from a one time high of 12th, and Kotlin's placement is a mild surprise because it had spent three consecutive runs not budging from 17, only to make the jump now. The tie here, meanwhile, is interesting because Scala's long history gives it an accretive advantage over Kotlin's more recent development, but in any case the combination is evidence of the continued staying power of the JVM.

- Objective C (#17): speaking of downward trajectories and the 17th placement on this list, Objective C's slide that began in mid-2018 continued and left the language with its lowest placement in these rankings to date at #17. That's still an enormously impressive achievement, of course, and there are dozens of languages that would trade their usage for Objective C's, but the direction of travel seems clear.

- Dart (#19) / Rust (#19): while once grouped with Kotlin as up and coming languages driven by differing incentives and trends, Dart and Rust have not been able to match the ascent of their counterpart with five straight quarters of no movement. That's not necessarily a negative; as with Objective C, these are still highly popular languages and communities, but it's worth questioning whether new momentum will arrive and from where, particularly because the communities are experiencing some friction in growing their usage.
It's important to remember Redmonk's methodology. "We extract language rankings from GitHub and Stack Overflow, and combine them for a ranking that attempts to reflect both code (GitHub) and discussion (Stack Overflow) traction. The idea is not to offer a statistically valid representation of current usage, but rather to correlate language discussion and usage in an effort to extract insights into potential future adoption trends."

Having said that, here's the current top ten in Redmonk's ranking:

1. JavaScript
2. Python
3. Java
4. PHP
5. C#
6. TypeScript
7. CSS
8. C++
9. Ruby
10. C

Their announcement also notes that at the other end of the list, the programming language Bicep "jumped eight spots to #78 and Zig 10 to #87. That progress pales next to Ballerina, however, which jumped from #80 to #61 this quarter. The general purpose language from WS02, thus, is added to the list of potential up and comers we're keeping an eye on."

The Register reports that Google "recently rewrote the firmware for protected virtual machines in its Android Virtualization Framework using the Rust programming language." And they add that Google "wants you to do the same, assuming you deal with firmware."

A post on Google's security blog by Android engineers Ivan Lozano and Dominik Maier promises to show "how to gradually introduce Rust into your existing firmware," adding "You'll see how easy it is to boost security with drop-in Rust replacements, and we'll even demonstrate how the Rust toolchain can handle specialized bare-metal targets."

This prompts the Register to quip that easy "is not a term commonly heard with regard to a programming language known for its steep learning curve." Citing the lack of high-level security mechanisms in firmware, which is often written in memory-unsafe languages such as C or C++, Lozano and Maier argue that Rust provides a way to avoid the memory safety bugs like buffer overflows and use-after-free that account for the majority of significant vulnerabilities in large codebases. "Rust provides a memory-safe alternative to C and C++ with comparable performance and code size," they note. "Additionally it supports interoperability with C with no overhead."
At one point the blog post explains that "You can replace existing C functionality by writing a thin Rust shim that translates between an existing Rust API and the C API the codebase expects." But their ultimate motivation is greater security. "Android's use of safe-by-design principles drives our adoption of memory-safe languages like Rust, making exploitation of the OS increasingly difficult with every release."

And the Register also got this quote from Lars Bergstrom, Google's director of engineering for Android Programming Languages (and chair of the Rust Foundation's board of directors). "At Google, we're increasing Rust's use across Android, Chromium, and more to reduce memory safety vulnerabilities. We're dedicated to collaborating with the Rust ecosystem to drive its adoption and provide developers with the resources and training they need to succeed.

"This work on bringing Rust to embedded and firmware addresses another critical part of the stack."

Efforts to add Rust code to the Linux kernel has suffered a setback as one of the maintainers of the Rust for Linux project has stepped down -- citing frustration with "nontechnical nonsense," according to The Register: Wedson Almeida Filho, a software engineer at Microsoft who has overseen the Rust for Linux project, announced his resignation in a message to the Linux kernel development mailing list. "I am retiring from the project," Filho declared. "After almost four years, I find myself lacking the energy and enthusiasm I once had to respond to some of the nontechnical nonsense, so it's best to leave it up to those who still have it in them."

[...] Memory safety bugs are regularly cited as the major source of serious software vulnerabilities by organizations overseeing large projects written in C and C++. So in recent years there's been a concerted push from large developers like Microsoft and Google, as well as from government entities like the US Cybersecurity and Infrastructure Security Agency, to use memory-safe programming languages -- among them Rust. Discussions about adding Rust to Linux date back to 2020 and were realized in late 2022 with the release of Linux 6.1. "I truly believe the future of kernels is with memory-safe languages," Filho's note continued. "I am no visionary but if Linux doesn't internalize this, I'm afraid some other kernel will do to it what it did to Unix."

Pundits aggregate results from multiple pollsters to minimize biases. So ZDNet tried the same approach, but aggregating rankings for the popularity of 19 top programming languages. Senior contributing editor David Gewirtz combined results from nine popularity rankings, including PYPL, the Tiobe index, GitHub's Usage 2023 summary report, and several rankings from Stack Overflow and from IEEE Spectrum.

The results? The top cluster contains Python, JavaScript, and Java. These are all very representative in the world of AI coding...

The next cluster contains the classic C-based languages [C++, C#, C], plus TypeScript (which is a more robust JavaScript variant) and SQL.

Below that are languages that were dominant a while ago, the web languages used to build and operate websites [HTML/CSS, PHP, Shell], followed by a range of other languages that are either growing in popularity (R, Dart) or dropping in popularity (Ruby). [Just above Ruby are Go, Rust, Kotlin, and Lua.]

Finally, at the bottom is Swift, Apple's language of choice. Objective-C, the previous language of Apple programming, has all but dropped off the list since Apple launched Swift. But while Apple boasts many developers, Swift is clearly not a standout in programmer interest... [T]here aren't a huge number of companies hiring Apple app developers, at least primarily. That's why Swift is relatively far down the chart. Objective-C is being replaced by Swift, and we can see it dropping right before our eyes.
"With the exception of Java, the C-family of languages still dominates," the article concludes, before adding that if you're only going to learn one language, "I'd recommend Python, Java, and JavaScript instead." But it also advises aspiring programmers to learn "multiple languages and multiple frameworks. Build things in the languages. Programming is not just an intellectual exercise. You have to actually make stuff....

"[L]earning how to learn languages is as important as learning a language — and the best way to do that is to learn more than one."

New submitter meisdug writes: A new feature has been submitted for inclusion in Linux 6.12, allowing the display of a QR code when a kernel panic occurs using the DRM Panic handler. This QR code can capture detailed error information that is often missed in traditional text-based panic messages, making it more user-friendly. The feature, written in Rust, is optional and can be enabled via a specific build switch. This implementation follows similar ideas from other operating systems and earlier discussions in the Linux community.

"At The Linux Foundation's Open Source Summit China conference, Linus Torvalds and his buddy Dirk Hohndel, Verizon's Head of the Open Source Program Office, once more chatted about Linux development and related issues," reports ZDNet: Torvalds: "Later this year, we will have the 20th anniversary of the real-time Linux project. This is a project that literally started 20 years ago, and the people involved are finally at that point where they feel like it is done... well, almost done. They're still tweaking the last things, but they hope it will soon be ready to be completely merged in the upstream kernel this year... You'd think that all the basics would have been fixed long ago, but they're not. We're still dealing with basic issues such as memory management...."

Switching to a more modern topic, the introduction of the Rust language into Linux, Torvalds is disappointed that its adoption isn't going faster. "I was expecting updates to be faster, but part of the problem is that old-time kernel developers are used to C and don't know Rust. They're not exactly excited about having to learn a new language that is, in some respects, very different. So there's been some pushback on Rust." On top of that, Torvalds commented, "Another reason has been the Rust infrastructure itself has not been super stable...."

The pair then moved on to the hottest of modern tech topics: AI. While Torvalds is skeptical about the current AI hype, he is hopeful that AI tools could eventually aid in code review and bug detection. In the meantime, though, Torvalds is happy about AI's side effects. For example, he said, "When AI came in, it was wonderful, because Nvidia got much more involved in the kernel. Nvidia went from being on my list of companies who are not good to my list of companies who are doing really good work."

Microsoft will meet with CrowdStrike and other security companies" on September 10, reports CNBC, to "discuss ways to evolve" the industry after a faulty CrowdStrike software update in July caused millions of Windows computers to crash: [An anonymous Microsoft executive] said participants at the Windows Endpoint Security Ecosystem Summit will explore the possibility of having applications rely more on a part of Windows called user mode instead of the more privileged kernel mode... Attendees at Microsoft's September 10 event will also discuss the adoption of eBPF technology, which checks if programs will run without triggering system crashes, and memory-safe programming languages such as Rust, the executive said.
Wednesday Crowdstrike argued no cybersecurity vendor could "technically" guarantee their software wouldn't cause a similar incident.

On a possibly related note, long-time Slashdot reader 278MorkandMindy shares their own thoughts: The "year of the Linux desktop" is always just around the corner, somewhat like nuclear fusion. Will Windows 11, with its general advert and telemetry BS, along with the recall feature, FINALLY push "somewhat computer literate" types like myself onto Linux?

Linux creator Linus Torvalds expressed disappointment with the slow adoption of Rust in the Linux kernel at the Linux Foundation's Open Source Summit China. In a conversation with Verizon executive Dirk Hohndel, Torvalds said, "I was expecting updates to be faster, but part of the problem is that old-time kernel developers are used to C and don't know Rust. They're not exactly excited about having to learn a new language that is, in some respects, very different." This resistance has led to "some pushback on Rust," he said. "Another reason has been the Rust infrastructure itself has not been super stable," he added.