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

"We serve about 100 million monthly visitors worldwide," says the CEO of Stack Overflow, "making us one of the most popular websites in the world. I think we are in the top 50 of all websites in the world by traffic."

In a new interview, he says the site's been accessed about 50 billion times over the past 14 years — and then shares his thoughts on the notion that programmers could be replaced by no-code, low-code, or AI-driven pair programming: A: Over the years, there have many, many tools, trying to democratize software development. That's a very positive thing. I actually love the fact that programming is becoming easier to do with these onramps. I was speaking at Salesforce recently, and they've got people in sales organizations writing workflows, and that's low code. You've got all these folks who are not software engineers that are creating their own automations and applications.

However, there is this trade-off. If you're making software easier to build, you're sacrificing things like customizability and a deeper understanding of how this code actually works. Back in the day, you might remember Microsoft FrontPage [an early HTML web page editor] as an example of that. You were limited to certain basic things, but you could get web work done. So similarly, these tools will work for general use cases. But, if they do that, without learning the fundamental principles of code, they will inevitably have some sort of a limit. For example, having to fix something that broke, I think they're going to be really dumbfounded.

Still, I think it's important, and I'm a believer. It's a great way to get people engaged, excited, and started. But you got to know what you're building. Access to sites like Stack Overflow help, but with more people learning as they're building, it's essential to make learning resources accessible at every stage of their journey....

Q: Is Stack Overflow considering any kind of certification? Particularly, as you just mentioned, since it's so easy now for people to step in and start programming. But then there's that big step from "Yes, I got it to work," but now "I have to maintain it for users using it in ways I never dreamed of."

A: "It's very much part of our vision for our company. We see Stack Overflow going from collective knowledge to collective learning. Having all the information is fine and dandy, but are you learning? Now, that we're part of Prosus's edtech division, we're very much looking forward to offering educational opportunities. Just as today, we can get knowledge to developers at the right place and time, we think we can deliver learning at just the right place and time. We believe we can make a huge impact with education and by potentially getting into the certification game.

Q: Some of the open-source nonprofits are moving into education as well. The Linux Foundation, in particular, has been moving here with the LF Training and Certification programs. Are you exploring that?

A: This is very much part of our vision....
Stack Overflow's CEO adds that the site's hot topics now include blockchain, machine learning, but especially technical cloud questions, "rising probably about 50% year over year over the past 10 years.... Related to this is an increase in interest in containerization and cloud-native services."

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.

"Microsoft's GitHub Copilot is being sued in a class action lawsuit that claims the AI product is committing software piracy on an unprecedented scale," reports IT Pro.

Programmer/designer Matthew Butterick filed the case Thursday in San Francisco, saying it was on behalf of millions of GitHub users potentially affected by the $10-a-month Copilot service: The lawsuit seeks to challenge the legality of GitHub Copilot, as well as OpenAI Codex which powers the AI tool, and has been filed against GitHub, its owner Microsoft, and OpenAI.... "By training their AI systems on public GitHub repositories (though based on their public statements, possibly much more), we contend that the defendants have violated the legal rights of a vast number of creators who posted code or other work under certain open-source licences on GitHub," said Butterick.

These licences include a set of 11 popular open source licences that all require attribution of the author's name and copyright. This includes the MIT licence, the GNU General Public Licence, and the Apache licence. The case claimed that Copilot violates and removes these licences offered by thousands, possibly millions, of software developers, and is therefore committing software piracy on an unprecedented scale.

Copilot, which is entirely run on Microsoft Azure, often simply reproduces code that can be traced back to open-source repositories or licensees, according to the lawsuit. The code never contains attributions to the underlying authors, which is in violation of the licences. "It is not fair, permitted, or justified. On the contrary, Copilot's goal is to replace a huge swath of open source by taking it and keeping it inside a GitHub-controlled paywall...." Moreover, the case stated that the defendants have also violated GitHub's own terms of service and privacy policies, the DMCA code 1202 which forbids the removal of copyright-management information, and the California Consumer Privacy Act.
The lawsuit also accuses GitHub of monetizing code from open source programmers, "despite GitHub's pledge never to do so."

