Systems-oriented developers already have programming languages like C, C++, Rust, and Go, notes InfoWorld.

But now, "we also have Zig, a newer language that seeks to absorb what's best about these languages and offer comparable performance with a better, more reliable developer experience." Zig is a very active project. It was started by Andrew Kelley in 2015 and now seems to be reaching critical mass. Zig's ambition is rather momentous in software history: to become the heir to C's longstanding reign as both the go-to portable low-level language and as a standard to which other languages are compared....

Currently, Zig is being used to implement the Bun.js JavaScript runtime as an alternative to Node.js. Bun's creator Jarred Sumner told me "Zig is sort of similar to writing C, but with better memory safety features in debug mode and modern features like defer (sort of similar to Go's) and arbitrary code can be executed at compile-time via comptime. It has very few keywords so it's a lot easier to learn than C++ or Rust."

Zig differs from most other languages in its small feature footprint, which is the outcome of an explicit design goal: Only one obvious way to do things. Zig's developers take this goal so much to heart that for a time, Zig had no for loop, which was deemed an unnecessary syntactic elaboration upon the already adequate while loop. Kevin Lynagh, coming from a Rust background, wrote, "The language is so small and consistent that after a few hours of study I was able to load enough of it into my head to just do my work." Nathan Craddock, a C developer, echoed the sentiment. Programmers seem to really like the focused quality of Zig's syntax.
While Zig is "approaching" production-ready status, the article notes its high degree of interoperability with C and C++, its unique error-handling system, and its elimination of a malloc keyword (leaving memory allocation to the standard library).

"For now, the Zig team appears to be taking its time with the 1.0 release, which may drop in 2025 or later — but none of that stops us from building all sorts of things with the language today."

"The Rust open source project, which handles standards for the language, released a new governance plan Thursday," reports The New Stack, "the cumulation of six months of intense work." Released as a request for comment on GitHub, it will now undergo a comment period. It requires ratification by team leaders before it's accepted.

The Rust project interacts with, but is separate from, the Rust Foundation, which primarily handles the financial assets of Rust. Two years ago, the project had a very public blowup after its entire mod team resigned and publicly posted a scathing account of the core team, which the mod team called "unaccountable to anyone but themselves." It even suggested the core team was not to be trusted, although the team later recanted and apologized for that.

[Rust core team developer] Josh Triplett understandably didn't want to dwell on the kerfuffle that lead to this action. He focused instead on the underlying structural issues that lead to the leadership crisis. "As a result of that, there was widespread agreement within the project that we needed to create a better formal governance structure that removed some of those ambiguities and conflicts, and had mechanisms for dealing with this without ever having a similar crisis," Triplett told The New Stack. "We don't want to ever to have things get to that point again...."

The original Rust project governance structure evolved out of Mozilla, where Rust began and was nurtured for years. Around 2016 or 2017, a request for comment came out that established the Rust project's governance, Triplett said. It created approximately six teams, including the core, language, mod, library and cargo teams. Among the problems with the old model was that the core team became responsible for not just overseeing problems that arose, but solving them as well, Triplett said. That led to burnout and problems, said JT Turner, one of the co-authors on the new model and a member of the Rust core team.... Ultimately, the old governance model was "not a very precise document," Triplett added.

"It was just, 'Hey, here's the rough divisions of power,' and because that document was very rough and informal, it didn't scale to today," he said. "That's one of the things that led to the governance crisis."

Slashdot reader sleeping cat shares a recent FOSDEM talk by a compiler engineer on the team building Rust-GCC, "an alternative compiler implementation for the Rust programming language."

"If gccrs interprets a program differently from rustc, this is considered a bug," explains the project's FAQ on GitHub.

The FAQ also notes that LLVM's set of compiler technologies — which Rust uses — "is missing some backends that GCC supports, so a gccrs implementation can fill in the gaps for use in embedded development." But the FAQ also highlights another potential benefit: With the recent announcement of Rust being allowed into the Linux Kernel codebase, an interesting security implication has been highlighted by Open Source Security, inc. When code is compiled and uses Link Time Optimization (LTO), GCC emits GIMPLE [an intermediate representation] directly into a section of each object file, and LLVM does something similar with its own bytecode. If mixing rustc-compiled code and GCC-built code in the Linux kernel, the compilers will be unable to perform a full link-time optimization pass over all of the compiled code, leading to absent CFI (control flow integrity).

