A new article from Wired calls Rust "the 'viral' secure programming language that's taking over tech."

"Rust makes it impossible to introduce some of the most common security vulnerabilities. And its adoption can't come soon enough...." [A] growing movement to write software in a language called Rust is gaining momentum because the code is goof-proof in an important way. By design, developers can't accidentally create the most common types of exploitable security vulnerabilities when they're coding in Rust, a distinction that could make a huge difference in the daily patch parade and ultimately the world's baseline cybersecurity....

[B]ecause Rust produces more secure code [than C] and, crucially, doesn't worsen performance to do it, the language has been steadily gaining adherents and now is at a turning point. Microsoft, Google, and Amazon Web Services have all been utilizing Rust since 2019, and the three companies formed the nonprofit Rust Foundation with Mozilla and Huawei in 2020 to sustain and grow the language. And after a couple of years of intensive work, the Linux kernel took its first steps last month to implement Rust support. "It's going viral as a language," says Dave Kleidermacher, vice president of engineering for Android security and privacy. "We've been investing in Rust on Android and across Google, and so many engineers are like, 'How do I start doing this? This is great'...."

By writing new software in Rust instead, even amateur programmers can be confident that they haven't introduced any memory-safety bugs into their code.... These types of vulnerabilities aren't just esoteric software bugs. Research and auditing have repeatedly found that they make up the majority of all software vulnerabilities. So while you can still make mistakes and create security flaws while programming in Rust, the opportunity to eliminate memory-safety vulnerabilities is significant....

"Yes, it's a lot of work, it will be a lot of work, but the tech industry has how many trillions of dollars, plus how many talented programmers? We have the resources," says Josh Aas, executive director of the Internet Security Research Group, which runs the memory-safety initiative Prossimo as well as the free certificate authority Let's Encrypt. "Problems that are merely a lot of work are great."
Here's how Dan Lorenc, CEO of the software supply-chain security company Chainguard, explains it to Wired. "Over the decades that people have been writing code in memory-unsafe languages, we've tried to improve and build better tooling and teach people how to not make these mistakes, but there are just limits to how much telling people to try harder can actually work.

"So you need a new technology that just makes that entire class of vulnerabilities impossible, and that's what Rust is finally bringing to the table."

The newest stable version of Rust, 1.65.0 includes generic associated types (GATs) — the ability to declare lifetime, type, and const generics on associated types. "It's hard to put into few words just how useful these can be," writes the official Rust blog.

An earlier post pointed out that "There have been a good amount of changes that have had to have been made to the compiler to get GATs to work," noting that the request-for-comments for this feature was first opened in 2016.

And Rust's types team also created a blog post with more detail: Note that this is really just rounding out the places where you can put generics: for example, you can already have generics on freestanding type aliases and on functions in traits. Now you can just have generics on type aliases in traits (which we just call associated types)....

In general, GATs provide a foundational basis for a vast range of patterns and APIs. If you really want to get a feel for how many projects have been blocked on GATs being stable, go scroll through either the tracking issue: you will find numerous issues from other projects linking to those threads over the years saying something along the lines of "we want the API to look like X, but for that we need GATs" (or see this comment that has some of these put together already). If you're interested in how GATs enable a library to do zero-copy parsing, resulting in nearly a ten-fold performance increase, you might be interested in checking out a blog post on it by Niko Matsakis.

All in all, even if you won't need to use GATs directly, it's very possible that the libraries you use will use GATs either internally or publically for ergonomics, performance, or just because that's the only way the implementation works.... [A]ll the various people involved in getting this stabilization to happen deserve the utmost thanks. As said before, it's been 6.5 years coming and it couldn't have happened without everyone's support and dedication.
Rust 1.65.0 also contains let-else statements — a new kind of let statement "with a refutable pattern and a diverging else block that executes when that pattern doesn't match," according to the release announcement.

And it highlights another new feature: Plain block expressions can now be labeled as a break target, terminating that block early. This may sound a little like a goto statement, but it's not an arbitrary jump, only from within a block to its end. This was already possible with loop blocks, and you may have seen people write loops that always execute only once, just to get a labeled break.

Now there's a language feature specifically for that! Labeled break may also include an expression value, just as with loops, letting a multi-statement block have an early "return" value.

RedMonk has released its latest quarterly rankings of popular programming languages, arguing that "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."

Their 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." Below are this quarter's results:

