When developers boast "I could write that in a weekend," they're missing the painful reality that haunts software maintainers for years. In a candid blog post, Construct developer Ashley explains why maintaining large software projects is a burden most programmers fail to appreciate. "Writing the initial code for a feature is only a fraction of the work," Ashley explains, estimating it represents just "25% of the total work" in Construct's 750,000-line codebase. The rest? A grinding cycle of "testing, diagnosing and fixing bugs, optimizing performance, upgrading it to work with other changes, refactoring, customer support, writing documentation and similarly revising the documentation over time."

Ashley describes how accepting code contributions feels like someone offering to build you a free extension -- initially attractive until the roof starts leaking years later and the original builder is nowhere to be found. Meanwhile, your tenants (users) are furious, and you're stuck with "no good options." The post recounts Construct's own bruises: a community-contributed storage plugin still causing compatibility headaches a decade later, and third-party libraries that became maintenance nightmares after their creators vanished.

These experiences explain why seasoned maintainers eye large code contributions with deep suspicion rather than gratitude. "If you suggest some software project uses some code -- even a small amount -- will you be there in literally 10 year's time sorting out all the issues that arise from it?" Ashley asks. "Usually the answer is no."

ZDNet's Steven Vaughan-Nichols shares some of the latest improvements to ExpressVPN following its codebase transition from C to Rust. An anonymous reader quotes an excerpt from the report: ExpressVPN is one of ZDNET's favorite Virtual Private Networks (VPNs). The popular VPN's transformation of its Lightway codebase from C to Rust promises to make the service faster and more secure. For now, the updated Lightway 2.0 is only available via ExpressVPN's Aircove router with the February 4 AircoveOS v5 update. The Aircove, which we rate as the best VPN router, costs $189. With this device, you can protect your tech from unwanted snoopers without installing a VPN on each gadget. So, how much faster is the updated ExpressVPN? In my tests, I connected to the internet via my updated router over my 2 Gigabit per second (Gbps) AT&T Internet using a 2.5 Gbps Ethernet-connected Linux Mint desktop with a Wi-Fi 6 connection over my Samsung Galaxy 25 Plus smartphone.

Without the VPN engaged, I saw 1.6 Gbps speeds, which is about par. With the VPN switched on and using Lightway 2.0, I saw speeds in the 290 to 330 Megabit per second (Mbps) range to Toronto and London, England. Farther afield, I saw speeds around 250 to 280Mbps to Hong Kong and Seoul. That's about 20% faster than I had seen with earlier Lightway versions. I was impressed. This version of the VPN should also be more secure. As Pete Membrey, ExpressVPN's chief research officer, said in a statement: "At ExpressVPN, we innovate to solve the challenges of tomorrow. Upgrading Lightway from its previous C code to Rust was a strategic and straightforward decision to enhance performance and security while ensuring longevity."

The updated Lightway VPN protocol also uses ML-KEM, the newly finalized NIST standard for post-quantum encryption. This feature, wrote Membray in a blog post, "ensures your connection is secured by encryption designed not just for today's threats but for the quantum-powered challenges of the future." To ensure the integrity of the recoded Lightway protocol, ExpressVPN commissioned two independent security audits from cybersecurity firms Cure53 and Praetorian. Both audits yielded positive results, with only minor vulnerabilities identified and promptly addressed by ExpressVPN. In short, ExpressVPN is technically about as safe a VPN as they come.

Google has launched a free version of Gemini Code Assist, offering developers substantially higher usage limits than competing services. From a report: The AI coding assistant, powered by the fine-tuned Gemini 2.0 model, allows up to 180,000 code completions monthly -- 90 times more than GitHub Copilot's free tier limit of 2,000. The release comes just one day after Anthropic introduced Claude Code, underscoring intensifying competition in AI-powered development tools.

Gemini Code Assist integrates with popular environments including Visual Studio Code, JetBrains IDEs, and GitHub, where it performs code reviews on both public and private repositories. Google's offering features a 128,000-token context window, enabling developers to work with larger codebases. The service supports all public domain programming languages and requires only a Gmail account to register, with no credit card needed.