If Rust is available in the GNU toolchain, releases can be built on the Linux kernel (for example) with CFI using LLVM or GCC.
Started in 2014 (and revived in 2019), "The effort has been ongoing since 2020...and we've done a lot of effort and a lot of progress," compiler engineer Arthur Cohen says in the talk. "We have upstreamed the first version of gccrs within GCC. So next time when you install GCC 13 — you'll have gccrs in it. You can use it, you can start hacking on it, you can please report issues when it inevitably crashes and dies horribly."

"One big thing we're doing is some work towards running the rustc test suite. Because we want gccrs to be an actual Rust compiler and not a toy project or something that compiles a language that looks like Rust but isn't Rust, we're trying really hard to get that test suite working."

Read on for some notes from the talk...

An anonymous reader quotes a report from MIT Technology Review: Many software projects emerge because -- somewhere out there -- a programmer had a personal problem to solve. That's more or less what happened to Graydon Hoare. In 2006, Hoare was a 29-year-old computer programmer working for Mozilla, the open-source browser company. Returning home to his apartment in Vancouver, he found that the elevator was out of order; its software had crashed. This wasn't the first time it had happened, either. Hoare lived on the 21st floor, and as he climbed the stairs, he got annoyed. "It's ridiculous," he thought, "that we computer people couldn't even make an elevator that works without crashing!" Many such crashes, Hoare knew, are due to problems with how a program uses memory. The software inside devices like elevators is often written in languages like C++ or C, which are famous for allowing programmers to write code that runs very quickly and is quite compact. The problem is those languages also make it easy to accidentally introduce memory bugs -- errors that will cause a crash. Microsoft estimates that 70% of the vulnerabilities in its code are due to memory errors from code written in these languages.

Most of us, if we found ourselves trudging up 21 flights of stairs, would just get pissed off and leave it there. But Hoare decided to do something about it. He opened his laptop and began designing a new computer language, one that he hoped would make it possible to write small, fast code without memory bugs. He named it Rust, after a group of remarkably hardy fungi that are, he says, "over-engineered for survival." Seventeen years later, Rust has become one of the hottest new languages on the planet -- maybe the hottest. There are 2.8 million coders writing in Rust, and companies from Microsoft to Amazon regard it as key to their future. The chat platform Discord used Rust to speed up its system, Dropbox uses it to sync files to your computer, and Cloudflare uses it to process more than 20% of all internet traffic.

When the coder discussion board Stack Overflow conducts its annual poll of developers around the world, Rust has been rated the most "loved" programming language for seven years running. Even the US government is avidly promoting software in Rust as a way to make its processes more secure. The language has become, like many successful open-source projects, a barn-raising: there are now hundreds of die-hard contributors, many of them volunteers. Hoare himself stepped aside from the project in 2013, happy to turn it over to those other engineers, including a core team at Mozilla. It isn't unusual for someone to make a new computer language. Plenty of coders create little ones as side projects all the time. But it's meteor-strike rare for one to take hold and become part of the pantheon of well-known languages alongside, say, JavaScript or Python or Java. How did Rust do it?

C++ creator Bjarne Stroustrup "joins calls for changing the programming language itself to address security concerns," according to an article shared by Slashdot user guest reader: In mid-January, the official C++ "direction group" -- which makes recommendations for the programming language's evolution -- issued a statement addressing concerns about C++ safety. While many languages now support "basic type safety" -- that is, ensuring that variables access only sections of memory that are clearly defined by their data types -- C++ has struggled to offer similar guarantees.

This new statement, co-authored by C++ creator Bjarne Stroustrup, now appears to call for changing the C++ programming language itself to address safety concerns. "We now support the idea that the changes for safety need to be not just in tooling, but visible in the language/compiler, and library." The group still also supports its long-preferred use of debugging tools to ensure safety (and "pushing tooling to enable more global analysis in identifying hard for humans to identify safety concerns"). But that January statement emphasizes its recommendation for changes within C++.