1. JavaScript
2. Python
3. Java
4. PHP
5. C#
6. CSS
7. C++
7. TypeScript
9. Ruby
10. C
11. Swift
12. R
12. Objective-C
14. Shell
15. Scala
15. Go
17. PowerShell
17. Kotlin
19. Rust
19. Dart

Their analysis of the latest rankings note "movement is increasingly rare.... the top 20 has been stable for multiple runs. As has been speculated about in this space previously, it seems increasingly clear that the hypothesis of a temporary equilibrium of programming language usage is supported by the evidence.... [W]e may have hit a point of relative — if temporary — contentment with the wide variety of languages available for developers' usage."

And yet this quarter TypeScript has risen from #8 to #7, now tied with C++, benefiting from attributes like its interoperability with an existing popular language with an increased availability of security-related features. "There is little suggestion at present that the language is headed anywhere but up. The only real question is on what timeframe." Unlike TypeScript, Go's trajectory has been anything but clear. While it grew steadily and reasonably swiftly as languages go, it has appeared to be stalled, never placing higher than 14th and having dropped into 16 for the last three runs. This quarter, however, Go rose one spot in the rankings back up to 15. In and of itself, this is a move of limited significance, as the further one goes down the rankings the less significant the differences between them are, ranking-wise. But it has been over a year since we've seen movement from Go, which raises the question of whether there is any room for further upward ascent or whether it will remain hovering in the slot one would expect from a technically well regarded but not particularly versatile (from a use case standpoint) language.

Like Go, Kotlin had spent the last three runs in the same position. It and Rust had been moving in lockstep in recent quarters, but while Rust enters its fourth consecutive run in 19th place, Kotlin managed to achieve some separation this quarter jumping one spot up from 18 to 17.

Canonical blog: Codenamed "Kinetic Kudu," this interim release improves the experience of enterprise developers and IT administrators. It also includes the latest toolchains and applications with a particular focus on the IoT ecosystem. Ubuntu 22.10 delivers toolchain updates to Ruby, Go, GCC and Rust. OpenSSH in Ubuntu 22.10 is configured by default to use systemd socket activation, meaning that sshd will not be started until an incoming connection request is received. This reduces the memory footprint of Ubuntu Server on smaller devices, VMs or LXD containers. Ubuntu 22.10 also comes with a new debuginfod service to help developers and admins debug programs shipped with Ubuntu. Debugging tools like gdb will automatically download the required debug symbols over HTTPS.

Ubuntu 22.10 now supports MicroPython on a variety of microcontrollers, including the Raspberry Pi Pico W. rshell, thonny and mpremote are all available in the Ubuntu repositories. The Ubuntu graphics stack transition to kms means developers can run Pi-based graphical applications using frameworks like Qt outside of a desktop session and without Pi specific drivers. This complements expanded support for a range of embedded displays for the Raspberry Pi, including the Inky eInk HAT series, Hyperpixel range and the Raspberry Pi Official Touchscreen. [...] All users will benefit from the refinements in GNOME 43, including GTK4 theming for improved performance and consistency. Quick Settings now provide faster access to commonly used options such as wifi, bluetooth, dark mode and power settings.

Last Friday, Google announced the release of KataOS, a security-minded operating system focused on embedded devices running ambient machine learning workloads. As Phoronix notes, it uses the Rust programming language and is "built atop the seL4 microkernel as its foundatin." From Google's Open-Source Blog: As the foundation for this new operating system, we chose seL4 as the microkernel because it puts security front and center; it is mathematically proven secure, with guaranteed confidentiality, integrity, and availability. Through the seL4 CAmkES framework, we're also able to provide statically-defined and analyzable system components. KataOS provides a verifiably-secure platform that protects the user's privacy because it is logically impossible for applications to breach the kernel's hardware security protections and the system components are verifiably secure. KataOS is also implemented almost entirely in Rust, which provides a strong starting point for software security, since it eliminates entire classes of bugs, such as off-by-one errors and buffer overflows.

The current GitHub release includes most of the KataOS core pieces, including the frameworks we use for Rust (such as the sel4-sys crate, which provides seL4 syscall APIs), an alternate rootserver written in Rust (needed for dynamic system-wide memory management), and the kernel modifications to seL4 that can reclaim the memory used by the rootserver. KataOS code is being worked on via GitHub under the AmbiML umbrella.