According to Ryan Salva, Google Cloud's senior director of product management, more than 75% of developers now rely on AI in their daily work, with over 25% of new code at Google being AI-generated. For developers wanting advanced features like private repository integration or Google Cloud service connections, premium tiers remain available.

An anonymous reader quotes a report from Wired: Anthropic, an artificial intelligence company founded by exiles from OpenAI, has introduced the first AI model that can produce either conventional output or a controllable amount of "reasoning" needed to solve more grueling problems. Anthropic says the new hybrid model, called Claude 3.7, will make it easier for users and developers to tackle problems that require a mix of instinctive output and step-by-step cogitation. "The [user] has a lot of control over the behavior -- how long it thinks, and can trade reasoning and intelligence with time and budget," says Michael Gerstenhaber, product lead, AI platform at Anthropic.

Claude 3.7 also features a new "scratchpad" that reveals the model's reasoning process. A similar feature proved popular with theChinese AI model DeepSeek. It can help a user understand how a model is working over a problem in order to modify or refine prompts. Dianne Penn, product lead of research at Anthropic, says the scratchpad is even more helpful when combined with the ability to ratchet a model's "reasoning" up and down. If, for example, the model struggles to break down a problem correctly, a user can ask it to spend more time working on it. [...]

Penn says that Claude's reasoning mode received additional data on business applications including writing and fixing code, using computers, and answering complex legal questions. "The things that we made improvements on are ... technical subjects or subjects which require long reasoning," Penn says. "What we have from our customers is a lot of interest in deploying our models into their actual workloads." Anthropic says that Claude 3.7 is especially good at solving coding problems that require step-by-step reasoning, outscoring OpenAI's o1 on some benchmarks like SWE-bench. The company is today releasing a new tool, called Claude Code, specifically designed for this kind of AI-assisted coding. "The model is already good at coding," Penn says. But "additional thinking would be good for cases that might require very complex planning -- say you're looking at an extremely large code base for a company."

An anonymous Slashdot reader shared this report from Phoronix: Linux's second-in-command Greg Kroah-Hartman has also been a big proponent of Rust kernel code. He's crafted another Linux kernel mailing list post [Wednesdsay] outlining the benefits of Rust and encouraging new kernel code/drivers to be in Rust rather than C. Greg KH makes the case that the majority of the kernel bugs are due to "stupid little corner cases in C that are totally gone in Rust."
"As someone who has seen almost EVERY kernel bugfix and security issue for the past 15+ years... and who sees EVERY kernel CVE issued, I think I can speak on this topic," Kroah-Hartman began. Here's some excerpts from his remarks. Citing corner cases like overwrites of memory, error path cleanups, use-after-free mistakes and forgetting to check error values, Kroah-Hartman says he's "all for... making these types of problems impossible to hit." That's why I'm wanting to see Rust get into the kernel, these types of issues just go away, allowing developers and maintainers more time to focus on the REAL bugs that happen (i.e. logic issues, race conditions, etc.)... [F]or new code / drivers, writing them in Rust where these types of bugs just can't happen (or happen much much less) is a win for all of us, why wouldn't we do this...? Rust isn't a "silver bullet" that will solve all of our problems, but it sure will help in a huge number of places, so for new stuff going forward, why wouldn't we want that...?

Yes, mixed language codebases are rough, and hard to maintain, but we are kernel developers dammit, we've been maintaining and strengthening Linux for longer than anyone ever thought was going to be possible. We've turned our development model into a well-oiled engineering marvel creating something that no one else has ever been able to accomplish. Adding another language really shouldn't be a problem, we've handled much worse things in the past and we shouldn't give up now on wanting to ensure that our project succeeds for the next 20+ years. We've got to keep pushing forward when confronted with new good ideas, and embrace the people offering to join us in actually doing the work to help make sure that we all succeed together.
Kroah-Hartman emphasized later that "a huge majority of the stupid things we do in C just don't happen in the same code implemented in Rust (i.e. memory leaks, error path cleanups, return value checking, etc.) "

The complete thread contains over 140 messages — including Linus Torvalds' observation that " #pragma is complete garbage and should never be used."