Specifically, it proposes "packaging several features into profiles" (with profiles defined later as "a collection of restrictions and requirements that defines a property to be enforced" by, for example, triggering an automatic analysis.) In this way the new changes for safety "should be visible such that the Safe code section can be named (possibly using profiles), and can mix with normal code." And this new approach would ultimately bring not just safety but also flexibility, with profiles specifically designed to support embedded computing, performance-sensitive applications, or highly specific problem domains, like automotive, aerospace, avionics, nuclear, or medical applications.

"For example, we might even have safety profiles for safe-embedded, safe-automotive, safe-medical, performance-games, performance-HPC, and EU-government-regulation," the group suggests. Elsewhere in the document they put it more succinctly. "To support more than one notion of 'safety', we need to be able to name them."
Stroustrup emphasized his faith in C++ in a 2020 interview. "I think C++ can do anything Rust can do, and I would like it to be much simpler to use," Stroustrup told the Association for Computing Machinery's Special Interest Group on Programming Languages.

But even then, he'd said that basic type safety was one of his earliest design goals -- and one he's spent decades trying to achieve. "I get a little bit sad when I hear people talk about C++ as if they were back in the 1980s, the 1990s, which a lot of people do. They looked at it back in the dark ages, and they haven't looked since."

A Rust-based re-implementation of GNU core utilities like cp and mv is "reaching closer to parity with the widely-used GNU upstream and becoming capable of taking on more real-world uses," reports Phoronix: Debian developer Sylvestre Ledru [also an engineering director at Mozilla] began working on uutils during the COVID-19 pandemic and presented last week at FOSDEM 2023 on his Coreutils replacement effort. With uutils growing into increasingly good shape, it's been packaged up by many Linux distributions and is also used now by "a famous social network via the Yocto project...."

The goals with uutils are to try to create a drop-in replacement for GNU Coreutils, strive for good cross-platform support, and easy testing. Ledru's initial goals were about being able to boot Debian, running the most popular packages, building key open-source software, and all-around it's been panning out to be a great success.... [M]ore performance optimizations are to come along with other work for compatibility against the GNU tools and implementing some still missing options in different programs

System76 is announcing a "fully redesigned" version of its AMD-only Linux-powered "Pangolin" laptop with an upgraded memory, storage, processor, and display.

9to5Linux reports: It features the AMD Ryzen 7 6800U processor with up to 4.7 GHz clock speeds, 8 cores, 16 threads, and AMD Radeon 680M integrated graphics.... a 15.6-inch 144Hz Full HD (1920 x 1080) display [using 12 integrated Radeon graphics cores] with a matte finish, a sleek magnesium alloy chassis, and promises up to 10 hours of battery life with its 70 Wh Li-Ion battery. It also features a single-color backlit US QWERTY Keyboard and a multitouch clickpad. Under the hood, the Linux-powered laptop boasts 32 GB LPDDR5 6400 MHz of RAM and it can be equipped with up to 16TB PCIe 4.0 NVMe M.2 SSD storage. Another cool feature is the hardware camera kill switch for extra privacy....

As with all of System76's Linux-powered laptops, the all-new Pangolin comes pre-installed with System76's in-house built Pop!_OS Linux distribution featuring the GNOME-based COSMIC desktop and full disk-encryption or with Ubuntu 22.04 LTS.

Thomas Claburn writes via The Register: GitHub has a lot of code to search -- more than 200 million repositories -- and says last November's beta version of a search engine optimized for source code that has caused a "flurry of innovation." GitHub engineer Timothy Clem explained that the company has had problems getting existing technology to work well. "The truth is from Solr to Elasticsearch, we haven't had a lot of luck using general text search products to power code search," he said in a GitHub Universe video presentation. "The user experience is poor. It's very, very expensive to host and it's slow to index." In a blog post on Monday, Clem delved into the technology used to scour just a quarter of those repos, a code search engine built in Rust called Blackbird.