And Butterick argued to IT Pro that "AI systems are not exempt from the law... If companies like Microsoft, GitHub, and OpenAI choose to disregard the law, they should not expect that we the public will sit still." Butterick believes AI can only elevate humanity if it's "fair and ethical for everyone. If it's not... it will just become another way for the privileged few to profit from the work of the many."

Reached for comment, GitHub pointed IT Pro to their announcement Monday that next year, suggested code fragments will come with the ability to identify when it matches other publicly-available code — or code that it's similar to.

The article adds that this lawsuit "comes at a time when Microsoft is looking at developing Copilot technology for use in similar programmes for other job categories, like office work, cyber security, or video game design, according to a Bloomberg report."

It's been one week since Python 3.11 was released — and it's "faster than ever!" So says Jay Miller, a Microsoft developer writing about Microsoft's six-person "Faster CPython" team (which includes Python creator Guido van Rossum, and offers assistance to other core developers). Miller cites the team's report that Python 3.11 has already seen speedups of 10-60% in some areas of the language -- and offers this inside look at their work.

First, how the team came together: In 2020, Core Developer Mark Shannon drafted an Implementation plan for speeding up CPython (the most common implementation) by five times. This plan proposed a 4-stage process that, as Python's creator Guido van Rossum says, "was an effort that was too much for one volunteer to accomplish".

"Right from the start, my thought was well, we should try to see if Microsoft can hire Mark and a small team of people to support him." In the previous year Van Rossum came out of retirement and joined Microsoft as a Distinguished Engineer. "It was an important effort and it was too much for one person." Microsoft was open to the idea and a team of 6 engineers, including Van Rossum were established. That team has assisted other core developers in acting on this plan.
But the blog post also looks at how the team functions: Every contributor that made the switch from part-time to full-time contribution mentioned being able to get deeper into their work on the language.... The team meets regularly to discuss these things. "All six of us meet every Monday," says Van Rossum. "There's always more than enough to talk about. That is very different than as a core dev community getting together for a Sprint twice a year, like one day after the conference. That is a very special event, of course, but it doesn't feed me throughout the year." Van Rossum believes that knowledge of one another and their collaborative work gave the team a "leg up" because everyone "knows what communication styles people have and what everybody's weaknesses and strengths are...."

Shannon's original 4 stage plan has continued to evolve to have continuous optimizations for the next several years. "To make that as smooth as possible, you have to think in terms of smaller steps, right?" says [team member] Michael Droettboom. Droettboom has worked on long-term projects in the scientific community including the Hubble Space Telescope and more recently the James Web Space Telescope.... "We hope we can bring some knowledge from really large proprietary systems into what we develop for the Community." says Droettboom. "I think that's really valuable because then you're not just doing it in the abstract. Not just imagining what's going to make Python faster for real use cases, but actually measuring it." [Team member] Brandt Bucher adds in that developers working with these teams can test the impact of changes, "getting useful insights and contributions from people who maintain large, diverse codebases...." Many of the team's meetings feature core developers from other teams and companies.
The blog post highlights specific activities of team members:

• L Pereira is working on a change to how integers are represented inside Python, and "intends to change smaller integers to use native computation instead of the slower algorithms for arbitrarily large numbers."

• Irit Katriel implemented the new Exception groups and except* features in Python 3.11, and reports that "By simplifying the interpreter's internal representation of raised exceptions, I reduced the time it takes to raise and catch an exception by about 10%."

• Brandt Bucher (who helped create structural pattern matching for Python 3.10) is working on a Specialized Adaptive Interpreter (and tools like Specialist to help users move to Python).

• Long-time contributor Eric Snow is working on a per-interpreter Global Interpreter Lock.

And they've already begun working on features for future versions of Python. "You can also find out more about what the Faster CPython Team has in mind for 3.12 in their ideas repo on Github."

Developer Dan Leveille received "a sketchy voicemail from a random number about a class action lawsuit settlement..." he posted on Twitter. "I thought it was a scam and almost ignored it."

But he didn't — and ended up with $8,064.88 in his Venmo account.