This year's "State of Rust" survey was completed by 7,310 Rust developers. DevClass note some key findings: When asked about their biggest worries for Rust's future, 45.5 percent cited "not enough usage in the tech industry," up from 42.5 percent last year, just ahead of the 45.2 percent who cited complexity as a concern... Only 18.6 percent declared themselves "not worried," though this is a slight improvement on 17.8 percent in 2023...

Another question asks whether respondents are using Rust at work. 38.2 percent claimed to use it for most of their coding [up from 34% in 2023], and 13.4 percent a few times a week, accounting for just over half of responses. At the organization level there is a similar pattern. 45.5 percent of organizations represented by respondents make "non-trivial use of Rust," up from 38.7 percent last year.
More details from I Programmer: On the up are "Using Rust helps us achieve or goals", now 82% compared to 72% in 2022; "We're likely to use Rust again in the future", up 3% to 78%; and "Using Rust has been worth the cost of Adoption". Going down are "Adopting Rust has been challenging", now 34.5% compared to 38.5% in 2022; and "Overall adopting Rust has slowed down our team" down by over 2% to 7%.
"According to the survey, organizations primarily choose Rust for building correct and bug-free software (87.1%), performance characteristics (84.5%), security and safety properties (74.8%), and development enjoyment (71.2%)," writes The New Stack: Rust seems to be especially popular for creating server backends (53.4%), web and networking services, cloud technologies and WebAssembly, the report said. It also seems to be gaining more traction for embedded use cases... Regarding the preferred development environment, Linux remains the dominant development platform (73.7%).

However, although VS Code remains the leading editor, its usage dropped five percentage points, from 61.7% to 56.7%, but the Zed editor gained notable traction, from 0.7% to 8.9%. Also, "nine out of 10 Rust developers use the current stable version, suggesting strong confidence in the language's stability," the report said...

Overall, 82% of respondents report that Rust helped their company achieve its goals, and daily Rust usage increased to 53% (up four percentage points from 2023). When asked why they use Rust at work, 47% of respondents cited a need for precise control over their software, which is up from 37% when the question was asked two years ago.

Linus Torvalds responded Thursday to kernel developer Christoph Hellwig, who had claimed Torvalds merged Rust code into the kernel even over his objections as the original C code's maintainer. Highlights from Torvalds' response: The fact is, the pull request you objected to DID NOT TOUCH THE DMA LAYER AT ALL. It was literally just another user of it, in a completely separate subdirectory, that didn't change the code you maintain in _any_ way, shape, or form... Honestly, what you have been doing is basically saying "as a DMA maintainer I control what the DMA code is used for".

And that is not how *any* of this works. What's next? Saying that particular drivers can't do DMA, because you don't like that device, and as a DMA maintainer you control who can use the DMA code? That's _literally_ exactly what you are trying to do with the Rust code. You are saying that you disagree with Rust — which is fine, nobody has ever required you to write or read Rust code. But then you take that stance to mean that the Rust code cannot even use or interface to code you maintain...

You don't have to like Rust. You don't have to care about it. That's been made clear pretty much from the very beginning, that nobody is forced to suddenly have to learn a new language, and that people who want to work purely on the C side can very much continue to do so. So to get back to the very core of your statement:

"The document claims no subsystem is forced to take Rust"

that is very much true. You are not forced to take any Rust code, or care about any Rust code in the DMA code. You can ignore it...

You can't have it both ways. You can't say "I want to have nothing to do with Rust", and then in the very next sentence say "And that means that the Rust code that I will ignore cannot use the C interfaces I maintain".... So when you change the C interfaces, the Rust people will have to deal with the fallout, and will have to fix the Rust bindings. That's kind of the promise here: there's that "wall of protection" around C developers that don't want to deal with Rust issues in the promise that they don't *have* to deal with Rust.

But that "wall of protection" basically goes both ways. If you don't want to deal with the Rust code, you get no *say* on the Rust code. Put another way: the "nobody is forced to deal with Rust" does not imply "everybody is allowed to veto any Rust code".
Torvalds also made sure to add some kind remarks, including "I respect you technically, and I like working with you."