Blackbird currently provides access to almost 45 million GitHub repositories, which together amount to 115TB of code and 15.5 billion documents. Shifting through that many lines of code requires something stronger than grep, a common command line tool on Unix-like systems for searching through text data. Using ripgrep on an 8-core Intel CPU to run an exhaustive regular expression query on a 13GB file in memory, Clem explained, takes about 2.769 seconds, or 0.6GB/sec/core. [...] At 0.01 queries per second, grep was not an option. So GitHub front-loaded much of the work into precomputed search indices. These are essentially maps of key-value pairs. This approach makes it less computationally demanding to search for document characteristics like the programming language or word sequences by using a numeric key rather than a text string. Even so, these indices are too large to fit in memory, so GitHub built iterators for each index it needed to access. According to Clem, these lazily return sorted document IDs that represent the rank of the associated document and meet the query criteria.

To keep the search index manageable, GitHub relies on sharding -- breaking the data up into multiple pieces using Git's content addressable hashing scheme and on delta encoding -- storing data differences (deltas) to reduce the data and metadata to be crawled. This works well because GitHub has a lot of redundant data (e.g. forks) -- its 115TB of data can be boiled down to 25TB through deduplication data-shaving techniques. The resulting system works much faster than grep -- 640 queries per second compared to 0.01 queries per second. And indexing occurs at a rate of about 120,000 documents per second, so processing 15.5 billion documents takes about 36 hours, or 18 for re-indexing since delta (change) indexing reduces the number of documents to be crawled.

What happens when Stack Overflow's senior research analyst delves more deeply into results from their annual Developer Survey? Rust, Elixir, Clojure, Typescript, and Julia are at the top of the list of Most Loved Programming Languages. However, in looking at the last three years, we see a bit of movement. [While Rust has remained #1 since 2020, Elixir has risen to #2, while Clojure and TypeScript have dropped.]

In 2022, we added a drill-down to specifically show popularity amongst those learning to code. Because Stack Overflow is a learning resource, I would expect that popularity amongst those specifically learning would be a good indicator of current and future programming language popularity. There is an interesting pattern in comparing Most Loved and Learning to Code Popularity: people learning to code aren't using the most loved languages....


Less than 1% of those learning responded they were using either Clojure or Elixir.

1.2% are using Julia
7.1% are using Rust
and 15.1% are using Typescript.
The article still tries to tease out ways to predict future popular programming languages (by, for example, the number of questions being asked about languages, especially by new programmers learning to code). But along the way, they uncover other surprising statistical truths about the limits of their data:

• "Stack Overflow questions are more susceptible to the preferences of those using the site as a learning tool rather than those of more advanced developers."

• "[B]eing loved (via the Developer Survey) is not related to generating more questions on Stack Overflow. And this makes sense: posting questions most likely speaks to friction with coding, a friction that may lead to loving a programming language less."

• "Our latest Developer Survey showed us that ~32% of programmers have been professionally coding for four years or less, a significant amount of people who are most likely involved in learning programming languages. That is, beginner-friendly languages get the most questions and popularity, but the Most Loved languages make veteran developers happy."

An anonymous reader quotes a report from 9to5Linux: Ubuntu maker Canonical announced Thursday the general availability of its Ubuntu Pro comprehensive subscription for Ubuntu users who want to expand the security updates and compliance of their systems.

First released in a beta version in October 2022 with free subscriptions for personal and small-scale commercial use on up to 5 machines, Ubuntu Pro is only available for Ubuntu LTS (Long-Term Support) releases, starting with Ubuntu 16.04, and promises up to 10 years of security updates, as well as access to exclusive tools. These include Ansible, Apache Tomcat, Apache Zookeeper, Docker, Drupal, Nagios, Node.js, phpMyAdmin, Puppet, PowerDNS, Python 2, Redis, Rust, WordPress, ROS, and many others.

The Ubuntu Pro subscription promises patches for critical CVEs in less than 24 hours and expands the optional technical support to an additional 23,000 open-source packages and toolchains beyond the main operating system, not just for Ubuntu's main software repository....

Canonical says that if you need Ubuntu Pro for more than five PCs, you will have to purchase a paid plan, which is currently priced at $25 USD per year for workstations or $500 USD per year for servers with a 30-day free trial. Official Ubuntu Community members get free support for up to 50 machines.

