"Supporting generics has been Go's most often requested feature, and we're proud to deliver the generic support that the majority of users need today," the Go blog announced this week. *

It's part of what Go's development team is calling the "biggest change ever to the language".

SiliconANGLE writes that "Right out of the gate, Go 1.18 is getting a CPU speed performance boost of up to 20% for Apple M1, ARM64 and PowerPC64 chips. This is all from an expansion of Go 1.17's calling conventions for the application binary interface on these processor architectures."

And Go 1.18 also introduces native support for fuzz testing — the first major programming language to do so, writes ZDNet: As Google explains, fuzz testing or 'fuzzing' is a means of testing the vulnerability of a piece of software by throwing arbitrary or invalid data at it to expose bugs and unknown errors. This adds an additional layer of security to Go's code that will keep it protected as its functionality evolves — crucial as attacks on software continue to escalate both in frequency and complexity. "At Google we are committed to securing the online infrastructure and applications the world depends upon," said Eric Brewer, VIP infrastructure at Google....

While other languages support fuzzing, Go is the first major programming language to incorporate it into its core toolchain, meaning — unlike other languages — third-party support integrations aren't required.
Google is emphasizing Go's security features — and its widespread adoption. ZDNet writes: Google created Go in 2007 and was designed specifically to help software engineers build secure, open-source enterprise applications for modern, multi-core computing systems. More than three-quarters of Cloud Native Computing Foundation projects, including Kubernetes and Istio, are written in Go, says Google. [Also Docker and Etc.] According to data from Stack Overflow, some 10% of developers are writing in Go worldwide, and there are signs that more recruiters are seeking out Go coders in their search for tech talent..... "Although we have a dedicated Go team at Google, we welcome a significant amount of contributions from our community. It's a shared effort, and with their updates we're helping our community achieve Go's long-term vision.
Or, as the Go blog says: We want to thank every Go user who filed a bug, sent in a change, wrote a tutorial, or helped in any way to make Go 1.18 a reality. We couldn't do it without you. Thank you.

Enjoy Go 1.18!
* Supporting generics "includes major — but fully backward-compatible — changes to the language," explains the release notes. Although it adds a few cautionary notes: These new language changes required a large amount of new code that has not had significant testing in production settings. That will only happen as more people write and use generic code. We believe that this feature is well implemented and high quality. However, unlike most aspects of Go, we can't back up that belief with real world experience. Therefore, while we encourage the use of generics where it makes sense, please use appropriate caution when deploying generic code in production.

While we believe that the new language features are well designed and clearly specified, it is possible that we have made mistakes.... it is possible that there will be code using generics that will work with the 1.18 release but break in later releases. We do not plan or expect to make any such change. However, breaking 1.18 programs in future releases may become necessary for reasons that we cannot today foresee. We will minimize any such breakage as much as possible, but we can't guarantee that the breakage will be zero.

Russia's invasion of Ukraine turns up in Mike Melanson's column "This Week in Programming": While the Open Source Initiative's (OSI) definition of open source software is quite clear on the matter — there must be "no discrimination against persons or groups" and "no discrimination against fields of endeavor" — the issue of who should be allowed to use open source software, according to ethical considerations, has long been debated.

Over the last month, this topic has again become a focus of debate as Russia's invasion of Ukraine has led to developers calling for blanket bans by companies like GitHub and GitLab; and to some developers even taking action. Earlier this month, we wrote about how open source gateway Scarf began limiting access to open source packages for the Russian government and military entities, via its gateway.

As we noted at the time, there was a primary distinction made when Scarf took this action: distribution of open source software is separate from the licensing of it. Those points of the OSI definition pertain to the licensing, not to some entity actively providing the software to others.

Since then, discussions around these ideas have continued, and this week an essay by Bradley M. Kuhn, a policy fellow and hacker-in-residence at the Software Freedom Conservancy, argues that copyleft won't solve all problems, just some of them.

The essay specifically takes to task the idea that open source software can effectively affect change by way of licensing limitations. He spent nearly 3,000 words on the topic, before pointedly addressing the issue of Russia — with a similar conclusion to the one reached by Scarf earlier this month. Kuhn argues that "FOSS licenses are not an effective tool to advance social justice causes other than software freedom" and that, instead, developers have a moral obligation to take stances by way of other methods.

"For example, FOSS developers should refuse to work specifically on bug reports from companies who don't pay their workers a living wage," Kuhn offers in an example.