AI coding assistants are reshaping software development, but they're unlikely to replace human programmers entirely, according to industry experts and developers. GitHub CEO Thomas Dohmke projects AI could soon generate 80-90% of corporate code, transforming developers into "conductors of an AI-empowered orchestra" who guide and direct these systems.

Current AI coding tools, including Microsoft's GitHub Copilot, are delivering 10-30% productivity gains in business environments. At KPMG, developers report saving 4.5 hours weekly using Copilot, while venture investment in AI coding assistants tripled to $1.6 billion in 2024. The tools are particularly effective at automating routine tasks like documentation generation and legacy code translation, according to KPMG AI expert Swami Chandrasekaran.

They're also accelerating onboarding for new team members. Demand for junior developers remains soft, however, though analysts say it's premature to attribute this directly to AI adoption. Training programs like Per Scholas are already adapting, incorporating AI fundamentals alongside traditional programming basics to prepare developers for an increasingly AI-augmented workplace.

Software engineering job listings have plummeted to a five-year low, with postings on Indeed dropping to 65% of January 2020 levels -- a steeper decline than any other tech-adjacent field. According to data from Indeed's job aggregator, software development positions are now at 3.5x fewer vacancies compared to their mid-2022 peak and 8% lower than a year ago.

The decline appears driven by multiple factors including widespread adoption of AI coding tools -- with 75% of engineers reporting use of AI assistance -- and a broader tech industry recalibration after aggressive pandemic-era hiring. Notable tech companies like Salesforce are maintaining flat engineering headcount while reporting 30% productivity gains from AI tools, according to an analysis by software engineer Gergely Orosz.

While the overall job market shows 10% growth since 2020, software development joins other tech-focused sectors in decline: marketing (-19%), hospitality (-18%), and banking/finance (-7%). Traditional sectors like construction (+25%), accounting (+24%), and electrical engineering (+20%) have grown significantly in the same period, he wrote. The trend extends beyond U.S. borders, with Canada showing nearly identical patterns. European markets and Australia demonstrate more resilience, though still below peak levels.

Leading AI models can fix broken code, but they're nowhere near ready to replace human software engineers, according to extensive testing [PDF] by OpenAI researchers. The company's latest study put AI models and systems through their paces on real-world programming tasks, with even the most advanced models solving only a quarter of typical engineering challenges.

The research team created a test called SWE-Lancer, drawing from 1,488 actual software fixes made to Expensify's codebase, representing $1 million worth of freelance engineering work. When faced with these everyday programming tasks, the best AI model â" Claude 3.5 Sonnet -- managed to complete just 26.2% of hands-on coding tasks and 44.9% of technical management decisions.

Though the AI systems proved adept at quickly finding relevant code sections, they stumbled when it came to understanding how different parts of software interact. The models often suggested surface-level fixes without grasping the deeper implications of their changes.

The research, to be sure, used a set of complex methodologies to test the AI coding abilities. Instead of relying on simplified programming puzzles, OpenAI's benchmark uses complete software engineering tasks that range from quick $50 bug fixes to complex $32,000 feature implementations. Each solution was verified through rigorous end-to-end testing that simulated real user interactions, the researchers said.

Junior software developers' overreliance on AI coding assistants is creating knowledge gaps in fundamental programming concepts, developer Namanyay Goel argued in a post. While tools like GitHub Copilot and Claude enable faster code shipping, developers struggle to explain their code's underlying logic or handle edge cases, Goel wrote. Goel cites the decline of Stack Overflow, a technical forum where programmers historically found detailed explanations from experienced developers, as particularly concerning.

