Software engineer Sergey Tselovalnikov weighs in on the new hype: The term caught on and Twitter quickly flooded with posts about how AI has radically transformed coding and will soon replace all software engineers. While AI undeniably impacts the way we write code, it hasn't fundamentally changed our role as engineers. Allow me to explain. [...] Vibe coding is interacting with the codebase via prompts. As the implementation is hidden from the "vibe coder", all the engineering concerns will inevitably get ignored. Many of the concerns are hard to express in a prompt, and many of them are hard to verify by only inspecting the final artifact. Historically, all engineering practices have tried to shift all those concerns left -- to the earlier stages of development when they're cheap to address. Yet with vibe coding, they're shifted very far to the right -- when addressing them is expensive. The question of whether an AI system can perform the complete engineering cycle and build and evolve software the same way a human can remains open. However, there are no signs of it being able to do so at this point, and if it one day happens, it won't have anything to do with vibe coding -- at least the way it's defined today. [...] It is possible that there'll be a future where software is built from vibe-coded blocks, but the work of designing software able to evolve and scale doesn't go away. That's not vibe engineering -- that's just engineering, even if the coding part of it will look a bit different.

Read more of this story at Slashdot.

Learning to code has become sort of become pointless as AI increasingly dominates programming tasks, said Replit founder and chief executive Amjad Masad. "I no longer think you should learn to code," Masad wrote on X. The statement comes as major tech executives report significant AI inroads into software development. Google CEO Sundar Pichai recently revealed that 25% of new code at the tech giant is AI-generated, though still reviewed by engineers. Furthermore, Anthropic CEO Dario Amodei predicted AI could generate up to 90% of all code within six months. Masad called this shift a "bittersweet realization" after spending years popularizing coding through open-source work, Codecademy, and Replit -- a platform that now uses AI to help users build apps and websites. Instead of syntax-focused programming skills, Masad recommends learning "how to think, how to break down problems... how to communicate clearly, with humans and with machines."

Read more of this story at Slashdot.