"Starting with the Ubuntu 16.04 edition and including the later LTS versions, Canonical will offer expanded security coverage for critical, high, and medium Common Vulnerabilities and Exposures (CVEs) to all of Ubuntu's open-source applications and toolchains for ten years," reports ZDNet.

"Yes, you read that right, you get security patches not just for the operating system, but for all of Ubuntu's open-source applications for a decade." Most of these are server programs, such as Ansible, Apache Tomcat, Drupal, Nagios, Redis, and WordPress. But, it also includes such developer essentials as Docker, Node.js, phpMyAdmin, Python 2, and Rust. Altogether, Canonical is supporting more than 23,000 packages. Indeed, it's now offering security for, as Mark Shuttleworth, Canonical's CEO, said, "Security coverage to every single package in the Ubuntu distribution."

Canonical isn't doing this on its own. It's offering free, improved security in partnership with the security management company Tenable. Robert Huber, Tenable's Chief Security Officer, said, "Ubuntu Pro offers security patch assurance for a broad spectrum of open-source software. Together, we give customers a foundation for trustworthy open source."

Beyond ordinary security, Canonical is backporting security fixes from newer application versions. This enables Ubuntu Pro users to use the Ubuntu release of their choice for long-term security without forced upgrades. Happy to keep using Ubuntu 20.04? No problem. You can run it until April 2030. Knock yourself out....

Users can obtain a free personal Ubuntu Pro subscription at ubuntu.com/pro for up to five machines. This free tier is for personal and small-scale commercial use.
Mark Shuttleworth, CEO of Ubuntu's parent company company Canonical, explains in a new video that Ubuntu "is now the world's most widely used Linux..."

"What makes most proud, though, is that we have found a way to make this available free of charge to anybody for their personal and for small-scale commercial use.... full commercial use for you, and any business you own, on up to five machines."

"The Rust programming language is getting so popular that the team behind it is creating a team that's dedicated to defining the default Rust coding style," reports ZDNet: Each language has style guides and, if they're popular enough, may have multiple style guides from major users, like Google, which has its guide for C++ — the language Chrome is written in. Python's Guido van Rossum's posted his styling conventions here.

Rust, which reached version 1.0 in 2015, has a style guide in the "rustfmt" or 'Rust formatting tool' published on GitHub. The tool automatically formats Rust code to let developers focus on output and aims to reduce the steep learning curve confronting new Rust developers. The guide instructs developers to "Use spaces, not tabs" and says "each level of indentation must be 4 spaces", for example....

But the team responsible for writing the style guide between 2016 and 2018 has "by design" come to end, so now it's now been decided to create the Rust style team, consisting of Josh Triplett, Caleb Cartwright, Michal Goulet, and Jane Lusby. The crew will first tackle a "backlog of new language constructs that lack formatting guidance" and move on to "defining and implementing the mechanisms to evolve the default Rust style, and then begin introducing style improvements."

The work includes minor language changes, big structural changes, and backwards compatibility and the style team wants to craft the tool to make it current for easier coding in Rust, and help adoption.
New constructs "by default, get ignored and not formatted by rustfmt," according to a blog post by the Rust style team, "and subsequently need formatting added. Some of this work has fallen to the rustfmt team in recent years, but the rustfmt team would prefer to implement style determinations made by another team rather than making such determinations itself."

The post also notes that the backwards compatibility maintained by rustfmt "also prevents evolving the Rust style to take community desires into account and improve formatting over time." rustfmt provides various configuration options to change its default formatting, and many of those options represent changes that many people in the community would like enabled by default... but [rustfmt] cannot make this the default without causing continuous integration failures in existing projects. We need a way to evolve the default Rust style compatibly, similar in spirit to the mechanisms we use for Rust editions: allowing existing style to continue working, and allowing people to opt into new style.

To solve both of these problems, RFC 3309 has revived the Rust style team, with three goals:

- Making determinations about styling for new Rust constructs
- Evolving the existing Rust style
- Defining mechanisms to evolve the Rust style while taking backwards compatibility into account

We don't plan to make any earth-shattering style changes; the look and feel of Rust will remain largely the same. Evolutions to the default Rust style will largely consist of established rustfmt options people already widely enable, or would enable if they were stable. We expect that the initial work of the style team will focus on clearing a backlog of new language constructs that lack formatting guidance. Afterwards, we will look towards defining and implementing the mechanisms to evolve the default Rust style, and then begin introducing style improvements.