In January the TIOBE Index (estimating programming language popularity) declared Python their language of the year. (Though it was already #1 in their rankings, it had showed a 9.3% increase in their ranking system, notes InfoWorld.) TIOBE CEO Paul Jansen says this reflects how easy Python is to learn, adding that "The demand for new programmers is still very high" (and that "developing applications completely in AI is not possible yet.")

In fact on February's version of the index, the top ten looks mostly static. The only languages dropping appear to be very old languages. Over the last 12 months C and PHP have both fallen on the index — C from the #2 to the #4 spot, and PHP from #10 all the way to #14. (Also dropping is Visual Basic, which fell from #9 to #10.)

But TechRepublican cites another factor that seems to be affecting the rankings: language speed. Fast programming languages are gaining popularity, TIOBE CEO Paul Jansen said in the TIOBE Programming Community Index in February. Fast programming languages he called out include C++ [#2], Go [#8], and Rust [#13 — up from #18 a year ago].

Also, according to the updated TIOBE rankings...

- C++ held onto its place at second from the top of the leaderboard.
- Mojo and Zig are following trajectories likely to bring them into the top 50, and reached #51 and #56 respectively in February.

"Now that the world needs to crunch more and more numbers per second, and hardware is not evolving fast enough, speed of programs is getting important. Having said this, it is not surprising that the fast programming languages are gaining ground in the TIOBE index," Jansen wrote. The need for speed helped Mojo [#51] and Zig [#56] rise...

Rust reached its all-time high in the proprietary points system (1.47%.), and Jansen expects Go to be a common sight in the top 10 going forward.

Oracle co-founder and chairman Larry Ellison said governments should consolidate all national data for consumption by AI models, calling this step the "missing link" for them to take full advantage of the technology. From a report: Fragmented sets of data about a population's health, agriculture, infrastructure, procurement and borders should be unified into a single, secure database that can be accessed by AI models, Ellison said in an on-stage interview with former British Prime Minister Tony Blair at the World Government Summit in Dubai.

Countries with rich population data sets, such as the UK and United Arab Emirates, could cut costs and improve public services, particularly health care, with this approach, Ellison said. Upgrading government digital infrastructure could also help identify wastage and fraud, Ellison said. IT systems used by the US government are so primitive that it makes it difficult to identify "vast amounts of fraud," he added, pointing to efforts by Elon Musk's team at the Department of Government Efficiency to weed it out.

Brave Browser version 1.75 introduces "custom scriptlets," a new feature that allows advanced users to inject their own JavaScript into websites for enhanced customization, privacy, and usability. The feature is similar to the TamperMonkey and GreaseMonkey browser extensions, notes BleepingComputer. From the report: "Starting with desktop version 1.75, advanced Brave users will be able to write and inject their own scriptlets into a page, allowing for better control over their browsing experience," explained Brave in the announcement. Brave says that the feature was initially created to debug the browser's adblock feature but felt it was too valuable not to share with users. Brave's custom scriptlets feature can be used to modify webpages for a wide variety of privacy, security, and usability purposes.

For privacy-related changes, users write scripts that block JavaScript-based trackers, randomize fingerprinting APIs, and substitute Google Analytics scripts with a dummy version. In terms of customization and accessibility, the scriptlets could be used for hiding sidebars, pop-ups, floating ads, or annoying widgets, force dark mode even on sites that don't support it, expand content areas, force infinite scrolling, adjust text colors and font size, and auto-expand hidden content.

For performance and usability, the scriptlets can block video autoplay, lazy-load images, auto-fill forms with predefined data, enable custom keyboard shortcuts, bypass right-click restrictions, and automatically click confirmation dialogs. The possible actions achievable by injected JavaScript snippets are virtually endless. However, caution is advised, as running untrusted custom scriptlets may cause issues or even introduce some risk.

Slashdot has been covering Harvard's legendary introductory programming course "CS50" since it began setting attendance records in 2014.

But now long-time Slashdot reader theodp brings some news about the course's fate over at Yale. From Yale's student newspaper: After a decade of partnership with Harvard, Yale's CS50 course will no longer be offered starting in fall 2025.... One of Yale's largest computer science courses, jointly taught with Harvard University, was canceled during a monthly faculty meeting after facing budgetary challenges. [Yale's endowment is $40+ billion]... Since Yale started offering the course in 2015, CS50 has consistently seen enrollment numbers in the hundreds and was often the department's largest class.... According to [Yale instructor Ozan] Erat, the original [anonymous] donation that made CS50 possible ended in June 2024, and the cost of employing so many undergraduate learning assistants for the course had become unsustainable.
theodp reminds us that CS50 and its progeny "will continue to live on in all their glory in-person and online at Harvard and edX."

Keynotes at this year's FOSDEM included free AI models and systemd, reports Heise.de — and also a progress report from Miguel Ojeda, supervisor of the Rust integration in the Linux kernel. Only eight people remain in the core team around Rust for Linux... Miguel Ojeda therefore launched a survey among kernel developers, including those outside the Rust community, and presented some of the more important voices in his FOSDEM talk. The overall mood towards Rust remains favorable, especially as Linus Torvalds and Greg Kroah-Hartman are convinced of the necessity of Rust integration. This is less about rapid progress and more about finding new talent for kernel development in the future.
The reaction was mostly positive, judging by Ojeda's slides:

- "2025 will be the year of Rust GPU drivers..." — Daniel Almedia

- "I think the introduction of Rust in the kernel is one of the most exciting development experiments we've seen in a long time." — Andrea Righi

- "[T]he project faces unique challenges. Rust's biggest weakness, as a language, is that relatively few people speak it. Indeed, Rust is not a language for beginners, and systems-level development complicates things even more. That said, the Linux kernel project has historically attracted developers who love challenging software — if there's an open source group willing to put the extra effort for a better OS, it's the kernel devs." — Carlos Bilbao

- "I played a little with [Rust] in user space, and I just absolutely hate the cargo concept... I hate having to pull down other code that I do not trust. At least with shared libraries, I can trust a third party to have done the build and all that... [While Rust should continue to grow in the kernel], if a subset of C becomes as safe as Rust, it may make Rust obsolete..." Steven Rostedt

Rostedt wasn't sure if Rust would attract more kernel contributors, but did venture this opinion. "I feel Rust is more of a language that younger developers want to learn, and C is their dad's language."

But still "contention exists within the kernel development community between those pro-Rust and -C camps," argues The New Stack, citing the latest remarks from kernel maintainer Christoph Hellwig (who had earlier likened the mixing of Rust and C to cancer). Three days later Hellwig reiterated his position again on the Linux kernel mailing list: "Every additional bit that another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language completely breaks this. You might not like my answer, but I will do everything I can do to stop this. This is NOT because I hate Rust. While not my favourite language it's definitively one of the best new ones and I encourage people to use it for new projects where it fits. I do not want it anywhere near a huge C code base that I need to maintain."
But the article also notes that Google "has been a staunch supporter of adding Rust to the kernel for Linux running in its Android phones." The use of Rust in the kernel is seen as a way to avoid memory vulnerabilities associated with C and C++ code and to add more stability to the Android OS. "Google's wanting to replace C code with Rust represents a small piece of the kernel but it would have a huge impact since we are talking about billions of phones," Ojeda told me after his talk.

In addition to Google, Rust adoption and enthusiasm for it is increasing as Rust gets more architectural support and as "maintainers become more comfortable with it," Ojeda told me. "Maintainers have already told me that if they could, then they would start writing Rust now," Ojeda said. "If they could drop C, they would do it...."

Amid the controversy, there has been a steady stream of vocal support for Ojeda. Much of his discussion also covered statements given by advocates for Rust in the kernel, ranging from lead developers of the kernel and including Linux creator Linus Torvalds himself to technology leads from Red Hat, Samsung, Google, Microsoft and others.

"It is now 45+ years since C++ was first conceived," writes 74-year-old C++ creator Bjarne Stroustrup in an article this week for Communications of the ACM. But he complains that many developers "use C++ as if it was still the previous millennium," in an article titled 21st Century C++ that promises "the key concepts on which performant, type safe, and flexible C++ software can be built: resource management, life-time management, error-handling, modularity, and generic programming...

"At the end, I present ways to ensure that code is contemporary, rather than relying on outdated, unsafe, and hard-to-maintain techniques: guidelines and profiles." To help developers focus on effective use of contemporary C++ and avoid outdated "dark corners" of the language, sets of guidelines have been developed. Here I focus on the C++ Core guidelines that I consider the most ambitious... My principal aim is a type-safe and resource-safe use of ISO standard C++. That is:

- Every object is exclusively used according to its definition
- No resource is leaked

This encompasses what people refer to as memory safety and much more. It is not a new goal for C++. Obviously, it cannot be achieved for every use of C++, but by now we have years of experience showing that it can be done for modern code, though so far enforcement has been incomplete... When thinking about C++, it is important to remember that C++ is not just a language but part of an ecosystem consisting of implementations, libraries, tools, teaching, and more.
WG21 (and others) are working on "profiles" to enforce guidelines (though they're "not yet available, except for experimental and partial versions"). But Stroustrup writes that the C++ Core Guidelines "use a strategy known as subset-of-superset." First: extend the language with a few library abstractions: use parts of the standard library and add a tiny library to make use of the guidelines convenient and efficient (the Guidelines Support Library, GSL).
Next: subset: ban the use of low-level, inefficient, and error-prone features.

What we get is "C++ on steroids": Something simple, safe, flexible, and fast; rather than an impoverished subset or something relying on massive run-time checking. Nor do we create a language with novel and/or incompatible features. The result is 100% ISO standard C++. Messy, dangerous, low-level features can still be enabled and used when needed.
Stroustrup writes that the C++ Core Guidelines focus on rules "we hope that everyone eventually could benefit from."

• No uninitialized variables

• No range or nullptr violations

• No resource leaks

• No dangling pointers

• No type violations

• No invalidation

Bjarne Stroustrup answered questions from Slashdot readers in 2014...

The Register's Thomas Claburn reports: Google's overhaul of Chrome's extension architecture continues to pose problems for developers of ad blockers, content filters, and privacy tools. [...] While Google's desire to improve the security, privacy, and performance of the Chrome extension platform is reasonable, its approach -- which focuses on code and permissions more than human oversight -- remains a work-in-progress that has left extension developers frustrated.

Alexei Miagkov, senior staff technology at the Electronic Frontier Foundation, who oversees the organization's Privacy Badger extension, told The Register, "Making extensions under MV3 is much harder than making extensions under MV2. That's just a fact. They made things harder to build and more confusing." Miagkov said with Privacy Badger the problem has been the slowness with which Google addresses gaps in the MV3 platform. "It feels like MV3 is here and the web extensions team at Google is in no rush to fix the frayed ends, to fix what's missing or what's broken still." According to Google's documentation, "There are currently no open issues considered a critical platform gap," and various issues have been addressed through the addition of new API capabilities.

Miagkov described an unresolved problem that means Privacy Badger is unable to strip Google tracking redirects on Google sites. "We can't do it the correct way because when Google engineers design the [chrome.declarativeNetRequest API], they fail to think of this scenario," he said. "We can do a redirect to get rid of the tracking, but it ends up being a broken redirect for a lot of URLs. Basically, if the URL has any kind of query string parameters -- the question mark and anything beyond that -- we will break the link." Miagkov said a Chrome developer relations engineer had helped identify a workaround, but it's not great. Miagkov thinks these problems are of Google's own making -- the company changed the rules and has been slow to write the new ones. "It was completely predictable because they moved the ability to fix things from extensions to themselves," he said. "And now they need to fix things and they're not doing it."

The Register's Thomas Claburn reports: Oracle this week asked the US Patent and Trademark Office (USPTO) to partially dismiss a challenge to its JavaScript trademark. The move has been criticized as an attempt to either stall or water down legal action against the database goliath over the programming language's name. Deno Land, the outfit behind the Deno JavaScript runtime, filed a petition with the USPTO back in November in an effort to make the trademarked term available to the JavaScript community. This legal effort is led by Node.js creator and Deno Land CEO Ryan Dahl, summarized on the JavaScript.tm website, and supported by more than 16,000 members of the JavaScript community. It aims to remove the fear of an Oracle lawsuit for using the term "JavaScript" in a conference title or business venture.

"Programmers working with JavaScript have formed innumerable community organizations," the website explains. "These organizations, like the standards bodies, have been forced to painstakingly avoid naming the programming language they are built around -- for example, JSConf. Sadly, without risking a legal trademark challenge against Oracle, there can be no 'JavaScript Conference' nor a 'JavaScript Specification.' The world's most popular programming language cannot even have a conference in its name." [...] In the initial trademark complaint, Deno Land makes three arguments to invalidate Oracle's ownership of "JavaScript." The biz claims that JavaScript has become a generic term; that Oracle committed fraud in 2019 when it applied to renew its trademark; and that Oracle has abandoned its trademark because it does not offer JavaScript products or services.

Oracle's motion on Monday focuses on the dismissal of the fraud claim, while arguing that it expects to prevail on the other two claims, citing corporate use of the trademarked term "in connection with a variety of offerings, including its JavaScript Extension Toolkit as well as developer's guides and educational resources, and also that relevant consumers do not perceive JavaScript as a generic term." The fraud claim follows from Deno Land's assertion that the material Oracle submitted in support of its trademark renewal application has nothing to do with any Oracle product. "Oracle, through its attorney, submitted specimens showing screen captures of the Node.js website, a project created by Ryan Dahl, Petitioner's Chief Executive Officer," the trademark cancellation petition says. "Node.js is not affiliated with Oracle, and the use of screen captures of the 'nodejs.org' website as a specimen did not show any use of the mark by Oracle or on behalf of Oracle."

Oracle contends that in fact it submitted two specimens to the USPTO -- a screenshot from the Node.js website and another from its own Oracle JavaScript Extension Toolkit. And this, among other reasons, invalidates the fraud claim, Big Red's attorneys contend. "Where, as here, Registrant 'provided the USPTO with [two specimens]' at least one of which shows use of the mark in commerce, Petitioner cannot plausibly allege that the inclusion of a second, purportedly defective specimen, was material," Oracle's motion argues, adding that no evidence of fraudulent intent has been presented. Beyond asking the court to toss the fraud claim, Oracle has requested an additional thirty days to respond to the other two claims.

NetChoice has filed (PDF) its 10th lawsuit challenging state internet regulations, this time opposing Maryland's Age-Appropriate Design Code Act. The Verge's Lauren Feiner reports: NetChoice has become one of the fiercest -- and most successful -- opponents of age verification, moderation, and design code laws, all of which would put new obligations on tech platforms and change how users experience the internet. [...] NetChoice's latest suit opposes the Maryland Age-Appropriate Design Code Act, a rule that echoes a California law of a similar name. In the California litigation, NetChoice notched a partial win in the Ninth Circuit Court of Appeals, which upheld the district court's decision to block a part of the law requiring platforms to file reports about their services' impact on kids. (It sent another part of the law back to the lower court for further review.)

A similar provision in Maryland's law is at the center of NetChoice's complaint. The group says that Maryland's reporting requirement lets regulators subjectively determine the "best interests of children," inviting "discriminatory enforcement." The reporting requirement on tech companies essentially mandates them "to disparage their services and opine on far-ranging and ill-defined harms that could purportedly arise from their services' 'design' and use of information," NetChoice alleges. NetChoice points out that both California and Maryland have passed separate online privacy laws, which NetChoice Litigation Center director Chris Marchese says shows that "lawmakers know how to write laws to protect online privacy when what they want to do is protect online privacy."

Supporters of the Maryland law say legislators learned from California's challenges and "optimized" their law to avoid questions about speech, according to Tech Policy Press. In a blog analyzing Maryland's approach, Future of Privacy Forum points out that the state made some significant changes from California's version -- such as avoiding an "express obligationâ to determine users' ages and defining the "best interests of children." The NetChoice challenge will test how well those changes can hold up to First Amendment scrutiny. NetChoice has consistently maintained that even well-intentioned attempts to protect kids online are likely to backfire. Though the Maryland law does not explicitly require the use of specific age verification tools, Marchese says it essentially leaves tech platforms with a no-win decision: collect more data on users to determine their ages and create varied user experiences or cater to the lowest common denominator and self-censor lawful content that might be considered inappropriate for its youngest users. And similar to its arguments in other cases, Marchese worries that collecting more data to identify users as minors could create a "honey pot" of kids' information, creating a different problem in attempting to solve another.