As Rust approaches its 10th anniversary, "there is an important piece of documentation missing that many other languages provide," notes the Rust Foundation. While there's documentation and tutorials — there's no official language specification: In December 2022, an RFC was submitted to encourage the Rust Project to begin working on a specification. After much discussion, the RFC was approved in July 2023, and work began. Initially, the Rust Project specification team (t-spec) were interested in creating the document from scratch using the Rust Reference as a guiding marker. However, the team knew there was already an external Rust specification that was being used successfully for compiler qualification purposes — the FLS. Thank Berlin-based Ferrous Systems, a Rust-based consultancy who assembled that description "some years ago," according to a post on the Rust blog: They've since been faithfully maintaining and updating this document for new versions of Rust, and they've successfully used it to qualify toolchains based on Rust for use in safety-critical industries. [The Rust Foundation notes it part of the consultancy's "Ferrocene" Rust compiler/toolchain.] Seeing this success, others have also begun to rely on the FLS for their own qualification efforts when building with Rust. The Rust Foundation explains: The FLS provides a structured and detailed reference for Rust's syntax, semantics, and behavior, serving as a foundation for verification, compliance, and standardization efforts. Since Rust did not have an official language specification back then, nor a plan to write one, the FLS represented a major step toward describing Rust in a way that aligns with industry requirements, particularly in high-assurance domains. And the Rust Project is "passionate about shipping high quality tools that enable people to build reliable software at scale," adds the Rust blog. So... It's in that light that we're pleased to announce that we'll be adopting the FLS into the Rust Project as part of our ongoing specification efforts. This adoption is being made possible by the gracious donation of the FLS by Ferrous Systems. We're grateful to them for the work they've done in assembling the FLS, in making it fit for qualification purposes, in promoting its use and the use of Rust generally in safety-critical industries, and now, for working with us to take the next step and to bring the FLS into the Project. With this adoption, we look forward to better integrating the FLS with the processes of the Project and to providing ongoing and increased assurances to all those who use Rust in safety-critical industries and, in particular, to those who use the FLS as part of their qualification efforts. More from the Rust Foundation: The t-spec team wanted to avoid potential confusion from having two highly visible Rust specifications in the industry and so decided it would be worthwhile to try to integrate the FLS with the Rust Reference to create the official Rust Project specification. They approached Ferrous Systems, which agreed to contribute its FLS to the Rust Project and allow the Rust Project to take over its development and management... This generous donation will provide a clearer path to delivering an official Rust specification. It will also empower the Rust Project to oversee its ongoing evolution, providing confidence to companies and individuals already relying on the FLS, and marking a major milestone for the Rust ecosystem. "I really appreciate Ferrous taking this step to provide their specification to the Rust Project," said Joel Marcey, Director of Technology at the Rust Foundation and member of the t-spec team. "They have already done a massive amount of legwork...." This effort will provide others who require a Rust specification with an official, authoritative reference for their work with the Rust programming language... This is an exciting outcome. A heartfelt thank you to the Ferrous Systems team for their invaluable contribution! Marcey said the move allows the team "to supercharge our progress in the delivery of an official Rust specification." And the co-founder of Ferrous Systems, Felix Gilcher, also sounded excited. "We originally created the Ferrocene Language Specification to provide a structured and reliable description of Rust for the certification of the Ferrocene compiler. As an open source-first company, contributing the FLS to the Rust Project is a logical step toward fostering the development of a unified, community-driven specification that benefits all Rust users."

Read more of this story at Slashdot.

Longtime Slashdot reader frank_adrian314159 writes: According to an article in Wired, Elon Musk has appointed a team of technologists from DOGE to "rewrite the code that runs the SSA in months." This codebase has over 60 million lines of COBOL and handles record keeping for all American workers and payments for all Social Security recipients. Given that the code has to track the byzantine regulations dealing with Social Security, it's no wonder that the codebase is this large. What is in question though is whether a small team can rewrite this code "in months." After all, what could possibly go wrong? "The project is being organized by Elon Musk lieutenant Steve Davis ... and aims to migrate all SSA systems off COBOL ... and onto a more modern replacement like Java within a scheduled tight timeframe of a few months," notes Wired. "Under any circumstances, a migration of this size and scale would be a massive undertaking, experts tell WIRED, but the expedited deadline runs the risk of obstructing payments to the more than 65 million people in the US currently receiving Social Security benefits." In 2017, SSA announced a plan to modernize its core systems with a timeline of around five years. However, the work was "pivoted away" because of the pandemic.

Read more of this story at Slashdot.

Computer programming jobs in the US have declined by more than a quarter over the past two years, placing the profession among the 10 hardest-hit occupations of 420-plus jobs tracked by the Bureau of Labor Statistics and potentially signaling the first concrete evidence of artificial intelligence replacing workers. The timing coincides with OpenAI's release of ChatGPT in late 2022. Anthropic researchers found people use AI to perform programming tasks more than those of any other job, though 57 percent of users employ AI to augment rather than automate work. "Without getting hysterical, the unemployment jump for programming really does look at least partly like an early, visible labor market effect of AI," said Mark Muro of the Brookings Institution. While software developer positions have remained stable with only a 0.3 percent decline, programmers who perform more routine coding from specifications provided by others have seen their ranks diminish to levels not seen since 1980. Economists caution that high interest rates and post-pandemic tech industry contraction have also contributed to the decline in programming jobs, which typically pay $99,700 compared to $132,270 for developers.

Read more of this story at Slashdot.

Y Combinator CEO Garry Tan said startups are reaching $1-10 million annual revenue with fewer than 10 employees due to "vibe coding," a term coined by OpenAI cofounder Andrej Karpathy in February. "You can just talk to the large language models and they will code entire apps," Tan told CNBC (video). "You don't have to hire someone to do it, you just talk directly to the large language model that wrote it and it'll fix it for you." What would've once taken "50 or 100" engineers to build, he believes can now be accomplished by a team of 10, "when they are fully vibe coders." He adds: "When they are actually really, really good at using the cutting edge tools for code gen today, like Cursor or Windsurf, they will literally do the work of 10 or 100 engineers in the course of a single day." According to Tan, 81% of Y Combinator's current startup batch consists of AI companies, with 25% having 95% of their code written by large language models. Despite limitations in debugging capabilities, Tan said the technology enables small teams to perform work previously requiring dozens of engineers and makes previously overlooked niche markets viable for software businesses.

Read more of this story at Slashdot.

Most mobile apps fail to reach $1,000 in monthly revenue within their first two years, according to a new report from RevenueCat examining data from over 75,000 mobile apps. Across all categories, only about 20% of apps achieve the $1,000 threshold, while just 5% reach $10,000 monthly. In 2025, the top 5% of apps generate 500 times more revenue than the remaining 95% -- up from 200 times in 2024. After one year, elite performers in gaming, photo and video, health and fitness, and social categories exceed $5,000 monthly, while those in the 25th percentile earn a meager $5-20 per month. The report also highlights North American developers' heavy iOS dependence, with 76.1% making over 80% of their revenue from Apple's platform. Subscription retention presents another challenge, with barely 10% of monthly subscribers staying beyond the first year.

Read more of this story at Slashdot.

Tuesday Microsoft "surprised everyone," writes Neowin, "by announcing a new change that will radically improve TypeScript performance" — porting TypeScript to Go. InfoWorld writes that "The initiative promises dramatic improvements in editor startup speed, build times, and memory usage, making it easier to scale TypeScript to large code bases, Microsoft said." Microsoft's TypeScript team expects to be able to preview command-line type-checking in Go-based tsc by mid-2025, and to deliver a feature-complete Go implementation of TypeScript by the end of the year. [You can build and run the Go code now from Microsoft's new working repository.] Developers who use Go-based TypeScript in the Visual Studio Code editor will feel the increased speed in the editor, Microsoft said. The company promises an 8x improvement in project load times, instant comprehensive error listings across entire projects, and greater responsiveness for all language service operations including completion lists, quick information, go to definition, and find all references. The new TypeScript will also support more advanced refactoring and deeper insights that were previously too expensive to compute, the company said. Microsoft believes native Go implementations reduce build times by up to 10x, notes Neowin. But "Developers can expect TypeScript 6.0 to have some deprecations and breaking changes to support the upcoming Go-based version." Later this year, Microsoft will be releasing this new native Go implementation as TypeScript 7.0. The current JS-based TypeScript codebase will continue development into the 6.x series until TypeScript 7+ reaches sufficient maturity and adoption, since some projects may depend on certain API features, legacy configurations, or other things that are not supported by TypeScript 7+. TypeScript's original creator Anders Hejlsberg recorded an announcement video — and also shared his thoughts in a GitHub discussion titled simply... "Why Go?" The TypeScript compiler's move to Go was influenced by specific technical requirements, such as the need for structural compatibility with the existing JavaScript-based codebase, ease of memory management, and the ability to handle complex graph processing efficiently. After evaluating numerous languages and making multiple prototypes — including in C# — Go emerged as the optimal choice... Let's be real. Microsoft using Go to write a compiler for TypeScript wouldn't have been possible or conceivable in years past. However, over the last few decades, we've seen Microsoft's strong and ongoing commitment to open-source software, prioritizing developer productivity and community collaboration above all. Our goal is to empower developers with the best tools available, unencumbered by internal politics or narrow constraints. This freedom to choose the right tool for each specific job ultimately benefits the entire developer community, driving innovation, efficiency, and improved outcomes. And you can't argue with a 10x outcome! Hejlsberg also addressed their choice of Go in an online interview with the Michigan TypeScript meetup.