guest reader writes: The Open Standards site contains a new paper from Bjarne Stroustrup titled A call to action: Think seriously about "safety"; then do something sensible about it.

Bjarne reacts to an NSA report about Software Memory Safety since the report excludes C and C++ as unsafe. Bjarne does not consider any of the report's choices for "safe" languages as superior to C++ for the range of uses he cares about.
From Bjarne's response: I have worked for decades to make it possible to write better, safer, and more efficient C++. In particular, the work on the C++ Core Guidelines specifically aims at delivering statically guaranteed type-safe and resource-safe C++ for people who need that without disrupting code bases that can manage without such strong guarantees or introducing additional tool chains. For example, the Microsoft Visual Studio analyzer and its memory-safety profile deliver much of the CG support today and any good static analyzer (e.g., Clang tidy, that has some CG support) could be made to completely deliver those guarantees at a fraction of the cost of a change to a variety of novel "safe" languages.
Bjarne also complains that in the NSA's document, "'safe' is limited to memory safety, leaving out on the order of a dozen other ways that a language could (and will) be used to violate some form of safety and security." There is not just one definition of "safety", and we can achieve a variety of kinds of safety through a combination of programming styles, support libraries, and enforcement through static analysis.... I envision compiler options and code annotations for requesting rules to be enforced. The most obvious would be to request guaranteed full type-and-resource safety.
Bjarne notes that if you work in application domains which prioritize performance over type safety, you could "apply the safety guarantees only where required and use your favorite tuning techniques where needed." Partial adoption of some of the rules (e.g., rules for range checking and initialization) is likely to be important. Gradual adoption of safety rules and adoption of differing safety rules will be important. If for no other reason than the billions of lines of C++ code will not magically disappear, and even "safe" code (in any language) will have to call traditional C or C++ code or be called by traditional code that does not offer specific safety guarantees.

Ignoring the safety issues would hurt large sections of the C++ community and undermine much of the other work we are doing to improve C++.
The article also contains the following references for consideration:
- Design Alternatives for Type-and-Resource Safe C++.
- Type-and-resource safety in modern C++.
- A brief introduction to C++'s model for type- and resource-safety.
- C++ Core Guidelines, safety profiles.

Google announced today that moving forward they will be allowing Rust code into the Chromium code-base, the open-source project that ultimately served as the basis for their Chrome web browser. Phoronix reports: Google is working to introduce a production Rust toolchain into their build system for Chromium and will be allowing Rust libraries for use within Chrome/Chromium. The timeframe for getting this all together is expected within the next year following a slow ramp. Google is backing Rust for Chromium to allow for simpler and safer code than "complex C++" overall, particularly around avoiding memory safety bugs. In turn using Rust should help speed-up development and improve overall security of the Chrome web browser. Initially they are focused on supporting interop in a single direction from C++ to Rust and for now will only be supporting third-party libraries for their Rust usage.

"The Tiobe index gauges language popularity using a formula that assesses searches on programming languages in Google, Bing, Yahoo, Wikipedia, and other search engines," writes InfoWorld. And they add that this year the "vaunted" C++ programming language was the index's biggest gainer in 2022.

TIOBE's announcement includes their calculation that C++ rose 4.62% in popularity in 2022: Runners up are C (+3.82%) and Python (+2.78%). Interestingly, C++ surpassed Java to become the number 3 of the TIOBE index in November 2022. The reason for C++'s popularity is its excellent performance while being a high level object-oriented language. Because of this, it is possible to develop fast and vast software systems (over millions of lines of code) in C++ without necessarily ending up in a maintenance nightmare.
So which programming languages are most popular now? For what it's worth, here's TIOBE's latest ranking:


- Python
- C
- C++
- Java
- C#
- Visual Basic
- JavaScript
- SQL
- Assembly Language
- PHP


InfoWorld adds that "Helping C++ popularity was the publication of new language standards with interesting features, such as C++ 11 and C++ 20."