Regarding Russia specifically, Kuhn again points to distribution as an avenue of protest, while still remaining in line with the principles of free and open source software.

"Every FOSS license in existence permits capricious distribution; software freedom guarantees the right to refuse to distribute new versions of the software. (i.e., Copyleft does not require that you publish all your software on the Internet for everyone, or that you give equal access to everyone — rather, it merely requires that those whom you chose to give legitimate access to the software also receive CCS). FOSS projects should thus avoid providing Putin easy access to updates to their FOSS," writes Kuhn.

Pamela Burdman, the executive director of Just Equations, a policy institute focused on the role of math in education equity, writes in an op-ed for Scientific American: All routes to STEM (science, technology, engineering and mathematics) degrees run through calculus classes. Each year, hundreds of thousands of college students take introductory calculus. But only a fraction ultimately complete a STEM degree, and research about why students abandon such degrees suggests that traditional calculus courses are one of the reasons. With scientific understanding and innovation increasingly central to solving 21st-century problems, this loss of talent is something society can ill afford. Math departments alone are unlikely to solve this dilemma. Several of the promising calculus reforms highlighted in our report Charting a New Course: Investigating Barriers on the Calculus Pathway to STEM , published with the California Education Learning Lab, were spearheaded by professors outside of math departments. It's time for STEM faculty to prioritize collaboration across disciplines to transform math classes from weed-out mechanisms to fertile terrain for cultivating a diverse generation of STEM researchers and professionals. This is not uncharted territory.

In 2013, life sciences faculty at the University of California, Los Angeles, developed a two-course sequence that covers classic calculus topics such as the derivative and the integral, but emphasizes their application in a biological context. The professors used modeling of complex systems such as biological and physiological processes as a framework for teaching linear algebra and a starting point for teaching the basics of computer programming to support students' use of systems of differential equations. Creating this course, Mathematics for Life Scientists, wasn't easy. The life sciences faculty involved, none of whom had a joint appointment with the math department, said they resorted to designing the course themselves after math faculty rebuffed their overture. The math faculty feared creating a "watered-down" course with no textbook (though after the course was developed, one math instructor taught some sections of the class).

Besides math, the life sciences faculty said they experienced "significant pushback" from the chemistry and physics departments over concerns that the course wouldn't adequately prepare students for required courses in those disciplines. But the UCLA course seems to be successful, and a textbook based on it now exists. According to recently published research led by UCLA education researchers, students in the new classes ended up with "significantly higher grades" in subsequent physics, chemistry and life sciences courses than students in the traditional calculus course, even when controlling for factors such as demographics, prior preparation and math grades. Students' interest in the subject doubled, according to surveys.

Sophos threat researcher Nick Gregory discovered a hole in Linux's netfilter firewall program that's "exploitable to achieve kernel code execution (via ROP [return-oriented programming]), giving full local privilege escalation, container escape, whatever you want." ZDNet reports: Behind almost all Linux firewalls tools such as iptables; its newer version, nftables; firewalld; and ufw, is netfilter, which controls access to and from Linux's network stack. It's an essential Linux security program, so when a security hole is found in it, it's a big deal. [...] This problem exists because netfilter doesn't handle its hardware offload feature correctly. A local, unprivileged attacker can use this to cause a denial-of-service (DoS), execute arbitrary code, and cause general mayhem. Adding insult to injury, this works even if the hardware being attacked doesn't have offload functionality! That's because, as Gregory wrote to a security list, "Despite being in code dealing with hardware offload, this is reachable when targeting network devices that don't have offload functionality (e.g. lo) as the bug is triggered before the rule creation fails."

This vulnerability is present in the Linux kernel versions 5.4 through 5.6.10. It's listed as Common Vulnerabilities and Exposures (CVE-2022-25636), and with a Common Vulnerability Scoring System (CVSS) score of 7.8), this is a real badie. How bad? In its advisory, Red Hat said, "This flaw allows a local attacker with a user account on the system to gain access to out-of-bounds memory, leading to a system crash or a privilege escalation threat." So, yes, this is bad. Worse still, it affects recent major distribution releases such as Red Hat Enterprise Linux (RHEL) 8.x; Debian Bullseye; Ubuntu Linux, and SUSE Linux Enterprise 15.3. While the Linux kernel netfilter patch has been made, the patch isn't available yet in all distribution releases.