Read more of this story at Slashdot.

IBM CEO Arvind Krishna has publicly disagreed with Anthropic CEO Dario Amodei's prediction that AI will write 90% of code within 3-6 months, estimating instead that only "20-30% of code could get written by AI." "Are there some really simple use cases? Yes, but there's an equally complicated number of ones where it's going to be zero," Krishna said during an onstage interview at SXSW. He argued AI will boost programmer productivity rather than eliminate jobs. "If you can do 30% more code with the same number of people, are you going to get more code written or less?" he asked. "History has shown that the most productive company gains market share, and then you can produce more products."

Read more of this story at Slashdot.

A 55-year-old software developer faces up to 10 years in prison after being convicted for deploying malicious code that sabotaged his former employer's network, causing hundreds of thousands of dollars in losses. Davis Lu was convicted by a jury for causing intentional damage to protected computers owned by power management company Eaton Corp., the US Department of Justice announced Friday. Lu, who worked at Eaton for 11 years, became disgruntled after a 2018 corporate "realignment" reduced his responsibilities. He created malicious code that deleted coworker profile files, prevented logins, and caused system crashes. His most destructive creation was a "kill switch" named "IsDLEnabledinAD" that automatically activated upon his termination in 2019, disrupting Eaton's global operations. Lu admitted to creating some malicious code but plans to appeal the verdict.

Read more of this story at Slashdot.