"This Monday, the first set of patches to enable Rust support and tooling was merged for Linux 6.1," writes Slashdot reader sabian2008, sharing an update from longtime kernel developer Kees Cook: The tree has a recent base, but has fundamentally been in linux-next for a year and a half. It's been updated based on feedback from the Kernel Maintainer's Summit, and to gain recent Reviewed-by: tags. Miguel is the primary maintainer, with me helping where needed/wanted. Our plan is for the tree to switch to the standard non-rebasing practice once this initial infrastructure series lands. The contents are the absolute minimum to get Rust code building in the kernel, with many more interfaces[2] (and drivers -- NVMe[3], 9p[4], M1 GPU[5]) on the way.

The initial support of Rust-for-Linux comes in roughly 4 areas:
- Kernel internals (kallsyms expansion for Rust symbols, %pA format)
- Kbuild infrastructure (Rust build rules and support scripts)
- Rust crates and bindings for initial minimum viable build
- Rust kernel documentation and samples Further reading: Linux 6.0 Arrives With Support For Newer Chips, Core Fixes, and Oddities

An anonymous reader quotes a report from Ars Technica: A stable version of Linux 6.0 is out, with 15,000 non-merge commits and a notable version number for the kernel. And while major Linux releases only happen when the prior number's dot numbers start looking too big -- there is literally no other reason" -- there are a lot of notable things rolled into this release besides a marking in time. Most notable among them could be a patch that prevents a nearly two-decade slowdown for AMD chips, based on workaround code for power management in the early 2000s that hung around for far too long. [...]

Intel's new Arc GPUs are supported in their discrete laptop form in 6.0 (though still experimental). Linux blog Phoronix notes that Intel's ARC GPUs all seem to run on open source upstream drivers, so support should show up for future Intel cards and chipsets as they arrive on the market. Linux 6.0 includes several hardware drivers of note: fourth-generation Intel Xeon server chips, the not-quite-out 13th-generation Raptor Lake and Meteor Lake chips, AMD's RDNA 3 GPUs, Threadripper CPUs, EPYC systems, and audio drivers for a number of newer AMD systems. One small, quirky addition points to larger things happening inside Linux. Lenovo's ThinkPad X13s, based on an ARM-powered Qualcomm Snapdragon chip, get some early support in 6.0. ARM support is something Linux founder Linus Torvalds is eager to see [...].

Among other changes you can find in Linux 6.0, as compiled by LWN.net (in part one and part two):
- ACPI and power management improvements for Sapphire Rapids CPUs
- Support for SMB3 file transfer inside Samba, while SMB1 is further deprecated
- More work on RISC-V, OpenRISC, and LoongArch technologies
- Intel Habana Labs Gaudi2 support, allowing hardware acceleration for machine-learning libraries
- A "guest vCPU stall detector" that can tell a host when a virtual client is frozen Ars' Kevin Purdy notes that in 2022, "there are patches in Linux 6.0 to help Atari's Falcon computers from the early 1990s (or their emulated descendants) better handle VGA modes, color, and other issues."

Not included in this release are Rust improvements, but they "are likely coming in the next point release, 6.1," writes Purdy.

Developer Asahi Lina with the Asahi Linux project was successfully able to get GNOME running on the Apple M1, including "Firefox with YouTube video playback, the game Neverball, various KDE applications, and more," reports Phoronix. From the report: This is some great progress especially with the driver being written in Rust -- the first within the Direct Rendering Manager subsystem -- and lots of work there with the Rust infrastructure in early form. It won't be until at least Linux 6.2 before this driver could be mainlined while we'll see how quickly it tries to go mainline before it can commit to a stable user-space interface. At the moment there is also a significant driver "hack" involved but will hopefully be sorted out soon. Over in user-space, the AGX Gallium3D driver continues being worked on for OpenGL support with hopes of having OpenGL 2.1 completed by year's end. Obviously it will be longer before seeing the Apple graphics suitable for modern gaming with Vulkan, etc but progress is being made across the board in reverse-engineered, open-source Apple Silicon support under Linux. You can watch a video of the driver working here.