South Africa's Competition Commission says it had referred Facebook and WhatsApp owner Meta Platforms to a tribunal for allegedly abusing its dominant position in the market. From a report: But a spokesperson for WhatsApp said the regulator was objecting to actions meant to protect the platform's users from abuses of WhatsApp's terms. In a statement, the regulator accused Meta of "abusing its dominance by engaging in exclusionary conduct geared at preventing competitors or potential competitors from entering into, participating, and expanding in a market". The commission said Meta had decided to "offboard" GovChat (a start-up that connects government and citizens) and its subsidiary #LetsTalk from its WhatsApp Business Application Programming Interface. It also said the company had "imposed and/or selectively enforced exclusionary terms and conditions regulating access to the WhatsApp Business API, mainly restrictions on the use of data".

This week Silicon Valley's Computer History Museum posted a PDF transcript (and video excerpts) from an interview with 81-year-old Margaret Hamilton, the programmer/systems designer who in the 1960s became director of the Software Engineering Division at the MIT Instrumentation Laboratory which developed the on-board flight software for NASA's Apollo program. Prior to that Hamilton had worked on software to detect an airplane's radar signature, but thought, "You know, 'I guess I should delay graduate school again because I'd like to work on this program that puts all these men on the Moon....'"

"There was always one thing that stood out in my mind, being in the onboard flight software, was that it was 'man rated,' meaning if it didn't work a person's life was at stake if not over. That was always uppermost in my mind and probably many others as well."

Interestingly, Hamilton had originally received two job offers from the Apollo Space Program, and had told them to flip a coin to settle it. ("The other job had to do with support systems. It was software, but it wasn't the onboard flight software.") But what's fascinating is the interview's glimpses at some of the earliest days of the programming profession: There was all these engineers, okay? Hardware engineers, aeronautical engineers and all this, a lot of them out of MIT... But the whole idea of software and programming...? Dick Battin, Dr. Battin, when they told him that they were going to be responsible for the software...he went home to his wife and said he was going to be in charge of software and he thought it was some soft clothing...
Hamilton also remembers in college taking a summer job as a student actuary at Travelers Insurance in the mid-1950s, and "all of a sudden one day word was going around Travelers that there were these new things out there called computers that were going to take away all of their jobs... Pretty soon they wouldn't have jobs. And so everybody was talking about it. They were scared they wouldn't have a way to make a living.

"But, of course, it ended up being more jobs were created with the computers than there were...."

Hamilton's story about Apollo 8 is amazing...

An interesting tidbit from Mike Melanson's column, "This Week in Programming."

"If a proposal unveiled this week gets its way, JavaScript developers will soon have something that many of them have long been asking for: a type system, of some sort at least." A blog post by TypeScript senior program manager Daniel Rosenwasser lays out the background and reasoning for the proposal for type syntax in JavaScript. He writes that "if we pull this all off, we have the chance to make one of the most impactful improvements to the world of JavaScript."

The proposal, which shares authors from Microsoft, Bloomberg, Igalia, and a number of other sources, suggests that JavaScript developers should be able to "add type annotations to their JavaScript code, allowing those annotations to be checked by a type checker that is external to JavaScript" and then be ignored at runtime. "Because this new syntax wouldn't change how surrounding code runs, it would effectively act as comments," writes Rosenwasser in his blog post, later adding that "JavaScript could carve out a set of syntax for types that engines would entirely ignore, but which tools like TypeScript, Flow, and others could use...."

One noteworthy part of the proposal lays out exactly what is not being proposed:

"Our team isn't proposing putting TypeScript's type-checking in every browser and JavaScript runtime — nor are we proposing any new type-checker to be put in the browser. We think doing that would cause problems for JavaScript and TypeScript users alike due to a range of issues, such as runtime performance, compatibility issues with existing TypeScript code, and the risk of halting innovation in the type-checking space." Similarly, several features from TypeScript that generate code, such as enums, namespaces, and parameter properties, are being explicitly excluded "because they have runtime semantics, generating JavaScript code rather than simply being stripped out and ignored...."

As the proposal's authors note, the proposal itself is presented as a "strawperson proposal".... Thus far, it would appear that there is debate aplenty, alongside a rather robust enthusiasm for the advent of type functionality coming to a JavaScript near you.

"Code generation AI — AI systems that can write in different programming languages given a prompt — promise to cut development costs while allowing coders to focus on creative, less repetitive tasks," writes VentureBeat.

