"A Canonical engineer has been experimenting with implementing a Linux scheduler within the Rust programming language..." Phoronix reported Monday, "that works via sched_ext for implementing a scheduler using eBPF that can be loaded during run-time."

The project was started "just for fun" over Christmas, according to a post on X by Canonical-based Linux kernel engineer Andrea Righi, adding "I'm pretty shocked to see that it doesn't just work, but it can even outperform the default Linux scheduler (EEVDF) with certain workloads (i.e., gaming)." Phoronix notes the a YouTube video accompanying the tweet shows "a game with the scx_rustland scheduler outperforming the default Linux kernel scheduler while running a parallel kernel build in the background."

"For sure the build takes longer," Righi acknowledged in a later post. "This scheduler doesn't magically makes everything run faster, it simply prioritizes more the interactive workloads vs CPU-intensive background jobs." Righi followed up by adding "And the whole point of this demo was to prove that, despite the overhead of running a scheduler in user-space, we can still achieve interesting performance, while having the advantages of being in user-space (ease of experimentation/testing, reboot-less updates, etc.)"

Wednesday Righi added some improvements, posting that "Only 19 lines of code (comments included) for ~2x performance improvement on SMT isn't bad... and I spent my lunch break playing Counter Strike 2 to test this patch..."

And work seems to be continuing, judging by a fresh post from Righi on Thursday. "I fixed virtme-ng to run inside Docker and used it to create a github CI workflow for sched-ext that clones the latest kernel, builds it and runs multiple VMs to test all the scx schedulers. And it does that in only ~20min. I'm pretty happy about virtme-ng now."

serviscope_minor shares a Phoronix post: A six year old Linux kernel mailing list discussion has been reignited over the prospects of converting the Linux kernel to supporting modern C++ code. The Linux kernel is predominantly made up of C code with various hand-written Assembly plus the growing work around supporting Rust within the Linux kernel. While it's not clear yet if there's sufficient weight to make it a reality, a Linux kernel mailing list discussion has been restarted over potentially seeing the Linux kernel C code converted to C++ in the future.

Back on 1 April 2018 was a set of 45 patches by Red Hat engineer David Howells to begin converting the kernel to C++. This would allow the mainline kernel to make use of inline template functions, inline overloaded functions, class inheritance, and other features not currently supported by the Linux kernel with its C code. A bit hard to make serious discussions that day and ultimately the patches resided on the Linux kernel mailing list for six years without much discussion. serviscope_minor adds: It is notable that the current discussion is somewhat different from the infamous discussions in the past.

Slashdot's 10 most-visited stories of 2023 seemed to touch on all the themes of the year, with a story about AI, two about electric cars, two stories about Linux, and two about the Rust programming language.

And at the top of this list, the #1 story of the year drew over 100,000 views...

• Can California's Power Grid Handle a 15x Increase in Electric Cars?

• Linux Desktop Powers Consider Uniting For an App Store

• Conservatives Bombarded With Facebook Misinformation Far More Than Liberals In 2020 Election, Study Suggests

• 'sudo' and 'su' Are Being Rewritten In Rust For Memory Safety

• Ask Slashdot: Where Can You Buy a Desktop PC That Makes Linux Easy to Install?

• Unix Pioneer Ken Thompson Announces He's Switching From Mac To Linux

• Rust Safety Is Not Superior To C++, Bjarne Stroustrup Says

• 'Pausing AI Developments Isn't Enough. We Need To Shut It All Down'

• Truck Thief Gunned Down by Owner After AirTag Gives Away Location

• Symbolic Wyoming Proposal Urges Voluntary Phase-out of EV Purchases by 2035

Interestingly, a story that ran on New Year's Eve of 2022 attracted so much traffic, it would've been the second-most visited story for all of 2023 — if it had run just a few hours later. That story?

Systemd's Growth Over 2022.