Back in 2019 a lawsuit by U.S. developers accused Apple of "profit-killing" App Store commissions, reports TechForge Media. Apple settled that suit by agreeing to create a $100 million Small Developer Assistance Fund (for developers who sold in Apple's app store between June of 2015 and April of 2021). And this month Apple has finally started sending out those payments, Apple Insider reports: Developers had until May 20 to submit a request to an independent administrator to become a "Settlement Class Member." If they met the criteria, the developers stood to receive a payment from $250 to $30,000 in value....

Along with the fund, the settlement also introduced a number of changes to App Store policies, including modifications relating to customer and developer communication, new pricing tiers, and a promise by Apple to continue offering its 15% reduced App Store commission for at least three years.

Long-time Slashdot reader theodp writes: "What is your biggest pain point?", North Carolina State University PhD student Samim Mirhosseini and Microsoft Researchers Austin Z. Henley & Chris Parnin asked 32 computer science instructors at universities and community colleges. Their feedback is summed up in a just-posted paper that will be presented at SIGCSE 2023.

Instructors cited understanding what students are struggling with, answering students' questions, limited teaching assistant (TA) support, grading & feedback, course material preparation, and administrative tasks as challenges, pain points, and things they wish they could change. Interestingly, instructors indicated that some of the attempts to address pain points — including the increased use of TA's, interactive textbooks/exercises, automated grading, "flipped" classrooms [where lectures are assigned as video homework, with classtime reserved for interaction], and peer instruction — aren't always what they're cracked up to be.

- "Some TAs are not mature programmers," instructors noted. "TAs sometimes only run the unit tests and never read the code, [so] two submissions that were nearly identical, but one got [high] marks and the other got [low] marks."

- Automation brings its own challenges, instructors added, citing the problem of interactive textbooks that give grades but deduct points even if there is only a whitespace difference with the solution ("My students struggle so much with it and they spend hours trying to get the white space correct in their program when in reality that's not what I want them spending time on").

- Instructors also cited struggles with "how to design 'Copilot-proof' assignments, to prevent students from completing homework assignments in seconds with little conceptual knowledge.

- Regarding the flipped classroom, one instructor confessed, "I've checked and there's very few people watching these videos."

While grading was cited as "probably the biggest burden of the courses" and "an impossible task," one instructor still noted a preference to grade things themselves even if they have TAs "because [of] the feedback I can get from [...] their homework and assignments." Along the same lines, another noted that while they also wish for more automation of mundane tasks, they are strongly opposed to automating feedback to students because "I think this is the wrong direction for education. Striping away community and humanity from learning."

"Kathleen Booth, who has died aged 100, co-designed of one of the world's first operational computers and wrote two of the earliest books on computer design and programming," the Telegraph wrote this week.

"She was also credited with the invention of the first assembly language, a programming language designed to be readable by users." In 1946 she joined a team of mathematicians under Andrew Booth at Birkbeck College undertaking calculations for the scientists working on the X-ray crystallography images which contributed to the discovery of the double helix shape of DNA....

To help the number-crunching involved Booth had embarked on building a computing machine called the Automatic Relay Calculator or ARC, and in 1947 Kathleen accompanied him on a six-month visit to Princeton University, where they consulted John von Neumann, who had developed the idea of storing programs in a computer. On their return to England they co-wrote General Considerations in the Design of an All Purpose Electronic Digital Computer, and went on to make modifications to the original ARC to incorporate the lessons learnt.

Kathleen devised the ARC assembly language for the computer and designed the assembler.

In 1950 Kathleen took a PhD in applied mathematics and the same year she and Andrew Booth were married. In 1953 they cowrote Automatic Digital Calculators, which included the general principles involved in the new "Planning and Coding"programming style.

The Booths remained at Birkbeck until 1962 working on other computer designs including the All Purpose Electronic (X) Computer (Apexc, the forerunner of the ICT 1200 computer which became a bestseller in the 1960s), for which Kathleen published the seminal Programming for an Automatic Digital Calculator in 1958. The previous year she and her husband had co-founded the School of Computer Science and Information Systems at Birkbeck.
"The APE(X)C design was commercialized and sold as the HEC by the British Tabulating Machine Co Ltd, which eventually became ICL," remembers the Register, sharing a 2010 video about the machine (along with several links for "Further Reading.")

While listening to a podcast about the Go programming language, backend architect Aviv Carmi heard some loose talk about forking the language to keep its original design while also allowing the evolution of an "extended flavor."

If such a fork takes place, Carmi writes on Medium, he hopes the two languages could interact and share the same runtime environment, libraries, and ecosystem — citing lessons learned from the popularity of other language forks: There are well-known, hugely successful precedents for such a move. Unarguably, the JVM ecosystem will last longer and keep on gaining popularity thanks to Scala and Kotlin (a decrease in Java's popularity is overtaken by an increase in Scala's, during the previous decade, and in Kotlin's, during this one). All three languages contribute to a stronger, single community and gain stronger libraries and integrations. JavaScript has undoubtedly become stronger thanks to Typescript, which quickly became one of the world's most popular languages itself. I also believe this is the right move for us Gophers...
Carmi applauds Go's readability-over-writability culture, its consistent concurrency model (with lightweight threading), and its broad ecosystem of tools. But in a second essay Carmi lists his complaints — about Go's lack of keyword-based visibility modifiers (like "public" and "private"), how any symbol declared in a file "is automatically visible to the entire package," and Go's abundance of global built-in symbols (which complicate the choice of possible variable names, but which can still be overriden, since they aren't actually keywords). After a longer wishlist — including null-pointer safety features and improvements to error handling — Carmi introduces a third article with "A Proposition for a Better Future." I would have loved to see a compile time environment that mostly looks like Go, but allows developers to be a bit more expressive to gain maintainability and runtime safety. But at the same time, allow the Go language itself to largely remain the same and not evolve into something new, as a lot of us Gophers fear. As Gophers, why not have two tools in our tool set?
The essay proposes a new extended flavor of Go called Goat — a "new compile-time environment that will produce standard, compatible, and performant Go files that are fully compatible with any other Go project. This means they can import regular Go files but also be safely imported from any other Go file."

"Goat implementation will most likely be delivered as a code generation tool or as a transpiler producing regular go files," explains a page created for the project on GitHub. "However, full implementation details should be designed once the specification provided in this document is finalized."

Carmi's essay concludes, "I want to ignite a thorough discussion around the design and specification of Goat.... This project will allow Go to remain simple and efficient while allowing the community to experiment with an extended flavor. Goat spec should be driven by the community and so it needs the opinion and contribution of any Gopher and non-Gopher out there."

"Come join the discussion, we need your input."

Related link: Go principal engineer Russ Cox gave a talk at GopherCon 2022 that was all about compatibility and "the strategies Go uses to continue to evolve without breaking your programs."

An anonymous reader quotes a report from ZDNet: Low-code and no-code development is often seen as the realm of citizen developers, but the segment of the enterprise where low-code and no-code has gained significant traction is among professional developers themselves. And, importantly, it's making their jobs better in two ways: providing tools for faster software development and deployment, as well as elevating their roles in enterprises to that of teachers and facilitators for potential citizen developers.

A recent survey of 860 developers by OutSystems finds a majority of low-code users -- most of whom also use traditional coding languages alongside low-code -- report that they are "very satisfied" with their team productivity (59%), compared to 41% of traditional developers. Most low-coders, 57%, are also very satisfied with the quality of tools at their disposal to complete their work, compared to 36% of their traditional coding counterparts. In addition, 71% of low-code users said they were able to stick to the typical 40-hour work week, compared to only 44% of traditional developers. Additionally, 63% of low-code developers indicate they are happy with their salary and benefits compared to 40% of traditional developers.

Not only is low-code and no-code making things easier, it is also elevating the roles of technology professionals within their enterprises, to facilitator, educators, and consultants. Industry observers agree. "The professional's role is now to customize and connect the low-code solution to the organization's resources," relates Moses Guttmann, CEO and co-founder of ClearML. Their roles "shift towards mainly automation and orchestration, taking a low-code process and helping the low-code infrastructure gain access to different resources within the organization. Think of it as abstracting the databases and providing access to the orchestration -- such as cloud infrastructure to execute the low-code application." This can only mean more Agile development for the next generation of applications, with business-savvy developers and tech-savvy business users working side by side. "Citizen developers are typically growth-minded, innovative problem solvers with an active understanding of the business' overarching goals," says Aaron White, CTO and co-founder of Vendr. "In tandem with overseeing the work completed in a low-code or no-code environment, professional developers -- especially those leading teams -- should strive to recognize these employees' talents, actively enabling them to contribute to the development process." "It takes away a lot of the day-to-day implementation-related tasks and allows developers to focus on more architectural and strategic concerns," says Om Vyas, co-founder and chief product officer for oak9. "It puts them in a position to have a greater business impact. But also, with low-code and no-code approaches, when the one-size-fits-all pattern does not work for you, it will create work for these professionals to amend or customize to add their own implementations."

In many cases, "a low-code/no-code approach may operate as a complete solution. That said, IT and engineering may need to step in from time to time, to fine-tune the details," White adds.

Apple just launched new ad placements on the App Store, and developers aren't happy with the types of ads surfacing beneath their apps. From a report: As spotted by MacRumors, several app developers have pointed out that ads for gambling have started appearing in the "You Might Also Like" sections beneath their App Store listings, which is just one of the new places Apple has started sticking ads. Developer Simon B. Stovring posted a screenshot of an ad for an online casino app appearing beneath his text editor Runestone. Stovring says he visited the page for his app 10 times and noticed that ads for gambling apps showed up on three visits. Marco Arment, the developer of the podcast app Overcast, said on Twitter he's "really not OK with" the gambling ads showing up on his app product page. Another user replied to Arment's tweet, noting that the App Store is even showing gambling ads beneath apps designed specifically to help users recover from a gambling addiction, while another noticed gambling ads have even popped up on children's education apps.

Apple has announced updates to the App Store Review Guidelines, offering guidance for apps offering cryptocurrency and NFTs. Apple Insider reports: The text for the rule has been changed to include the following: "Apps may not use their own mechanisms to unlock content or functionality, such as license keys, augmented reality markers, QR codes, cryptocurrencies and cryptocurrency wallets, etc." The rule change is no surprise, as Apple only allows alternative payment systems in certain countries.

An addition to the 3.11 rule is as follows: "Apps may use in-app purchase to sell and sell services related to non-fungible tokens (NFTs), such as minting, listing, and transferring. Apps may allow users to view their own NFTs, provided that NFT ownership does not unlock features or functionality within the app. Apps may allow users to browse NFT collections owned by others, provided that the apps may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than in-app purchase."

Finally, Apple has revised rule 3.1.5(iii) to include cryptocurrency exchanges. These companies let people buy and sell cryptocurrencies using traditional fiat currency. "Exchanges: Apps may facilitate transactions or transmissions of cryptocurrency on an approved exchange, provided they are offered only in countries or regions where the app has appropriate licensing and permissions to provide a cryptocurrency exchange."

Earlier this year, Microsoft announced that it would be releasing new hardware to encourage more developers to start using and supporting the Arm version of Windows. Dubbed "Project Volterra," all we knew about it at the time was that it would use an unnamed Qualcomm Snapdragon processor and NVMe-based storage, that it would support at least two monitors, and that it would have a decent number of ports. Today, Microsoft is putting Volterra out into the world, complete with a snappy new name: the Windows Dev Kit 2023. From a report: The Dev Kit 2023 will use a Snapdragon 8cx Gen 3 -- essentially the same chip as the Microsoft SQ3 in the new 5G version of the Surface Pro 9 -- plus 512GB of storage and a whopping 32GB of RAM for the surprisingly low price of $599.

We don't know exactly how fast the 8cx Gen 3 will be (Qualcomm says "up to 85 percent faster" CPU performance than the 8cx Gen 2, which would put it somewhere below but within spitting distance of modern Core i5 laptop CPU). But 512GB of storage and 32GB of memory should make the Dev Kit 2023 useful as a development and testing environment. Microsoft says the box can connect to up to three monitors simultaneously using its two USB-C ports and mini DisplayPort and that up to two of those displays can be 4K screens running at 60 Hz. Three USB-A ports, gigabit Ethernet, Wi-Fi 6, and Bluetooth 5.1 round out the connectivity options.

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.

An anonymous reader quotes a report from the Register: GitHub Copilot -- a programming auto-suggestion tool trained from public source code on the internet -- has been caught generating what appears to be copyrighted code, prompting an attorney to look into a possible copyright infringement claim. On Monday, Matthew Butterick, a lawyer, designer, and developer, announced he is working with Joseph Saveri Law Firm to investigate the possibility of filing a copyright claim against GitHub. There are two potential lines of attack here: is GitHub improperly training Copilot on open source code, and is the tool improperly emitting other people's copyrighted work -- pulled from the training data -- to suggest code snippets to users?

Butterick has been critical of Copilot since its launch. In June he published a blog post arguing that "any code generated by Copilot may contain lurking license or IP violations," and thus should be avoided. That same month, Denver Gingerich and Bradley Kuhn of the Software Freedom Conservancy (SFC) said their organization would stop using GitHub, largely as a result of Microsoft and GitHub releasing Copilot without addressing concerns about how the machine-learning model dealt with different open source licensing requirements.

Copilot's capacity to copy code verbatim, or nearly so, surfaced last week when Tim Davis, a professor of computer science and engineering at Texas A&M University, found that Copilot, when prompted, would reproduce his copyrighted sparse matrix transposition code. Asked to comment, Davis said he would prefer to wait until he has heard back from GitHub and its parent Microsoft about his concerns. In an email to The Register, Butterick indicated there's been a strong response to news of his investigation. "Clearly, many developers have been worried about what Copilot means for open source," he wrote. "We're hearing lots of stories. Our experience with Copilot has been similar to what others have found -- that it's not difficult to induce Copilot to emit verbatim code from identifiable open source repositories. As we expand our investigation, we expect to see more examples. "But keep in mind that verbatim copying is just one of many issues presented by Copilot. For instance, a software author's copyright in their code can be violated without verbatim copying. Also, most open-source code is covered by a license, which imposes additional legal requirements. Has Copilot met these requirements? We're looking at all these issues." GitHub's documentation for Copilot warns that the output may contain "undesirable patterns" and puts the onus of intellectual property infringement on the user of Copilot, notes the report.

Bradley Kuhn of the Software Freedom Conservancy is less willing to set aside how Copilot deals with software licenses. "What Microsoft's GitHub has done in this process is absolutely unconscionable," he said. "Without discussion, consent, or engagement with the FOSS community, they have declared that they know better than the courts and our laws about what is or is not permissible under a FOSS license. They have completely ignored the attribution clauses of all FOSS licenses, and, more importantly, the more freedom-protecting requirements of copyleft licenses."

Brett Becker, assistant professor at University College Dublin in Ireland, told The Register in an email, "AI-assisted programming tools are not going to go away and will continue to evolve. Where these tools fit into the current landscape of programming practices, law, and community norms is only just beginning to be explored and will also continue to evolve." He added: "An interesting question is: what will emerge as the main drivers of this evolution? Will these tools fundamentally alter future practices, law, and community norms -- or will our practices, law and community norms prove resilient and drive the evolution of these tools?"

Linux kernel boss Linus Torvalds has released the first release candidate for version 6.1 of the project and added an appeal for developers to make his life easier by adding code earlier in the development cycle. The Register reports: "Let me just say that after I got my machine sorted out and caught up with the merge window, I was somewhat frustrated with various late pull requests. I've mentioned this before, but it's _really_ quite annoying to get quite a few pull requests in the last few days of the merge window."

He then offered further guidance on how kernel devs can do it right. "Yes, the merge window is two weeks, but that's very much to allow me time to look things over, not 'two weeks to hurriedly put together a branch that you send Linus on Friday of the second week'," he wrote. "The whole 'do an all-nighter to get the paper in the day before the deadline' is something that should have gone out the window after high school. Not for kernel development." His next line was: "You know who you are."

"Anyway, it's not the first time I've said this, I doubt it will be the last. But maybe more people could take it to heart, ok?" he added, before concluding his post with a slightly non-traditional call for testers to visit Linux's git tree because "The merge window may not be the biggest ever, but it's certainly big enough that the shortlog is much too big to post, and below is just my usual merge log." "For all the gory details, please refer to the git tree."

A new resource featuring interactive Q&A's and one-on-ones for developers has launched today called "Ask Apple." 9to5Mac reports: Apple announced the new developer series in a newsroom post today: "Developers participating in Ask Apple can inquire about a variety of topics, such as testing on the latest seeds; implementing new and updated frameworks from Worldwide Developers Conference (WWDC); adopting new features like the Dynamic Island; moving to Swift, SwiftUI, and accessibility; and preparing their apps for new OS and hardware releases. Ask Apple is free of charge and registration is open to all members of the Apple Developer Program and the Apple Developer Enterprise Program."

Ask Apple will kick off with the first round of "opportunities" from October 17-21. Apple says it will be an ongoing series. 9to5Mac highlights what you can expect from "Ask Apple": - Ask questions to various Apple team members through Q&As on Slack or in one-on-one office hours
- Q&As allow developers to connect with Apple evangelists, engineers, and designers to get their questions answered, share their learnings, and engage with other developers around the world
- Office hours are focused on creating and distributing compelling apps that take advantage of the latest in technology and design
- Developers can ask for code-level assistance, design guidance, input on implementing technologies and frameworks, advice on resolving issues, or help with App Review Guidelines and distribution tools
- Office hours will be hosted in time zones around the world and in multiple languages

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

Greg Lavender, CTO of Intel, spoke to VentureBeat about the company's efforts to help developers build applications that can run on any operating system. From the report: "Today in the accelerated computing and GPU world, you can use CUDA and then you can only run on an Nvidia GPU, or you can go use AMD's CUDA equivalent running on an AMD GPU,â Lavender told VentureBeat. "You can't use CUDA to program an Intel GPU, so what do you use?" That's where Intel is contributing heavily to the open-source SYCL specification (SYCL is pronounced like "sickle") that aims to do for GPU and accelerated computing what Java did decades ago for application development. Intel's investment in SYCL is not entirely selfless and isn't just about supporting an open-source effort; it's also about helping to steer more development toward its recently released consumer and data center GPUs. SYCL is an approach for data parallel programming in the C++ language and, according to Lavender, it looks a lot like CUDA.

To date, SYCL development has been managed by the Khronos Group, which is a multi-stakeholder organization that is helping to build out standards for parallel computing, virtual reality and 3D graphics. On June 1, Intel acquired Scottish development firm Codeplay Software, which is one of the leading contributors to the SYCL specification. "We should have an open programming language with extensions to C++ that are being standardized, that can run on Intel, AMD and Nvidia GPUs without changing your code," Lavender said. Lavender is also a realist and he knows that there is a lot of code already written specifically for CUDA. That's why Intel developers built an open-source tool called SYCLomatic, which aims to migrate CUDA code into SYCL. Lavender claimed that SYCLomatic today has coverage for approximately 95% of all the functionality that is present in CUDA. He noted that the 5% SYCLomatic doesn't cover are capabilities that are specific to Nvidia hardware.

With SYCL, Lavender said that there are code libraries that developers can use that are device independent. The way that works is code is written by a developer once, and then SYCL can compile the code to work with whatever architecture is needed, be it for an Nvidia, AMD or Intel GPU. Looking forward, Lavender said that he's hopeful that SYCL can become a Linux Foundation project, to further enable participation and growth of the open-source effort. [...] "We should have write once, run everywhere for accelerated computing, and then let the market decide which GPU they want to use, and level the playing field," Lavender said.

Michael Larabel writes via Phoronix: Debian developers have been figuring out an updated stance to take on non-free firmware considering the increasing number of devices now having open-source Linux drivers but requiring closed-source firmware for any level of functionality. The voting on the non-free firmware matter has now concluded and the votes tallied... The debian votes option 5 as winning: "Change SC for non-free firmware in installer, one installer."

Basically the Debian Installer media will now be allowed to include non-free firmware and to automatically load/use it where necessary while informing the user of it, etc. Considering the state of the hardware ecosystem these days, it's reasonable and common sense since at least users will be able to easily make use of their graphics cards, network adapters, and more. Plus a number of modern CPU security mitigations also requiring the updated closed-source microcode. So all in, I am personally happy with this decision as it will allow for a more pleasant experience for Debian on modern systems and one akin to what is found with other Linux distributions. The solution is described in full via the Debian Wiki.