"But while research labs like OpenAI and Alphabet-backed DeepMind have developed powerful code-generating AI, many of the most capable systems aren't available in open source." For example, the training data for OpenAI's Codex, which powers GitHub's Copilot feature, hasn't been made publicly available, preventing researchers from fine-tuning the AI model or studying aspects of it such as interpretability.

To remedy this, researchers at Carnegie Mellon University — Frank Xu, Uri Alon, Graham Neubig, and Vincent Hellendoorn — developed PolyCoder, a model based on OpenAI's GPT-2 language model that was trained on a database of 249 gigabytes of code across 12 programming languages. While PolyCoder doesn't match the performance of top code generators in every task, the researchers claim that PolyCoder is able to write in C with greater accuracy than all known models, including Codex....

"Large tech companies aren't publicly releasing their models, which is really holding back scientific research and democratization of such large language models of code," the researchers said. "To some extent, we hope that our open-sourcing efforts will convince others to do the same. But the bigger picture is that the community should be able to train these models themselves. Our model pushed the limit of what you can train on a single server — anything bigger requires a cluster of servers, which dramatically increases the cost."

Sony Pictures Entertainment is consolidating its anime businesses under the Crunchyroll banner to better compete in the growing streaming market for Japanese animation. From a report: The company is adding hundreds of hours of programming and dozens of titles, including "Cowboy Bebop," to the Crunchyroll streaming service that were previously available through its Funimation outlet, the company said Tuesday. Culver City-based Sony Pictures, the film and TV entertainment arm of Tokyo electronics giant Sony Corp., made a big bet on the anime market last year when it bought streaming service Crunchyroll from AT&T for $1.175 billion. The problem was that Sony then had two subscription streamers focused on the market for Japanese animation. Fans had to subscribe to both Crunchyroll and Funimation to get everything they wanted, in addition to Netflix and other services, said Colin Decker, who runs Sony's anime businesses.

The creator of Apple's Swift programming language stayed involved in the Swift core team and Evolution community... until this week. Though he'd left Apple more than five years ago, "Swift is important to me, so I've been happy to spend a significant amount of time to help improve and steer it," Lattner wrote in an explanatory comment on the Swift community forum. "This included the ~weekly core team meetings (initially in person, then over WebEx)..."

The tech news site DevClass notes Lattner is also "the mind behind compiler infrastructure project LLVM," but reports that "Apparently, Lattner hasn't been part of the [Swift] core team since autumn 2021, when he tried discussing what he perceived as a toxic meeting environment with project leadership after an especially noteworthy call made him take a break in summer." "[...] after avoiding dealing with it, they made excuses, and made it clear they weren't planning to do anything about it. As such, I decided not to return," Lattner wrote in his explanation post. Back then, he planned to keep participating via the Swift Evolution community "but after several discussions generating more heat than light, when my formal proposal review comments and concerns were ignored by the unilateral accepts, and the general challenges with transparency working with core team, I decided that my effort was triggering the same friction with the same people, and thus I was just wasting my time."

Lattner had been the steering force behind Swift since the language's inception in 2010. However, after leaving Apple in 2017 and handing over his project lead role, design premises like "single things that compose" seem to have fallen by the wayside, making the decision to move on completely easier for language-creator Lattner.
The article points out Lattner's latest endeavour is AI infrastructure company Modular.AI.

And Lattner wrote in his comment that Swift's leadership "reassures me they 'want to make sure things are better for others in the future based on what we talked about' though...." Swift has a ton of well meaning and super talented people involved in and driving it. They are trying to be doing the best they can with a complicated situation and many pressures (including lofty goals, fixed schedules, deep bug queues to clear, internal folks that want to review/design things before the public has access to them, and pressures outside their team) that induce odd interactions with the community. By the time things get out to us, the plans are already very far along and sometimes the individuals are attached to the designs they've put a lot of energy into. This leads to a challenging dynamic for everyone involved.

I think that Swift is a phenomenal language and has a long and successful future ahead, but it certainly isn't a community designed language, and this isn't ambiguous. The new ideas on how to improve things sounds promising — I hope they address the fundamental incentive system challenges that the engineers/leaders face that cause the symptoms we see. I think that a healthy and inclusive community will continue to benefit the design and evolution of Swift.
DevClass also reported on the aftermath: Probably as a consequence of the move, the Swift core team is currently looking to restructure project leadership. According to Swift project lead Ted Kremenek... "The intent is to free the core team to invest more in overall project stewardship and create a larger language workgroup that can incorporate more community members in language decisions."