More from TIOBE: What else happened in 2022? Performance seemed to be important. C++ competitor Rust entered the top 20 again (being at position #26 one year ago), but this time it seems to be for real. Lua, which is known for its easy interfacing with C, jumped from position #30 to #24. F# is another language that made an interesting move: from position #74 to position #33 in one years' time. Promising languages such as Kotlin (from #29 to #25), Julia (from #28 to #29) and Dart (from #37 to #38) still have a long way to go before they reach the top 20. Let's see what happens in 2023.

For three years Stockholm-based games studio Embark has been working on the Rust-gpu project to make Rust "a first class language and ecosystem for GPU programming." The project's latest announcement? rust-gpu now supports ray-tracing.

Their original announcement explained the rationale for this years-long dvelopment effort: Historically in games GPU programming has been done through writing either HLSL, or to a lesser extent GLSL. These are simple programming languages that have evolved along with rendering APIs over the years. However, as game engines have evolved, these languages have failed to provide mechanisms for dealing with large codebases, and have generally stayed behind the curve compared to other programming languages.

In part this is because it's a niche language for a niche market, and in part this has been because the industry as a whole has sunk quite a lot of time and effort into the status quo. While over-all better alternatives to both languages exist, none of them are in a place to replace HLSL or GLSL. Either because they are vendor locked, or because they don't support the traditional graphics pipeline. Examples of this include CUDA and OpenCL. And while attempts have been made to create language in this space, none of them have gained any notable traction in the gamedev community.

Our hope with this project is that we push the industry forward by bringing an existing, low-level, safe, and high performance language to the GPU; namely Rust. And with it come some additional benefits that can't be overlooked: a package/module system that's one of the industry's best, built in safety against race-conditions or out of bounds memory access, a wide range of tools and utilities to improve programmer workflows, and many others!
Along with ray-tracing, this week they announced plans to keep rust-gpu on the same schedule as the stable Rust release, "so you can use your favorite new language features as new stable versions of Rust are being released, by just updating your rust-gpu version."

Thanks to Slashdot reader guest reader for sharing the news!

"Java is no longer among the top three most popular programming languages in the TIOBE Index," reports the Register, "one of several not particularly definitive yardsticks by which such things are measured." According to Paul Jansen, CEO of Netherlands-based TIOBE Software, the rising popularity of C++ has pushed Java down a notch. The index's rankings are now:

- Python in first place
- C second
- C++ third, and
- Java fourth.

C++ stepped up to third, and Java fell to fourth. "C++ surpassed Java for the first time in the history of the TIOBE Index, which means that Java is at position 4 now," said Jansen in the December update for the TIOBE Index. "This is the first time that Java is not part of the top 3 since the beginning of the TIOBE Index in 2001."

The surge in C++, perhaps in part helped by the stable release of C++ 20 in December 2020, is particularly ironic in light of the language's recent dismissal by Microsoft CTO Mark Russinovich, which coincides with industry evangelism for Rust and its capacity for memory safety.
The article points out that other rankings still show a slighty higher popularity for Java. And ZDNet notes the other languages rising quickly in popularity over the last 12 months: In a year-on-year comparison in Tiobe's index, the languages now in the top 20 that made significant gains over the period are: Rust (up from 27 to 20), Objective-C (up from 29 to 19), science-specialized MATLAB (20 to 14), and Google's Go language (up from 19 to 12).

"Linus has released the 6.1 kernel," reports LWN.net — and it's the one with initial support for kernel development in Rust.

Elsewhere LWN explains the specifics of this milestone: No system with a production 6.1 kernel will be running any Rust code, but this change does give kernel developers a chance to play with the language in the kernel context and get a sense for how Rust development feels....

There are other initiatives underway, including the writing of an Apple graphics driver in the Rust language. For the initial merge into the mainline kernel, though, Linus Torvalds made it clear that as little functionality as possible should be included. So those drivers and their support code were trimmed out and must wait for a future kernel release. What is there is the support needed to build a module that can be loaded into the kernel, along with a small sample module.... Torvalds asked for something that could do "hello world" and that is what we got. It is something that can be played with, but it cannot be used for any sort of real kernel programming at this point.

That situation will, hopefully, change in the near future.
Meanwhile, Linux 6.1 also includes "support for destructive BPF programs, some significant io_uring performance improvements, better user-space control over transparent huge-page creation, improved memory-tiering support."

The Register adds: Other interesting additions include more support for the made-in-China LoongArch CPU architecture, introductory work to support Wi-Fi 7 and security fixes for some flaky Wi-Fi routines in previous versions of the kernel. There's also plenty of effort to improve the performance of Linux on laptops, and enhanced power efficiency for AMD's PC-centric RYZEN silicon.

"Rust is awesome, for certain things. But think twice before picking it up for a startup that needs to move fast," Matt Welsh, co-founder and chief executive of Fixie.ai and former Google engineering director, writes in a blog post. From the post: I hesitated writing this post, because I don't want to start, or get into, a holy war over programming languages. (Just to get the flame bait out of the way, Visual Basic is the best language ever!) But I've had a number of people ask me about my experience with Rust and whether they should pick up Rust for their projects. So, I'd like to share some of the pros and cons that I see of using Rust in a startup setting, where moving fast and scaling teams is really important. Right up front, I should say that Rust is very good at what it's designed to do, and if your project needs the specific benefits of Rust (a systems language with high performance, super strong typing, no need for garbage collection, etc.) then Rust is a great choice. But I think that Rust is often used in situations where it's not a great fit, and teams pay the price of Rust's complexity and overhead without getting much benefit.

My primary experience from Rust comes from working with it for a little more than 2 years at a previous startup. This project was a cloud-based SaaS product that is, more-or-less, a conventional CRUD app: it is a set of microservices that provide a REST and gRPC API endpoint in front of a database, as well as some other back-end microservices (themselves implemented in a combination of Rust and Python). Rust was used primarily because a couple of the founders of the company were Rust experts. Over time, we grew the team considerably (increasing the engineering headcount by nearly 10x), and the size and complexity of the codebase grew considerably as well. As the team and codebase grew, I felt that, over time, we were paying an increasingly heavy tax for continuing to use Rust. Development was sometimes sluggish, launching new features took longer than I would have expected, and the team was feeling a real productivity hit from that early decision to use Rust. Rewriting the code in another language would have, in the long run, made development much more nimble and sped up delivery time, but finding the time for the major rewrite work would have been exceedingly difficult.

So we were kind of stuck with Rust unless we decided to bite the bullet and rewrite a large amount of the code. Rust is supposed to be the best thing since sliced bread, so why was it not working so well for us? [...] Despite being some of the smartest and most experienced developers I had worked with, many people on the team (myself included) struggled to understand the canonical ways to do certain things in Rust, how to grok the often arcane error messages from the compiler, or how to understand how key libraries worked (more on this below). We started having weekly "learn Rust" sessions for the team to help share knowledge and expertise. This was all a significant drain on the team's productivity and morale as everyone felt the slow rate of development. As a comparison point of what it looks like to adopt a new language on a software team, one of my teams at Google was one of the first to switch entirely from C++ to Go, and it took no more than about two weeks before the entire 15-odd-person team was quite comfortably coding in Go for the first time.

Last year, Google announced Android Open Source Project (AOSP) support for Rust, and today the company provided an update, while highlighting the decline in memory safety vulnerabilities. 9to5Google reports: Google says the "number of memory safety vulnerabilities have dropped considerably over the past few years/releases."; Specifically, the number of annual memory safety vulnerabilities fell from 223 to 85 between 2019 and 2022. They are now 35% of Android's total vulnerabilities versus 76% four years ago. In fact, "2022 is the first year where memory safety vulnerabilities do not represent a majority of Android's vulnerabilities."

That count is for "vulnerabilities reported in the Android security bulletin, which includes critical/high severity vulnerabilities reported through our vulnerability rewards program (VRP) and vulnerabilities reported internally." During that period, the amount of new memory-unsafe code entering Android has decreased: "Android 13 is the first Android release where a majority of new code added to the release is in a memory safe language. "

Rust makes up 21% of all new native code in Android 13, including the Ultra-wideband (UWB) stack, DNS-over-HTTP3, Keystore2, Android's Virtualization framework (AVF), and "various other components and their open source dependencies." Google considers it significant that there have been "zero memory safety vulnerabilities discovered in Android's Rust code" so far across Android 12 and 13. Google's blog post today also talks about non-memory-safety vulnerabilities, and its future plans: "... We're implementing userspace HALs in Rust. We're adding support for Rust in Trusted Applications. We've migrated VM firmware in the Android Virtualization Framework to Rust. With support for Rust landing in Linux 6.1 we're excited to bring memory-safety to the kernel, starting with kernel drivers.

Linux 6.1 (released last month) included what Linus Torvalds described as "initial Rust scaffolding," remembers this update from SD Times But now, "work has already been done since the 6.1 release to add more infrastructure for Rust in the kernel, though still none of the code interacts with any C code."

And there's still no actual Rust code in Linux: "You need to get all those things that can make sure that Rust can compile, and you can do the debugging and all these things," explained Joel Marcey, director of advocacy and operations for the Rust Foundation, "and make sure that the memory safety is there and all that sort of stuff. And that has to happen first before you can actually write any real code in Rust for the Linux kernel itself."

Marcey explained that Linux is going to be doing this inclusion very piecemeal, with lots of little integrations here and there over time so they can see how it is working. "I would imagine that over the next year, you're going to see more small incremental changes to the kernel with Rust, but as people are seeing that it's actually kind of working out, you'll be able to maybe, for example, write Linux drivers or whatever with Rust," said Marcey....

According to Bec Rumbul, executive director of the Rust Foundation, Rust being added to the kernel is an "enormous vote of confidence in the Rust programming language." She explained that in the past other languages have been planned to make it into the kernel and ended up not getting put in. "I think having someone with the kind of intellectual gravity of Linus Torvalds saying 'No, it's going in there,' that kind of says an awful lot about how reliable Rust already is and how much potential there is for the future as well," she said.

Rumbul believes that there will be an increased interest in the language, which is still relatively new (It first made its debut in 2010) compared to some of the other languages out there to choose from. "I suspect that because Rust is now in the kernel, and it's just being talked about much ... more widely, that it will seem like an attractive prospect to a lot of people that are looking to develop their skills and their knowledge," she said. Rumbul hopes people will also be inspired to participate in the language as contributors and maintainers, because those are some of the less popular roles within open source, but are extremely critical to the health of a language, she explained.
The Rust Foundation also launched a new security team in September to ensure best practices (including a dedicated security engineer). Their first initiative will be a security audit and threat modeling exercises. "We want to basically shore up," Rust operations director Marcey tells SD Times, "to ensure that Rust itself is actually as secure as we always say it is."

In this year's Stack Overflow Developer Survey, 86.73% of developers said they love Rust.

While the popularity of jQuery is decreasing, React.JS "is currently the most widely used client-side framework," reports ZDNet, citing SlashData's 23rd State of the Developer Nation report (compiled from more than 26,000 developers last summer from 163 countries).

ZDNet believe it shows developers "experimenting less and sticking with what they know and what works." JavaScript remains the largest programming language community, SlashData found. According to its research, there are an estimated 19.6 million developers worldwide using JavaScript every day in everything from web development and mobile apps to backend coding, cloud and game design. Java, meanwhile, is growing rapidly. In the last two years, the size of the Java community has more than doubled from 8.3 million to 16.5 million, SlashData found. For perspective, the global developer population grew about half as fast over the same period....

Python also continued to grow strongly, adding about eight million new developers over the last two years, according to SlashData. It accredited the rise of data science and machine learning as "a clear factor in Python's growing popularity". Approximately 63% of machine-learning developers and data scientists report using Python, whereas less than 15% use R, another programming language often associated with data science.
Both the Kotlin and Rust communities doubled in size in the past two years, the article points out. But according to the survey, only 9% of developers were involved in blockchain technologies.

Yet 27% of respondents reported they were learning about (if not currently working on) cryptocurrency-based projects. ZDNet summarizes the findings: Of the three blockchain technologies covered in the report, non-fungible tokens (NFTs) were found to be of least interest to developers: 58% showed "no interest" in NFTs, which SlashData said was "likely due to its perception as a novelty".

The report found that one-quarter (25%) of developers currently work on, or are learning about, blockchain applications other than cryptocurrencies.