slack_justyb writes: As previously indicated on Slashdot, Rust was slated to be coming to the Linux Kernel sometime in the 6.x version. Well wonder no longer on which version of kernel 6.x will have the first bits of Rust officially in the kernel, as Linus has confirmed that 6.1 will be the first with the new NVMe kernel drivers being in Rust. The first version non-production ready code for the NVMe Rust based kernel drivers were already producing performance comparable to C code. So the final drivers to hit 6.1 are already looking promising. It also helped Rust's case that, thanks to the ground-breaking work of Linux kernel and Rust developer Miguel Ojeda, Rust on Linux has gotten much more mature. Kernel maintainers were convinced it is time to move forward with Rust in Linux. In short, they agreed that Rust on Linux was ready for work.

The IEEE's official publication, IEEE Spectrum, has released its ninth annual ranking of the top programming languages. The results? Python remains on top but is closely followed by C. Indeed, the combined popularity of C and the big C-like languages — C++ and C# — would outrank Python by some margin.

Java also remains popular, as does Javascript, the latter buoyed by the ever-increasing complexity of websites and in-browser tools (although it's worth noting that in some quarters, the cool thing is now deliberately stripped-down static sites built with just HTML and simple CSS).

But among these stalwarts is the rising popularity of SQL. In fact, it's at No. 1 in our Jobs ranking, which looks solely at metrics from the IEEE Job Site and CareerBuilder. Having looked through literally hundreds and hundreds of job listings in the course of compiling these rankings for you, dear reader, I can say that the strength of the SQL signal is not because there are a lot of employers looking for just SQL coders, in the way that they advertise for Java experts or C++ developers. They want a given language plus SQL. And lots of them want that "plus SQL...."

Job listings are of course not the only metrics we look at in Spectrum. A complete list of our sources is here, but in a nutshell we look at nine metrics that we think are good proxies for measuring what languages people are programming in. Sources include GitHub, Google, Stack Overflow, Twitter, and IEEE Xplore [their library of technical content]. The raw data is normalized and weighted according to the different rankings offered — for example, the Spectrum default ranking is heavily weighted toward the interests of IEEE members, while Trending puts more weight on forums and social-media metrics.
Python is still #1 in their "Trending" view of language popularity, but with Java in second place (followed by C, JavaScript, C++ and C# — and then SQL). PHP is next — their 8th-most-trending language, followed by HTML, Go, R, and Rust.

Linux creator Linus Torvalds has announced the first release candidate for the Linux kernel version 6.0, but he says the major number change doesn't signify anything especially different about this release. ZDNet: While there is nothing fundamentally different about this release compared with 5.19, Torvalds noted that there were over 13,500 non-merge commits and over 800 merged commits, meaning "6.0 looks to be another fairly sizable release." According to Torvalds, most of the updates are improvements to the GPU, networking and sound. Torvalds stuck to his word after releasing Linux kernel 5.19 last month, when he flagged he would likely call the next release 6.0 because he's "starting to worry about getting confused by big numbers again."

On Sunday's release of Linux 6.0 release candidate version 1 (rc-1), he explained his reasoning behind choosing a new major version number and its purpose for developers. Again, it's about avoiding confusion rather than signaling that the release has major new features. His threshold for changing the lead version number was .20 because it is difficult to remember incremental version numbers beyond that. "Despite the major number change, there's nothing fundamentally different about this release - I've long eschewed the notion that major numbers are meaningful, and the only reason for a 'hierarchical; numbering system is to make the numbers easier to remember and distinguish," said Torvalds. Torvalds lamented some Rust-enabling code didn't make it into the release. The Register adds: "I actually was hoping that we'd get some of the first rust infrastructure, and the multi-gen LRU VM, but neither of them happened this time around," he mused, before observing "There's always more releases. This is one of those releases where you should not look at the diffstat too closely, because more than half of it is yet another AMD GPU register dump," he added, noting that Intel's Gaudi2 Ai processors are also likely to produce plenty of similar kernel additions. "The CPU people also show up in the JSON files that describe the perf events, but they look absolutely tiny compared to the 'asic_reg' auto-generated GPU and AI hardware definitions," he added.

This week the Rust team announced the release of Rust 1.63.

One noteable update? Adding scoped threads to the standard library: Rust code could launch new threads with std::thread::spawn since 1.0, but this function bounds its closure with 'static. Roughly, this means that threads currently must have ownership of any arguments passed into their closure; you can't pass borrowed data into a thread. In cases where the threads are expected to exit by the end of the function (by being join()'d), this isn't strictly necessary and can require workarounds like placing the data in an Arc.

Now, with 1.63.0, the standard library is adding scoped threads, which allow spawning a thread borrowing from the local stack frame. The std::thread::scope API provides the necessary guarantee that any spawned threads will have exited prior to itself returning, which allows for safely borrowing data.
The official Rust RFC book says "The main drawback is that scoped threads make the standard library a little bit bigger," but calls it "a very common and useful utility...great for learning, testing, and exploratory programming.

"Every person learning Rust will at some point encounter interaction of borrowing and threads. There's a very important lesson to be taught that threads can in fact borrow local variables, but the standard library [didn't] reflect this." And otherwise, "Implementing scoped threads is very tricky to get right so it's good to have a reliable solution provided by the standard library."

"Python seems to be unstoppable," argues the commentary on August's edition of the TIOBE index (which attempts to calculate programming-language popularity based on search results for courses, vendors, and "skilled engineers").

By that measure Python's "market share" rose another 2% in this month's index — to an all-time high of 15.42%. It is hard to find a field of programming in which Python is not used extensively nowadays. The only exception is (safety-critical) embedded systems because of Python being dynamically typed and too slow. That is why the performant languages C and C++ are gaining popularity as well at the moment.

If we look at the rest of the TIOBE index, not that much happened last month. Swift and PHP swapped places again at position 10, Rust is getting close to the top 20, Kotlin is back in the top 30, and the new Google language Carbon enters the TIOBE index at position 192.
InfoWorld notes it's been 10 months since Python first claimed the index's #1 spot last October, "becoming the only language besides Java and C to hold the No. 1 position." In the alternative Pypl Popularity of Programming Language index, which assesses language popularity based on Google searches of programming language tutorials, the top 10 rankings for August were:

1. Python, 28.11% share
2. Java, 17.35%
3. JavaScript, 9.48%
4. C#, 7.08%
5. C/C++, 6.19%
6. PHP, 5.47%
7. R, 4.35%
8. TypeScript, 2.79%
9. Swift, 2.09%
10. Objective-C, 2.03%

The source code for an information-stealing malware coded in Rust has been released for free on hacking forums, with security analysts already reporting that the malware is actively used in attacks. BleepingComputer reports: The malware, which the author claims to have developed in just six hours, is quite stealthy, with VirusTotal returning a detection rate of around 22%. As the info-stealer is written in Rust, a cross-platform language, it allows threat actors to target multiple operating systems. However, in its current form, the new info-stealer only targets Windows operating systems.

Analysts at cybersecurity firm Cyble, who sampled the new info-stealer and named it "Luca Stealer," report that the malware comes with standard capabilities for this type of malware. When executed, the malware attempts to steal data from thirty Chromium-based web browsers, where it will steal stored credit cards, login credentials, and cookies. The stealer also targets a range of "cold" cryptocurrency and "hot" wallet browser addons, Steam accounts, Discord tokens, Ubisoft Play, and more. Where Luca Stealer stands out against other info-stealers is the focus on password manager browser addons, stealing the locally stored data for 17 applications of this kind. In addition to targeting applications, Luca also captures screenshots and saves them as a .png file, and performs a "whoami" to profile the host system and send the details to its operators.

It's difficult for large projects to convert existing C++ codebases into Rust, argue Google engineers — so they've created a new "experimental" open source programming language called Carbon.

Google Principal Software Engineer Chandler Carruth introduced Carbon this week at the "CPP North" C++ conference in Toronto. TechRadar reports: The newly announced Carbon should be interoperable with the popular C++ code, however for users looking to make the full switch, the migration should be fairly easy. For those unsure about a full changeover, Carruth delved into more detail about some of the reasons why Carbon should be considered a powerful successor to the C++ language, including simpler grammar and smoother API imports.
Google's engineers are already building tools to translate C++ into this new language. "While Carbon began as a Google internal project, the development team ultimately wants to reduce contributions from Google, or any other single company, to less than 50% by the end of the year," reports The New Stack, adding that Google ultimately wants to hand off the project to an independent software foundation where development will be led by volunteers: Long the language of choice for building performance-critical applications, C++ is plagued with a number of issues that hamper modern developers, Carruth explained on a GitHub page. It has accumulated decades of technical debt, bringing with it many of the outdated practices that were part of the language's predecessor, C. The keepers of C++ prioritize backward compatibility, in order to continue to support widely-used projects such as Linux and its package management ecosystem, Carruth charged.

The language's evolution is also stymied by a bureaucratic committee process, oriented around standardization rather than design. Which can make it difficult to add new features. C++ has largely a sequestered development process, in which a select committee makes the important decisions, in a waterfall process that can take years. "The committee structure is designed to ensure representation of nations and companies, rather than building an inclusive and welcoming team and community of experts and people actively contributing to the language," Carruth wrote. "Access to the committee and standard is restricted and expensive, attendance is necessary to have a voice, and decisions are made by live votes of those present."

Carruth wants to build Carbon by a more open community-led environment. The project will be maintained on GitHub, and discussed on Discord.... The design team wants to release a core working version ("0.1") by the end of the year.
Carbon will boast modern features like generics and memory safety (including dynamic bounds checks), the article points out. And "The development team will also set out to create a built-in package manager, something that C++ sorely lacks."

"T2 SDE is not just a regular Linux distribution," reads the announcement. "It is a flexible Open Source System Development Environment or Distribution Build Kit (others might even name it Meta Distribution). T2 allows the creation of custom distributions with state of the art technology, up-to-date packages and integrated support for cross compilation."

Slashdot reader ReneR writes: The T2 project released a major milestone update, shipping full support for 25 CPU architectures, variants, and C libraries. Support for cross compiling was further improved to also cover Rust, Ada, ObjC, Fortran, and Go!

This is also the first major release where an AI powered package update bot named 'data' contributed more changes than human contributors combined! [Data: 164, humans: 141]

T2 is known for its sophisticated cross compile support as well as supporting nearly all existing CPU architectures: alpha, arc, arm, arm64, avr32, hppa, ia64, m68k, mipsel, mips64, nios2, ppc, ppc64-32, ppc64le, riscv, riscv64, s390x, spare, sparc64, superh x86, x86-64 and x32 for a wide use in Embedded systems. The project also still supports the Sony PS3, Sgi Octane and Sun workstations as well as state of the art ARM64, RISCV64 as well as AMD64 for regular cloud, server, or simply enthusiast workstation use.

Phoronix reports: The GCC Steering Committee has approved of the GCC Rust front-end providing Rust programming language support by the GNU Compiler Collection. This Rust front-end will likely be merged ahead of the GCC 13 release next year.

The GCC Steering Committee this morning has announced that the Rust front-end "GCC Rust" is appropriate for inclusion into the GCC mainline code-base. This is the effort that has been in the works for a while as an alternative to Rust's official LLVM-based compiler. GCC Rust is still under active development but is getting into shape for mainlining.

The hope is to have at least "beta" level support for the Rust programming language in GCC 13, which will be released as stable around April of next year.

This year's "State of WebAssembly" report has been published by Colin Eberhardt (CTO at the U.K.-based software consultancy Scott Logic). Hundreds of people were surveyed for the report, notes this article by Visual Studio Magazine.

Published by B2B media company 1105 Media, the magazine notes that Eberhardt's survey included some good news for Rust — and for Microsoft's free open source framework Blazor (for building web apps using C# and HTML): This year, like last year, Rust was found to be the most frequently used and most desired programming language for WebAssembly development.... "Rust once again comes out on top, with 45 percent saying they use it frequently or sometimes," Eberhardt said. "WebAssembly and Rust do have quite a close relationship, most WebAssembly runtimes are written in Rust, as are the various platforms based on wasm. It also enjoys some of the best tooling, so this result doesn't come as a big surprise."

While Rust usage and desirability has continued to climb, the Blazor web-dev framework is coming on strong in the report, which treats Blazor as a programming language, though it's not. On that desirability scale, Blazor climbed from sixth spot in 2021 to fourth this year among seven "programming languages" [based on] percentage of respondents who use a given language 'frequently,' or 'sometimes' [for WebAssembly development] compared to last year. Eberhardt said, "Rust has had a modest rise in desirability, but the biggest climber is Blazor, with Go following just behind."

Commenting on another graphic that shows which language people most want to use for WebAssembly development, Eberhardt said, "This shows that Rust usage has climbed steadily, but the biggest climbers are Blazor and Python.
While you can now compile WebAssembly from a variety of languages (including C, #C, and C++), the report also found that JavaScript has somehow become a viable WebAssembly language — sort of, and even though JavaScript itself can't be compiled to WebAssembly... There's a cunning workaround for this challenge; rather than compiling JS to Wasm, you can instead compile a JavaScript engine to WebAssembly then use that to execute your code.

This is actually much more practical than you might think.