Kremenek also used the announcement to thank Lattner for his leadership throughout the formative years of the project, writing "it has been one of the greatest privileges of my life to work with Chris on Swift."
In 2017 Chris Lattner answered questions from Slashdot's readers.

Respondents to the annual survey of the Rust community reported an uptick in weekly usage and challenges, writes InfoWorld: Among those surveyed who are using Rust, 81% were using the language on at least a weekly basis, compared to 72% in last year's survey. Of all Rust users, 75% said they are able to write production-ready code but 27% said it was at times a struggle to write useful, production-ready code.... While the survey pointed toward a growing, healthy community of "Rustaceans," it also found challenges. In particular, Rust users would like to see improvements in compile times, disk usage, debugging, and GUI development...

- For those who adopted Rust at work, 83% found it "challenging." But it was unclear how much of this was a Rust-specific issue or general challenges posed by adopting a new language. During adoption, only 13% of respondents believed the language was slowing their team down while 82% believed Rust helped their teams achieve their goals.

- Of the respondents using Rust, 59% use it at least occasionally at work and 23% use it for the majority of their coding. Last year, only 42% used Rust at work.
From the survey's results: After adoption, the costs seem to be justified: only 1% of respondents did not find the challenge worth it while 79% said it definitely was. When asked if their teams were likely to use Rust again in the future, 90% agreed. Finally, of respondents using Rust at work, 89% of respondents said their teams found it fun and enjoyable to program.

As for why respondents are using Rust at work, the top answer was that it allowed users "to build relatively correct and bug free software" with 96% of respondents agreeing with that statement. After correctness, performance (92%) was the next most popular choice. 89% of respondents agreed that they picked Rust at work because of Rust's much-discussed security properties.

Overall, Rust seems to be a language ready for the challenges of production, with only 3% of respondents saying that Rust was a "risky" choice for production use.
Thanks to Slashdot reader joshuark for submitting the story...

theodp writes: Tech-bankrolled nonprofit Code.org is inviting kids to join the Coldplay Dance Party, explaining in a Medium post that "we've teamed up with award-winning band Coldplay to launch a global campaign that celebrates music and computer science." Teachers and students are encouraged to "share your creations for Code.org and Coldplay to see!" on Twitter, Instagram, TikTok, and Facebook, although a footnote warns: "In most countries, use of social media is not permitted for underage students [Dance Party targets kindergarten thru high school students]. Do not post videos or photos of students without the permission of a parent or guardian." From the announcement: "Coldplay and Code.org believe in the power of computer science education for every student, in every classroom around the world. That's why we're teaming up to inspire students everywhere to code and dance [YouTube] -- let's celebrate the magic of computer science and music! Join the party by using Code.org's Dance Party activity to code your own choreography to Coldplay's "Higher Power." Get creative with classic moves, and have fun with new album-inspired visuals and dancer formations! Post or submit your creations for Coldplay and Code.org to see, and we'll share the best ones on social media [GitHub]. Plus, you'll get a chance to win tickets to see Coldplay on tour, or a chance for your classroom to video chat with the band." "This is a new creative way to continue introducing people to play with and dance around the practice of programming," Google AI Chief Jeff Dean tweeted to his 200K+ Twitter followers. "Since it launched in 2018 [in partnership with Amazon]," Code.org exclaimed in its Medium post, "Dance Party has engaged more than 5.7 million students!"

A recent post on the AWS Open Source blog announced that AWS "is investing in the sustainability of Rust, a language we believe should be used to build sustainable and secure solutions."