"TrapC, a fork of the C language, is being developed as a potential solution for memory safety issues that have hindered the C and C++ languages," reports InfoWorld. But also being developed is a compiler named trapc "intended to be implemented as a cybersecurity compiler for C and C++ code, said developer Robin Rowe..." Due by the end of this year, trapc will be a free, open source compiler similar to Clang... Rowe said. TrapC has pointers that are memory-safe, addressing the memory safety issue with the two languages. With TrapC, developers write in C or C++ and compile in TrapC, for memory safety... Rowe presented TrapC at an ISO C meeting this week. Developers can download a TrapC whitepaper and offer Rowe feedback. According to the whitepaper, TrapC's memory management is automatic and cannot leak memory. Pointers are lifetime-managed, not garbage-collected. Also, TrapC reuses a few code safety features from C++, notably member functions, constructors, destructors, and the new keyword. "TrapC Memory Safe Pointers will not buffer overrun and will not segfault," Rowe told the ISO C Committee standards body meeting, according to the Register. "When C code is compiled using a TrapC compiler, all pointers become Memory Safe Pointers and are checked." In short, TrapC "is a programming language forked from C, with changes to make it LangSec and Memory Safe," according to that white paper. "To accomplish that, TrapC seeks to eliminate all Undefined Behavior in the C programming language..." "The startup TRASEC and the non-profit Fountain Abode have a TrapC compiler in development, called trapc," the whitepaper adds, and their mission is "to enable recompiling legacy C code into executables that are safe by design and secure by default, without needing much code refactoring... The TRASEC trapc cybersecurity compiler with AI code reasoning is expected to release as free open source software sometime in 2025." In November the Register offered some background on the origins of TrapC...

Read more of this story at Slashdot.

Memory safety bugs are "eroding trust in technology and costing billions," argues a new post on Google's security blog — adding that "traditional approaches, like code auditing, fuzzing, and exploit mitigations — while helpful — haven't been enough to stem the tide." So the blog post calls for a "common framework" for "defining specific, measurable criteria for achieving different levels of memory safety assurance." The hope is this gives policy makers "the technical foundation to craft effective policy initiatives and incentives promoting memory safety" leading to "a market in which vendors are incentivized to invest in memory safety." ("Customers will be empowered to recognize, demand, and reward safety.") In January the same Google security researchers helped co-write an article noting there are now strong memory-safety "research technologies" that are sufficiently mature: memory-safe languages (including "safer language subsets like Safe Buffers for C++"), mathematically rigorous formal verification, software compartmentalization, and hardware and software protections. (With hardware protections including things like ARM's Memory Tagging Extension and the (Capability Hardware Enhanced RISC Instructions, or "CHERI", architecture.) Google's security researchers are now calling for "a blueprint for a memory-safe future" — though Importantly, the idea is "defining the desired outcomes rather than locking ourselves into specific technologies." Their blog post this week again urges a practical/actionable framework that's commonly understood, but one that supports different approaches (and allowing tailoring to specific needs) while enabling objective assessment: At Google, we're not just advocating for standardization and a memory-safe future, we're actively working to build it. We are collaborating with industry and academic partners to develop potential standards, and our joint authorship of the recent CACM call-to-action marks an important first step in this process... This commitment is also reflected in our internal efforts. We are prioritizing memory-safe languages, and have already seen significant reductions in vulnerabilities by adopting languages like Rust in combination with existing, wide-spread usage of Java, Kotlin, and Go where performance constraints permit. We recognize that a complete transition to those languages will take time. That's why we're also investing in techniques to improve the safety of our existing C++ codebase by design, such as deploying hardened libc++. This effort isn't about picking winners or dictating solutions. It's about creating a level playing field, empowering informed decision-making, and driving a virtuous cycle of security improvement... The journey towards memory safety requires a collective commitment to standardization. We need to build a future where memory safety is not an afterthought but a foundational principle, a future where the next generation inherits a digital world that is secure by design. The security researchers' post calls for "a collective commitment" to eliminate memory-safety bugs, "anchored on secure-by-design practices..." One of the blog post's subheadings? "Let's build a memory-safe future together." And they're urging changes "not just for ourselves but for the generations that follow."

Read more of this story at Slashdot.

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

Read more of this story at Slashdot.

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

Read more of this story at Slashdot.

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.

Read more of this story at Slashdot.

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

Read more of this story at Slashdot.

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.

Read more of this story at Slashdot.

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

Read more of this story at Slashdot.

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.

Read more of this story at Slashdot.