Long-time Slashdot reader destinyland writes: It's a question that comes up all the time on Reddit. Etsy even created a special page for programmer-themed gift suggestions (showing more than 5,000 results). While CNET sticks to broader lists of "tech gifts" — and a separate list for "Star Wars gifts" — other sites around the web have been specifically honing in on programmer-specific suggestions. (Blue light-blocking glasses... A giant rubber duck... The world's strongest coffee... A printer that transfers digital images onto cheese...)

So while in years past Amazon has said they laughed at customer reviews for cans of uranium, this year Amazon has now added a special section that's entirely dedicated to Gifts for Computer Programmers, according to this funny rundown of 2023's "Gifts for Programmers" (that ends up recommending ChatGPT gift cards and backyard office sheds):
From the article: [Amazon's Gifts for Programmers section] shows over 3,000 results, with geek-friendly subcategories like "Glassware & Drinkware" and "Novelty Clothing"... For the coder in your life, Amazon offers everything from brain–teasing programming puzzles to computer–themed jigsaw puzzles. Of course, there's also a wide selection of obligatory funny t–shirts... But this year there's also tech-themed ties and motherboard-patterned socks...

Some programmers, though, might prefer a gift that's both fun and educational. And what's more entertaining than using your Python skills to program a toy robot dog...? But if you're shopping for someone who's more of a cat person, Petoi sells a kit for building a programmable (and open source) cat robot named "Nybble". The sophisticated Arduino-powered feline can be programmed with Python and C++ (as well as block-based coding)... [part of] the new community that's building around "OpenCat", the company's own quadruped robotic pet framework (open sourced on GitHub).

Connor Jones reports via The Register: DLang is among the newer breed of memory-safe languages being endorsed by Western security agencies over the past few years, the same type of language that cyber criminals are switching to. At least three new DLang-based malware strains have been used in attacks on worldwide organizations spanning the manufacturing, agriculture, and physical security industries, Cisco Talos revealed today. The attacks form part of what's being called "Operation Blacksmith" and are attributed to a group tracked as Andariel, believed to be a sub-division of the Lazarus Group -- North Korea's state-sponsored offensive cyber unit. [...]

The researchers noted that DLang is an uncommon choice for writing malware, but a shift towards newer languages and frameworks is one that's been accelerating over the last few years -- in malware coding as in the larger programming world. Rust, however, has often shown itself to be the preferred choice out of what is a fairly broad selection of languages deemed to be memory-safe. AlphV/BlackCat was the first ransomware group to make such a shift last year, re-writing its payload in Rust to offer its affiliates a more reliable tool. A month later, the now-shuttered Hive group did the same thing, and many others followed after that. Other groups to snub Rust include China-based Sandman which was recently observed using Lua-based malware, believed to be part of a wider shift toward Lua development from Chinese attackers.

ZDNet reports that "At the Linux Foundation's Open Source Summit Japan, Linus Torvalds and his good friend Dirk Hohndel, the head of Verizon open source, talked about the current state of Linux: Speaking of maintainers, Hohndel brought up the question of "maintainer fatigue and how draining and stressful this role is...." Torvalds replied, "It's much easier to find developers; we have a lot of developers. Some people think that you have to be a superdeveloper who can do everything to be a maintainer, but that's not actually true...."

Hohndel commented that the aging of the kernel community is a "double-edged sword." Torvalds agreed, but he noted that "one of the things I liked about the Rust side of the kernel, was that there was one maintainer who was clearly much younger than most of the maintainers. We can clearly see that certain areas in the kernel bring in more young people...."

Hohndel and Torvalds also talked about the use of the Rust language in the Linux kernel. Torvalds said, "It's been growing, but we don't have any part of the kernel that really depends on Rust yet. To me, Rust was one of those things that made technical sense, but to me personally, even more important was that we need to not stagnate as a kernel and as developers." That said, Torvalds continued, "Rust has not really shown itself as the next great big thing. But I think during next year, we'll actually be starting to integrate drivers and some even major subsystems that are starting to use it actively. So it's one of those things that is going to take years before it's a big part of the kernel. But it's certainly shaping up to be one of those."
Torvalds also said he enjoyed the fact that open source "has become the standard within the industry."

But later Hohndel, calling AI "autocorrect on steroids," asked Torvalds if he thought he'd ever see submissions of LLM-written code. "I'm convinced it's gonna happen. And it may well be happening already, maybe on a smaller scale where people use it more to help write code." But, unlike many people, Torvalds isn't too worried about AI. "It's clearly something where automation has always helped people write code. This is not anything new at all...."

But, "What about hallucinations?," asked Hohndel. Torvalds, who will never stop being a little snarky, said, "I see the bugs that happen without AI every day. So that's why I'm not so worried. I think we're doing just fine at making mistakes on our own."

The Linux Foundation's own "Open Software Security foundation" has an associated project called Alpha-Omega funded by Microsoft, Google, and Amazon with a mission to catalyze sustainable security improvements to critical open source projects and ecosystems.

It was established nearly two years ago in February of 2022 — and this month announced plans to continue supporting the Rust Foundation Security Initiative: 2022 was also the first full year of operation for the Rust Foundation — an independent nonprofit dedicated to stewarding the Rust programming language and supporting its global community. Given the considerable growth and rising popularity of the Rust programming language in recent years, it has never been more critical to have a healthy and well-funded foundation in place to help ensure the safety and security of this important language.

When the Rust Foundation emerged, OpenSSF recognized a shared vision of global open source security baked into their organizational priorities from day one. These shared security values were the driving force behind Alpha-Omega's decision to grant $460k USD to the Rust Foundation in 2022. This funding helped underwrite their Security Initiative — a program dedicated to improving the state of security within the Rust programming language ecosystem and sowing security best practices within the Rust community. The Security Initiative began in earnest this past January and has now been in operation for a full year with many achievements to note and exciting plans in development.

While security is a clear priority of the Rust language itself and can be seen in its memory safety-critical features, the Rust Project cannot reasonably be expected to foster long term, sustainable security without proper support and funding. Indeed, there is still a pervasive attitude across technology that cybersecurity is being managed and prioritized by "someone else." The unfortunate impact of this attitude is that critical security work often falls on overburdened and under-resourced open source maintainers. By prioritizing the Security Initiative during their first full year in operation, the Rust Foundation has taken on the responsibility of overseeing — and supporting — security improvements within the Rust ecosystem while ensuring meaningful progress...

Alpha-Omega is excited to announce our second year of supporting the Rust Foundation Security Initiative. We believe that this funding will build on the good work and momentum established by the Rust Foundation in 2023. Through this partnership, we are helping relieve maintainer burdens while paving an important path towards a healthier and more secure future within the Rust ecosystem.
Meanwhile, this month the Rust Foundation announced that downloads from Rust's package repository crates.io have now reached 45 billion — and that the foundation is "committed to facilitating the healthy growth of Rust through funding and resources for the community and the Project.

"After conducting initial planning and research and getting approval from our board of directors, we are pleased to announce our intention to help fulfill this commitment by developing a Rust Foundation training and certification program." We continue to be supportive of anyone creating Rust training and education materials. In fact, we are proud to have provided funding to a few individuals involved in this work via our Community Grants Program. Our team is also aware that commercial Rust training courses already exist and that global training entities are already developing their own Rust-focused programs. Given the value of Rust in professional open source, this makes sense. However, we are eager to introduce a program that will allow us to direct profits back into the Rust ecosystem.

As a nonprofit organization, we sit in a unique position thanks to the tools, connections, insights, administrative support, and resources at our disposal — all of which will add value to course material aimed at professional development and adoption. We see our forthcoming program as one tool of many that can be used to verify skills for prospective employers, and for those employers to build out their professional teams of Rust expertise. We will remain supportive of existing training programs offered by Rust Foundation member companies and we'll look for ways to ensure this remains the case as program development progresses... There is no set launch date for the Rust Foundation training and certification program yet, but we plan to continue laying high-quality groundwork in Q4 of 2023 and the first half of 2024.

Python "come with downsides," argues a new article in Communications of the ACM. "Its programs tend to run slowly, and because it is inefficient at running processes in parallel, it is not well suited to some of the latest AI programming."

"Hoping to overcome those difficulties, computer scientist Chris Lattner set out to create a new language, Mojo, which offers the ease of use of Python, but the performance of more complex languages such as C++ or Rust." Lattner tells the site "we don't want to break Python, we want to make Python better," while software architect Doug Meil says Mojo is essentially "Python for AI... and it's going to be way faster in scale across multiple hardware platforms." Lattner teamed up with Tim Davis, whom he had met when they both worked for Google, to form Modular in January 2022. The company, where Lattner is chief executive officer and Davis chief product officer, provides support for companies working on AI and is developing Mojo.

A modern AI programming stack generally has Python on top, Lattner says, but because that is an inefficient language, it has C++ underneath to handle the implementation. The C++ then must communicate with performance accelerators or GPUs, so developers add a platform such as Compute Unified Device Architecture (CUDA) to make efficient use of those GPUs. "Mojo came from the need to unify these three different parts of the stack so that we could build a unified solution that can scale up and down," Lattner says. The result is a language with the same syntax as Python, so people used to programming in Python can adopt it with little difficulty, but which, by some measures, can run up to 35,000 times faster. For AI, Mojo is especially fast at performing the matrix multiplications used in many neural networks because it compiles the multiplication code to run directly on the GPU, bypassing CUDA...

"Increasingly, code is not being written by computer programmers. It's being written by doctors and journalists and chemists and gamers," says Jeremy Howard, an honorary professor of computer science at the University of Queensland, Australia, and a co-founder of fast.ai, a. "All data scientists write code, but very few data scientists would consider themselves professional computer programmers." Mojo attempts to fill that need by being a superset of Python. A program written in Python can be copied into Mojo and will immediately run faster, the company says. The speedup comes from a variety of factors. For instance, Mojo, like other modern languages, enables threads, small tasks that can be run simultaneously, rather than in sequence. Instead of using an interpreter to execute code as Python does, Mojo uses a compiler to turn the code into assembly language.

Mojo also gives developers the option of using static typing, which defines data elements and reduces the number of errors... "Static behavior is good because it leads to performance," Lattner says. "Static behavior is also good because it leads to more correctness and safety guarantees."
Python creator Guido van Rossum "says he is interested to watch how Mojo develops and whether it can hit the lofty goals Lattner is setting for it..." according to the article, " but he emphasizes that the language is in its early stages and, as of July 2023, Mojo had not yet been made available for download."


In June, Lattner did an hour-long interview with the TWIML AI podcast. And in 2017 Chris Lattner answered questions from Slashdot's readers.

An anonymous reader shared this report from InfoWorld: JetBrains' Kotlin language, a Java rival endorsed by Google for Android mobile development, continues to scale up Tiobe's index of language popularity, reaching the 15th spot in the November 2023 rankings...

Software quality services company Tiobe cites Kotlin advantages including interoperability with Java and unrivaled Android accommodations as reasons for the language's rise. Kotlin, Tiobe CEO Paul Jansen said, also fits in with a modern programming culture of expressive languages that have a strong type system and avoid null pointer exceptions by design. "Based on my experience, I am pretty sure Kotlin can reach a top 10 position," Jansen said. It remains to be seen if it can ever scale as high as a top four slot, he added...

In the rival Pypl Popularity of Programming languages index this month, Kotlin was ranked 13th with a 1.76% share, having slipped slightly year-over-year.
Kotlin's rank on the TIOBE index rose three positions in the last month — after rising two positions the month before. TIOBE's CEO says the language has now achieved its highest ranking ever on the index, surpassing 2017's "first wave of Kotlin popularity...when Google announced first class support for Kotlin on Android."

Rust now ranks #20 on the index, behind Delphi/Object Pascal, Swift, Ruby, and R.

Here's TIOBE November rankings for top-20 most popular programming languages:

1. Python
2. C
3. C++
4. Java
5. C#
6. JavaScript
7. PHP
8. Visual Basic
9. SQL
10. Assembly Language
11. Scratch
12. Fortran
13. Go
14. MATLAB
15. Kotlin
16. Delphi/Object Pascal
17. Swift
18. Ruby
19. R
20. Rust

ZDNet shares on update on "Rust in Linux: Where we are and where we're going next," citing a talk at the Linux Plumbers Conference in Richmond, Virginia by Linux/Rust developer Miguel Ojeda: In brief, Rust Linux is continuing to mature and is getting strong support from developers and vendors, such as Cisco, Samsung, and Canonical... Rust is taking the steps it needs to become — along with C — a fully-fledged member of the Linux language toolchain... That's not to say that we're ready to retire C for Rust just yet. In fact, that day is unlikely ever to come. But Rust is definitely on its way to becoming an important language for Linux development...

As for the day-to-day work that's required to make Rust fully integrated with Linux, the "official" website of the initiative is now the self-explanatory Rust for Linux. This site is your one-stop source for all things Rust on Linux... However, the move forward has not been straightforward. Rust on Linux developers have discovered some problems along the way. For example, while deadlocks, when two or more threads are waiting on the other to finish, are safe in Rust, because they don't result in undefined behavior, they're not safe in the Linux kernel. The programmers are working on fixing this issue...

A related issue is that there's growing interest in backporting Rust support into long-term support (LTS) versions of Linux, specifically 5.15 and 6.1. Some people are especially showing interest in the super LTS Linux 6.1 kernel. However, Linux doesn't generally allow backports into LTS Linuxes. So, if you really, really want fully featured Rust support in an older LTS kernel, you're going to need to pay for it in one way or the other. Another general rule that Rust developers have decided they're going to try to "break" is the rule against duplicate drivers. Usually, no one wants anyone wasting time reinventing the wheel, but some maintainers are open to the idea of experimenting with Rust, by starting simple with a driver they're already familiar with...

These movements are small steps forward, but they're all critical for making Rust equal to C as a Linux programming language.

An anonymous reader quotes a report from Ars Technica: This Sunday, November 19, makes a full 25 years since the original Half-Life first hit (pre-Steam) store shelves. To celebrate the anniversary, Valve has uploaded a feature-packed "25th anniversary update" to the game on Steam, and made the title free to keep if you pick it up this weekend. Valve's 25th Anniversary Update page details a bevy of new and modernized features added to the classic first-person shooter, including:

- Four new multiplayer maps that "push the limits of what's possible in the Half-Life engine"
- New graphics settings, including support for a widescreen field-of-view on modern monitors and OpenGL Overbright lighting (still no official ray-tracing support, though-leave that to the modders)
- "Proper gamepad config out of the box" (so dust off that Gravis Gamepad Pro)
- Steam networking support for easier multiplayer setup
- "Verified" support for Steam Deck play ("We failed super hard" on the first verification attempt, Valve writes)
- Proper UI scaling for resolutions up to 3840x1600
- Multiplayer balancing updates (because 25 years hasn't been enough to perfect the meta)
- New entity limits that allow mod makers to build more complex mods
- A full software renderer for the Linux version of the game
- Various bug fixes
- "Removed the now very unnecessary 'Low video quality. Helps with slower video cards' setting"

In addition, the new update includes a host of restored and rarely seen content, including:

- Three multiplayer maps from the "Half-Life: Further Data" CD-ROM: Double Cross, Rust Mill, and Xen DM
- Four restored multiplayer models: Ivan the Space Biker, Proto-Barney (from the alpha build), a skeleton, and Too Much Coffee Man (from "Further Data")
- Dozens of "Further Data" sprays to tag in your multiplayer matches
- The original Half-Life: Uplink demo in playable form

In Chrome, JavaScript (and WebAssembly) code are both executed by Google's open source V8 engine — which already has garbage-collecting capabilities. "This means developers making use of, for example, PHP compiled to Wasm, end up shipping a garbage collector implementation of the ported language (PHP) to the browser that already has a garbage collector," writes Google developer advocate Thomas Steiner, "which is as wasteful as it sounds."

"This is where WasmGC comes in." WebAssembly Garbage Collection (or WasmGC) is a proposal of the WebAssembly Community Group [which] adds struct and array heap types, which means support for non-linear memory allocation... In simplified terms, this means that with WasmGC, porting a programming language to WebAssembly means the programming language's garbage collector no longer needs to be part of the port, but instead the existing garbage collector can be used.
Sometime on Halloween, Steiner wrote that in Chrome, WebAssembly garbage collection is now enabled by default. But then he explored what this means for high-level programming languages (with their own built-in garbage collection) being compiled into WebAssembly: To verify the real-world impact of this improvement, Chrome's Wasm team has compiled versions of the Fannkuch benchmark (which allocates data structures as it works) from C, Rust, and Java. The C and Rust binaries could be anywhere from 6.1 K to 9.6 K depending on the various compiler flags, while the Java version is much smaller at only 2.3 K! C and Rust do not include a garbage collector, but they do still bundle malloc/free to manage memory, and the reason Java is smaller here is because it doesn't need to bundle any memory management code at all. This is just one specific example, but it shows that WasmGC binaries have the potential of being very small, and this is even before any significant work on optimizing for size.
The blog post includes two examples of WasmGC-ported programming languages in action:

• "One of the first programming languages that has been ported to Wasm thanks to WasmGC is Kotlin in the form of Kotlin/Wasm."

• "The Dart and Flutter teams at Google are also preparing support for WasmGC. The Dart-to-Wasm compilation work is almost complete, and the team is working on tooling support for delivering Flutter web applications compiled to WebAssembly."

An anonymous reader shared this article from the Linux blog OMG! Ubuntu: The System Monitor app Ubuntu comes with does an okay job of letting you monitor system resources and oversee running processes — but it does look dated... [T]he app's graphs and charts are tiny, compact, and lack the glanceability and granular-detail that similar tools on other systems offer.

Thankfully, there are plenty of ace System Monitor alternatives available on Linux, with the Rust-based Resources being the latest tool to the join the club. And it's a real looker... Resources shows real-time graphs showing the utilisation of core system components... You can also see a [sortable and searchable] list of running apps and processes, which are separated in this app.
It's also possible to select a refresh interval "from very slow/slow/normal/fast/very fast (though tempting to select, 'very fast' can increase CPU usage)." And selecting an app or process "activates a big red button you can click to 'end' the app/process (a submenu has options to kill, halt, or continue the app/process instead)..."

"If you don't like the 'Windows-iness' of Mission Center — which you may have briefly spotted it in my Ubuntu 23.10 release video — then Resources is a solid alternative."

An anonymous reader shared this report from InfoWorld: JetBrains is previewing a dedicated IDE for the Rust programming language, called RustRover, which combines coding assistance with an integrated Rust toolchain. Available in preview September 13, RustRover is positioned to simplify the Rust coding experience while "unlocking the language's full potential," JetBrains said. Capabilities include real-time feedback, code suggestions, simplified toolchain management, and team collaboration.

Previously, JetBrains offered IntelliJ Rust, an open source Rust plugin for IntelliJ IDEs. But with RustRover, the company aims to provide a dedicated product with enhanced functionality for the growing Rust developer community. JetBrains also has been previewing a multi-language editor and IDE, called JetBrains Fleet, that supports Rust development...

RustRover will have some similarities to JetBrains' other language-specific IDEs including PyCharm for Python, GoLand for Go, and RubyMine for Ruby.
RustRover integrates with version control systems, supporting GitHub and Git.

"We have heard you," Unity posted on Twitter/X on Sunday afternoon. "We apologize for the confusion and angst the runtime fee policy we announced on Tuesday caused."

"We are listening, talking to our team members, community, customers, and partners, and will be making changes to the policy. We will share an update in a couple of days. Thank you for your honest and critical feedback."

Within 90 minutes Unity's tweet had been viewed over 1 million times. Pushback had built over the last five days to Unity's announcement that next year they'd charge developers per game installation (beyond certain thresholds). IGN reports: Unity tried to clarify the policy, saying it will only count "net new installs" on any devices starting January 1 and devs would not be paying fees on re-installations, "fraudulent" installs via botnets and the like, trial version, web and streaming games, and charity-related installs. Unity also claimed that "90 percent of customers will not be affected by this change."

The development community did not take kindly to these proposed changes and clarifications, and many teams across the globe, including Rust 2 developer Facepunch Studios, said they won't be making their games in Unity now. Others, like Massive Monster, threatened to delete its Unity-made game Cult of the Lamb on January 1 should these changes happen.

The pushback got so severe that Unity offices in San Francisco and Austin had to close due to what it called a credible death threat.

An anonymous reader shared this report from InfoWorld: The uses of WebAssembly, aka Wasm, have grown far beyond its initial target of web applications, according to The State of WebAssembly 2023 report. But some developers remain skeptical. Released September 6 by the Cloud Native Computing Foundation (CNCF) and SlashData, in collaboration with the Linux Foundation, the report finds mostly optimism among software developers about future adoption of Wasm for web and non-web environments... However, about 22% of participants in the report indicated pessimism about Wasm adoption for either the web or non-web environments. Further, 83% of the respondents reported challenges with Wasm including difficulties with debugging and troubleshooting, different performance between runtimes, lack of consistent developer experiences between runtimes, lack of learning materials, and compatibility issues with certain browsers.

The report finds that respondents are using WebAssembly across a wide range of software projects including data visualization (35%), internet of things (32%, artificial intelligence (30%), games (28%), back-end services (27%), edge computing (25%), and more. While Wasm is still primarily used to develop web applications (58%), this is changing thanks to WASI (WebAssembly System Interface), which provides a modular interface for Wasm...

Other findings of the State of WebAssembly 2023 report:

- When migrating existing applications to Wasm, 30% of respondents experience performance benefits of more than 50%.
- JavaScript is the most popular language used with Wasm applications. But Rust stands out in popularity in Wasm projects compared to other use cases...
The article says WebAssembly developers were attracted by "faster loading times, the ability to explore new use cases and technologies, and the ability to share code between projects. Improved performance over JavaScript and efficient execution of computationally intensive tasks also were cited."

This month the official Rust blog announced: For the 6th year in a row, the Rust Project conducted a survey on the Rust programming language, with participation from project maintainers, contributors, and those generally interested in the future of Rust. This edition of the annual State of Rust Survey opened for submissions on December 5 and ran until December 22, 2022... [W]e had 9,433 total survey completions and an increased survey completion rate of 82% vs. 76% in 2021...

- More people are using Rust than ever before! Over 90% of survey respondents identified as Rust users, and of those using Rust, 47% do so on a daily basis — an increase of 4% from the previous year.

- 30% of Rust user respondents can write simple programs in Rust, 27% can write production-ready code, and 42% consider themselves productive using Rust. Of the former Rust users who completed the survey, 30% cited difficulty as the primary reason for giving up while nearly 47% cited factors outside of their control.

- The growing maturation of Rust can be seen through the increased number of different organizations utilizing the language in 2022. In fact, 29.7% of respondents stated that they use Rust for the majority of their coding work at their workplace, which is a 51.8% increase compared to the previous year.

- There are numerous reasons why we are seeing increased use of Rust in professional environments. Top reasons cited for the use of Rust include the perceived ability to write "bug-free software" (86%), Rust's performance characteristics (84%), and Rust's security and safety guarantees (69%). We were also pleased to find that 76% of respondents continue to use Rust simply because they found it fun and enjoyable. (Respondents could select more than one option here, so the numbers don't add up to 100%.)

- Of those respondents that used Rust at work, 72% reported that it helped their team achieve its goals (a 4% increase from the previous year) and 75% have plans to continue using it on their teams in the future.

- But like any language being applied in the workplace, Rust's learning curve is an important consideration; 39% of respondents using Rust in a professional capacity reported the process as "challenging" and 9% of respondents said that adopting Rust at work has "slowed down their team". However, 60% of productive users felt Rust was worth the cost of adoption overall...

- Of those respondents who shared their main worries for the future of Rust, 26% have concerns that the developers and maintainers behind Rust are not properly supported — a decrease of more than 30% from the previous year's findings. One area of focus in the future may be to see how the Project in conjunction with the Rust Foundation can continue to push that number towards 0%.

- While 38% have concerns about Rust "becoming too complex", only a small number of respondents were concerned about documentation, corporate oversight, or speed of evolution. 34% of respondents are not worried about the future of Rust at all.

This year's survey reflects a 21% decrease in fears about Rust's usage in the industry since the last survey.

"Serde, a popular Rust (de)serialization project, has decided to ship its serde_derive macro as a precompiled binary," reports Bleeping Computer.

"The move has generated a fair amount of push back among developers who worry about its future legal and technical implications, along with a potential for supply chain attacks, should the maintainer account publishing these binaries be compromised." According to the Rust package registry, crates.io, serde has been downloaded over 196 million times over its lifetime, whereas the serde_derive macro has scored more than 171 million downloads, attesting to the project's widespread circulation... The Serde ecosystem consists of data structures that know how to serialize and deserialize themselves along with data formats that know how to serialize and deserialize other things," states the project's website. Whereas, "derive" is one of its macros...

Some Rust developers request that precompiled binaries be kept optional and separate from the original "serde_derive" crate, while others have likened the move to the controversial code change to the Moq .NET project that sparked backlash. "Please consider moving the precompiled serde_derive version to a different crate and default serde_derive to building from source so that users that want the benefit of precompiled binary can opt-in to use it," requested one user. "Or vice-versa. Or any other solution that allows building from source without having to patch serde_derive... Having a binary shipped as part of the crate, while I understand the build time speed benefits, is for security reasons not a viable solution for some library users."

Users pointed out how the change could impact entities that are "legally not allowed to redistribute pre-compiled binaries, by their own licenses," specifically mentioning government-regulated environments.
The official response from Serde's maintainer: "The precompiled implementation is the only supported way to use the macros that are published in serde_derive. If there is implementation work needed in some build tools to accommodate it, someone should feel free to do that work (as I have done for Buck and Bazel, which are tools I use and contribute significantly to) or publish your own fork of the source code under a different name.

"Separately, regarding the commentary above about security, the best path forward would be for one of the people who cares about this to invest in a Cargo or crates.io RFC around first-class precompiled macros so that there is an approach that would suit your preferences; serde_derive would adopt that when available."

An anonymous reader quotes a report from BleepingComputer: Google has announced the first open-source quantum resilient FIDO2 security key implementation, which uses a unique ECC/Dilithium hybrid signature schema co-created with ETH Zurich. FIDO2 is the second major version of the Fast IDentity Online authentication standard, and FIDO2 keys are used for passwordless authentication and as a multi-factor authentication (MFA) element. Google explains that a quantum-resistant FIDO2 security key implementation is a crucial step towards ensuring safety and security as the advent of quantum computing approaches and developments in the field follow an accelerating trajectory.

To protect against quantum computers, a new hybrid algorithm was created by combining the established ECDSA algorithm with the Dilithium algorithm. Dilithium is a quantum-resistant cryptographic signature scheme that NIST included in its post-quantum cryptography standardization proposals, praising its strong security and excellent performance, making it suitable for use in a wide array of applications. This hybrid signature approach that blends classic and quantum-resistant features wasn't simple to manifest, Google says. Designing a Dilithium implementation that's compact enough for security keys was incredibly challenging. Its engineers, however, managed to develop a Rust-based implementation that only needs 20KB of memory, making the endeavor practically possible, while they also noted its high-performance potential.

The hybrid signature schema was first presented in a 2022 paper (PDF) and recently gained recognition at the ACNS (Applied Cryptography and Network Security) 2023, where it won the "best workshop paper" award. This new hybrid implementation is now part of the OpenSK, Google's open-source security keys implementation that supports the FIDO U2F and FIDO2 standards. The tech giant hopes that its proposal will be adopted by FIDO2 as a new standard and supported by major web browsers with large user bases. The firm calls the application of next-gen cryptography at the internet scale "a massive undertaking" and urges all stakeholders to move quickly to maintain good progress on that front.