It was written by the chair of the Rust foundation (and leader of AWS's Rust team) with a Principal Engineer at AWS, and reminds us that Rust "combines the performance and resource efficiency of systems programming languages like C with the memory safety of languages like Java."

But there's another reason they're promoting Rust: Worldwide, data centers consume about 200 terawatt hours per year. That's roughly 1% of all energy consumed on our planet... [C]loud and hyperscale data centers have been implementing huge energy efficiency improvements, and the migration to that cloud infrastructure has been keeping the total energy use of data centers in balance despite massive growth in storage and compute for more than a decade... [I]s the status quo good enough? Is keeping data center energy use to 1% of worldwide energy consumption adequate..? [Will] innovations in energy efficiency continue to keep pace with growth in storage and compute in the future? Given the explosion we know is coming in autonomous drones, delivery robots, and vehicles, and the incredible amount of data consumption, processing, and machine learning training and inference required to support those technologies, it seems unlikely that energy efficiency innovations will be able to keep pace with demand...

[J]ust like security, sustainability is a shared responsibility. AWS customers are responsible for energy efficient choices in storage policies, software design, and compute utilization, while AWS owns efficiencies in hardware, utilization features, and cooling systems.... In the same way that operational excellence, security, and reliability have been principles of traditional software design, sustainability must be a principle in modern software design. That's why AWS announced a sixth pillar for sustainability to the AWS Well-Architected Framework. What that looks like in practice is choices like relaxing service-level agreements for non-critical functions and prioritizing resource use efficiency. We can take advantage of virtualization and allow for longer device upgrade cycles. We can leverage caching and longer times-to-live whenever possible. We can classify our data and implement automated lifecycle policies that delete data as soon as possible. When we choose algorithms for cryptography and compression, we can include efficiency in our decision criteria.

Last, but not least, we can choose to implement our software in energy efficient programming languages.

There was a really interesting study a few years ago that looked at the correlation between energy consumption, performance, and memory use.... What the study did is implement 10 benchmark problems in 27 different programming languages and measure execution time, energy consumption, and peak memory use. C and Rust significantly outperformed other languages in energy efficiency. In fact, they were roughly 50% more efficient than Java and 98% more efficient than Python. It's not a surprise that C and Rust are more efficient than other languages. What is shocking is the magnitude of the difference. Broad adoption of C and Rust could reduce energy consumption of compute by 50% — even with a conservative estimate....

No one developer, service, or corporation can deliver substantial impact on sustainability. Adoption of Rust is like recycling; it only has impact if we all participate. To achieve broad adoption, we are going to have to grow the developer community.
That "interesting study" cited also found that both C and Rust execute faster than other programming languages, the blog post points out, so "when you choose to implement your software in Rust for the sustainability and security benefits, you also get the optimized performance of C."

And the post also notes Linus Torvalds' recent acknowledgement that while he really loves C, it can be like juggling chainsaws, with easily-overlooked and "not always logical" type interactions. (Torvalds then went on to call Rust "the first language I saw which looked like this might actually be a solution.")

The Rust Foundation is a non-profit partnership between Amazon Web Services (AWS), Google, Huawei, Microsoft, and Mozilla.

From Mike Melanson's "This Week in Programming" column: The 20th anniversary of .NET is upon us this week and with it, Microsoft is pulling out all the stops in celebration of what it says is "the most loved framework by developers for three years in a row now — 2019, 2020, 2021, according to Stack Overflow's developer survey."

First launched in 2002, .NET is, in some ways, something that Microsoft can roll out as evidence of its changed ways over the years. It went from a company embroiled in a monopoly case just a year before this release, to one that later decided to turn around, mend its former ways, and open source .NET Core. "When Microsoft made another major transformation, this time towards open source, .NET was also at the forefront," Microsoft writes in this week's celebratory blog post. "By 2012, we had fully open-sourced the ASP.NET MVC web framework and were accepting contributions. It was one of Microsoft's first major open-source projects at the time. In 2014, we started to build a cross-platform and open-source .NET on GitHub and were floored at the incredible support and contributions from the open-source community...."

Certainly, in comparison to the Microsoft we once knew, there has been a massive shift in its approach to open source software and openness in general. Indeed, these days, Microsoft is also synonymous with another giant in the world of open source, its now-subsidiary GitHub — as well as the npm Registry and countless other projects. Microsoft has transformed from a company that was once led by a man who said that "Linux is a cancer" to one that has more recently welcomed Linux to the Windows desktop, among numerous other open source endeavors.
The column ends by remembering what it calls "Microsoft 'hot reload' drama" last year — Microsoft's removal of the feature from the .NET SDK repo (and its subsequent return, with an apology). "All that's to say, perhaps all's well that ends well, and we should indeed celebrate 20 years of success with a now open source framework. In the same breath, vigilance may be necessary should we want to celebrate another such anniversary in the future."

"As of the 1st of May, the Alexa web traffic ranking engine is going to stop its services," the TIOBE Index reminds us. So for the first time, TIOBE has switched to Similarweb this month to choose which search engines' results to use for its ranking of the popularity of programming languages. Fortunately, there are no big changes in the index due to this swap. The only striking difference is that the top 3 languages, Python, C, and Java, all gained more than 1 percent in the rankings.

We are still fine-tuning the integration with Similarweb, which is combined with a shift to HtmlUnit in the back-end. Some websites are not onboarded yet, but will follow soon. Now that HtmlUnit is applied for web crawling, it will become possible to add more sites to the index, such as Stackoverflow and Github. This will hopefully happen in the next few months.
TechRepublic reports: Python continues to sit atop the index, with C and Java directly behind it. In Feb. 2021, those three also occupied the top spot, but with Python in the number three position, C at top, and Java in second place.

Beyond the top three, there hasn't been much movement in the index, with positions four through eight unchanged from the same time last year. Those slots are occupied, respectively, by C++, C#, Visual Basic, JavaScript and PHP. Positions nine and 10 swapped from Feb. 21 to now, with Assembly Language and SQL now occupying each other's positions.

The one big move of note between Feb. 2021 and Feb. 2022 was with the Groovy programming language, an object-oriented language for Java. Over the course of the year, Groovy fell from 12th position all the way to 20th, putting it perilously close to the "other programming languages" list.
Thanks to Amigan (Slashdot reader #25,469) for sharing the story.

MoviePass, the defunct discount ticketing service, will return this summer without the firm that ran it into the ground, says co-founder Stacy Spikes. The Verge reports: The company, recently bought by Spikes after his unceremonious ouster from MoviePass in 2018, held its launch event today at the Walter Reade Theater Lincoln Center in NYC. Spikes began by wasting absolutely no time addressing the Helios and Matheson Analytics-shaped elephant in the room. The firm is now infamous for being the parent company of MoviePass that managed to blow the entire thing up shortly after the firm bought the startup, which became famous for offering unlimited movie tickets for a monthly fee.
"A lot of people lost money, a lot of people lost trust," Spikes said, claiming he was among those who were hurt by the company's mismanagement. During the opening moments of the event, Spikes oscillated between addressing the disappointment of being pushed out of his company, joking about MoviePass' loyal consumers -- as well as its power users, who Spikes cracked are the reason the company went out of business -- and finally, the process of snapping the company back after its parent company went bankrupt in 2020. "We're looking at this from another point of view," Spikes said of the company's relaunch, adding that he now plans to run the business like a "co-op." Spikes added that MoviePass users will be able to hold partial ownership of the company, with its most premium tier inclusive of a lifetime subscription.

The company's original engineering team is returning for the business's relaunch, according to Spikes, and the service will launch this summer. Under the new model, MoviePass will run on tradable credits that roll over month to month. Subscribers will also be able to use their credits to bring a friend, a markedly different approach from the single-user card system that MoviePass used previously, which could prove annoying for non-cardholders. MoviePass 2.0 will also work on a tiered system, Spikes said. Spikes shared images of a beta version of the new app and the credit-based system, which will vary based on things like peak moviegoing hours. MoviePass' ambitions for subscribers are, charitably, ambitious. Spikes wants to claim 30 percent of the moviegoer market by 2030, MoviePass' "moonshot" goal. Somewhat unsurprisingly, MoviePass will incorporate aspects of Spikes' existing business PreShow, a technology that has been used to allow gamers to trade ad views for in-game currency. [...] Spikes told attendees at the event that MoviePass' most loyal fans will be "deputized" to beta users and will be able to use the experience for its first year for free. At some point during the summer, these users will be contacted about the beta programming.

Google today announced the first developer release of Android 13. These very early releases, which are only meant for developers and aren't available through over-the-air updates, typically don't include too many user-facing changes. From a report: That's true this time as well, but even in this early release, the company is already showing off a few changes that will impact how you'll use your Android phone. Unlike with Android 12, Google plans to have two developer releases and then launch a beta in April, a month earlier than in 2021. The final release could come as early as August, based on Google's roadmap, whereas Android 12 launched in early October. All of this is happening while Android 12L, the Android release for large-screen devices, is still in development, too, though Google notes that it will bring some of those features to Android 13 as well. These include improved support for tablets, foldables and Android apps on Chromebooks. One of the most visible changes in Android 13 so far is that Google will bring the dynamic color feature of Material You, which by default takes its cues from your home screen image to all app icons. Developers will have to supply a monochromatic app icon for this to work, which many will hopefully do, because the current mix of themed and un-themed icons doesn't make for a great look. For now, this will only be available on Pixel devices, though, and Google says it will work with its partners to bring it to more devices. With this release, Google supports the Pixel 6 Pro, Pixel 6, Pixel 5a 5G, Pixel 5, Pixel 4a (5G), Pixel 4a, Pixel 4 XL, and Pixel 4.

An anonymous reader shares a report: Imagine for a moment that the millions of computer chips inside the servers that power the largest data centers in the world had rare, almost undetectable flaws. And the only way to find the flaws was to throw those chips at giant computing problems that would have been unthinkable just a decade ago. As the tiny switches in computer chips have shrunk to the width of a few atoms, the reliability of chips has become another worry for the people who run the biggest networks in the world. Companies like Amazon, Facebook, Twitter and many other sites have experienced surprising outages over the last year. The outages have had several causes, like programming mistakes and congestion on the networks. But there is growing anxiety that as cloud-computing networks have become larger and more complex, they are still dependent, at the most basic level, on computer chips that are now less reliable and, in some cases, less predictable. In the past year, researchers at both Facebook and Google have published studies describing computer hardware failures whose causes have not been easy to identify. The problem, they argued, was not in the software -- it was somewhere in the computer hardware made by various companies. Google declined to comment on its study, while Facebook did not return requests for comment on its study.

"They're seeing these silent errors, essentially coming from the underlying hardware," said Subhasish Mitra, a Stanford University electrical engineer who specializes in testing computer hardware. Increasingly, Dr. Mitra said, people believe that manufacturing defects are tied to these so-called silent errors that cannot be easily caught. Researchers worry that they are finding rare defects because they are trying to solve bigger and bigger computing problems, which stresses their systems in unexpected ways. Companies that run large data centers began reporting systematic problems more than a decade ago. In 2015, in the engineering publication IEEE Spectrum, a group of computer scientists who study hardware reliability at the University of Toronto reported that each year as many as 4 percent of Google's millions of computers had encountered errors that couldn't be detected and that caused them to shut down unexpectedly. In a microprocessor that has billions of transistors -- or a computer memory board composed of trillions of the tiny switches that can each store a 1 or 0 -- even the smallest error can disrupt systems that now routinely perform billions of calculations each second.

From Mike Melanson's "This Week in Programming" column: The second beta of Go 1.18 was released this week, following up the first beta, which the team writes was "the most downloaded Go beta ever, with twice as many downloads as any previous release." With it comes support for generics in both gopls [the official Go language server] and Visual Studio Code's Go extension.

In addition to the long-awaited generics feature, Go 1.18 introduces fuzzing and the new Go workspace mode.

Having put the first beta through its paces, the team also writes that it "has also proved very reliable; in fact, we are already running it in production here at Google." Nonetheless, Beta 2 is here to make sure everything is good, as Beta 1 uncovered some "obscure bugs in the new support for generics".

The release candidate is also expected later this month, with the final Go 1.18 release slated for March. And while we're talking about Go 1.18, Go AWK creator Ben Hoyt decided to take a look at Go performance from version 1.2 to 1.18 using the performance of his own tool "when compiled using each released version of Go from 1.2 (the earliest version I could download) to 1.18 (which is in beta now)." As you might expect (or hope, rather), Go has picked up the pace over recent versions. "Overall, countwords is now about 5x as fast as it would have been with Go 1.2, and sumloop is 14x as fast! (Though I first released GoAWK when Go was already at version 1.11, so it wasn't around for the huge early gains.)," Hoyt writes.

"For an actively-developed compiler like Go, it's cool to be able to get performance improvements just by waiting and letting others do all the hard work. :-)"

DeepMind has created an AI system named AlphaCode that it says "writes computer programs at a competitive level." From a report: The Alphabet subsidiary tested its system against coding challenges used in human competitions and found that its program achieved an "estimated rank" placing it within the top 54 percent of human coders. The result is a significant step forward for autonomous coding, says DeepMind, though AlphaCode's skills are not necessarily representative of the sort of programming tasks faced by the average coder. Oriol Vinyals, principal research scientist at DeepMind, told The Verge over email that the research was still in the early stages but that the results brought the company closer to creating a flexible problem-solving AI -- a program that can autonomously tackle coding challenges that are currently the domain of humans only. "In the longer-term, we're excited by [AlphaCode's] potential for helping programmers and non-programmers write code, improving productivity or creating new ways of making software," said Vinyals.