Long-time Slashdot reader sosume quotes the Register: Redox OS, written in Rust and currently under development, is only "a few months of work away" from self-hosting, meaning that the Rustc compiler would run on Redox itself, according to its creator Jeremy Soller...

Redox has a POSIX-compliant C library written in Rust, called relibc. It is Linux-compatible both at the syscall API level and at the syscall ABI (Application binary interface) level, subject to the same architecture.
The article notes that the OS's latest release was version 0.5 last March, arguing that it's "best described as experimental..."

"Still, if Rust continues to grow in popularity, its characteristics of safety and unimpeded performance seem ideal for creating a new operating system, so perhaps Redox will become more prominent."

By 2037, one quarter of the U.S. for-sale housing stock, or roughly 21 million homes will be vacated by seniors. That is more than twice the number of new properties built during a 10-year period that spanned the last housing bubble [the link may be paywalled]. From a report: Most of these homes will be concentrated in traditional retirement communities in Arizona and Florida, according to Zillow, or parts of the Rust Belt that have been losing population for decades. A more modest infusion of new housing is expected in pricey coastal neighborhoods of New York or San Francisco where younger Americans are still flocking in large numbers. On the face of it, this doesn't sound all bad. Dying homeowners have always needed to be replaced by younger ones and the U.S. has for a number of years suffered from a shortage of housing, a development that has dampened recent home sales activity and kept many millennials stuck in rentals.

But the buyers coming behind the baby boomers, the Gen Xers, are a smaller and more financially precarious generation with different preferences, posing a new kind of test for the housing market. One problem is that the bulk of the supply won't necessarily be in places where these new buyers want to live. Gen Xers and the younger millennials have shown thus far they would rather be in cities or suburbs in major metropolitan areas that offer strong Wi-Fi and plenty of shops and restaurants within walking distance -- like the Frisco suburbs of Dallas or the Capitol Hill neighborhood of Seattle. They have little interest in migrating to planned, age-restricted retirement enclaves in sunnier corners of the U.S. lined with golf courses, community centers and man-made lakes -- like The Villages, a community of 115,000 in central Florida. Innovations such as voice-recognition technology and ride-share drivers are also making it easier for older people to stay in their existing homes and eschew these retirement communities altogether.

"The hit programming language Python has climbed over once-dominant Java to become the second most popular language on Microsoft-owned open-source code-sharing site GitHub," reports ZDNet: Python now outranks Java based on the number of repository contributors, and by that metric Python is now second only to JavaScript, which has been in top spot since 2014, according to GitHub's 'State of the Octoverse' report for 2019...

Another interesting aspect of GitHub's report is its ranking of fastest-growing languages. Google's Dart programming language and Flutter, for building UIs for iOS and Android apps, are getting major traction with developers on GitHub. Dart was the fastest-growing language between 2018 and 2019, with usage up a massive 532%. It was followed by the Mozilla-developed Rust, which grew a respectable 235%. Microsoft is experimenting with Rust in its Windows code base because it was designed to address memory-related security bugs -- the dominant flaw-type in Microsoft software over the past decade.

Last year Kotlin, the Google-endorsed programming language for Android app development, was the fastest-growing language on GitHub. It's not a top-10 language yet, but it still grew 182% over the year. Microsoft-backed TypeScript, its superset of JavaScript, is also growing fast, up 161% over the past year as more developers use it to grapple with large-scale JavaScript apps.

Other languages making up the top 10 fastest-growing category are HCL, PowerShell, Apex, Python, Assembly, and Go.

Microsoft gave a status update today on its experiments on using the Rust programming language instead of C and C++ to write Windows components. From a report: Microsoft began experimenting with Rust over the summer. The Redmond-based software giant said it was interested in Rust because, over the past decade, more than 70% of the security patches it shipped out fixed memory-related bugs, an issue that Rust was created to address.

[...] Today, almost four months later, we got the first feedback. "I've been tasked with an experimental rewrite of a low-level system component of the Windows codebase (sorry, we can't say which one yet)," said Adam Burch, Software Engineer at the Microsoft Hyper-V team, in a blog post today. "Though the project is not yet finished, I can say that my experience with Rust has been generally positive," Burch added. "In general, new components or existing components with clean interfaces will be the easiest to port to Rust," the Microsoft engineer said. However, not all things went smoothly. It would have been unrealistic if we expected they would. Burch cited the lack of safe transmutation, safe support for C style unions, fallible allocation, and a lack of support for at-scale unit testing, needed for Microsoft's sprawling code-testing infrastructure.

"Guido van Rossum, the creator of the hugely popular Python programming language, is leaving cloud file storage firm Dropbox and heading into retirement," reports ZDNet: That ends his six and half years with the company, which hired in him in 2013 because so much of its functionality was built on Python. And, after last year stepping down from his leadership role over Python decision making, that means the Python creator is officially retiring....

According to Dropbox, in 2011, when van Rossum first met Dropbox CEO Drew Houston, the Dropbox server and desktop client were written "almost exclusively in Python". Today, Dropbox also relies on Go, TypeScript, and Rust, as well as the open source Mypy static type checker that Dropbox develops to manage Python code at scale. Mypy helps developers overcome the challenge of understanding dynamically typed Python code written by other developers in the past...

Dropbox said van Rossum has had a major impact on its engineering culture. "There was a small number of really smart, really young coders who produced a lot of very clever code that only they could understand," said van Rossum. "That is probably the right attitude to have when you're a really small startup." However, as Dropbox notes, when the company grew, new engineers could not understand the clever but 'short and cryptic' code written by and for earlier developers. Van Rossum called this "cowboy coding culture" and educated the company about the value of maintainable code. "When asked, I would give people my opinion that maintainable code is more important than clever code," he said.... Dropbox also credits van Rossum with sharpening the company's testing processes for its continuous integration program and helping engineers understand why tests were broken.
"Thank you, Guido" is the title of the post on Dropbox's blog announcing the news that van Rossum is now retiring. Sharing that article on Twitter Thursday, van Rossum added "It's bittersweet... I've learned a lot during my time as an engineer here -- e.g. type annotations came from this experience -- and I'll miss working here."

But by Friday he was heading off to the North Bay Python conference in Petaluma, California.

Packt's recent story about Rust had the headline "Rust is the future of systems programming, C is the new Assembly."

But there was an interesting discussion about the story on LWN.net. One reader suggested letting people write drivers for the Linux kernel in Rust. ("There's a good chance that encouraging people to submit their wacky drivers in Rust would improve the quality of the driver, partly because you can focus attention on the unsafe parts.")

And that comment drew an interesting follow-up:

"I spoke with Greg Kroah-Hartman, and he said he'd be willing to accept a framework in the kernel for writing drivers in Rust, as long as 1) for now it wasn't enabled by default (even if you did "make allyesconfig") so that people don't *need* Rust to build the kernel, and 2) it shows real benefits beyond writing C, such as safe wrappers for kernel APIs."

Someone from the Rust language governance team gave an interesting talk at this year's Open Source Technology Summit. Josh Triplett (who is also a principal engineer at Intel), discussed "what Intel is contributing to bring Rust to full parity with C," in a talk titled Intel and Rust: the Future of Systems Programming.

An anonymous reader quotes Packt: Triplett believes that C is now becoming what Assembly was years ago. "C is the new Assembly," he concludes. Developers are looking for a high-level language that not only addresses the problems in C that can't be fixed but also leverage other exciting features that these languages provide. Such a language that aims to be compelling enough to make developers move from C should be memory safe, provide automatic memory management, security, and much more...

"Achieving parity with C is exactly what got me involved in Rust," says Triplett. Triplett's first contribution to the Rust programming language was in the form of the 1444 RFC, which was started in 2015 and got accepted in 2016. This RFC proposed to bring native support for C-compatible unions in Rust that would be defined via a new "contextual keyword" union...

He is starting a working group that will focus on achieving full parity with C. Under this group, he aims to collaborate with both the Rust community and other Intel developers to develop the specifications for the remaining features that need to be implemented in Rust for system programming. This group will also focus on bringing support for systems programming using the stable releases of Rust, not just experimental nightly releases of the compiler.
Last week Triplett posted that the FFI/C Parity working group "is in the process of being launched, and hasn't quite kicked off yet" -- but he promised to share updates when it does.

An anonymous reader quotes The Verge's AI and Robotics reporter: By scanning huge datasets of text, machine learning software can produce convincing samples of everything from short stories to song lyrics. Now, those same techniques are being applied to the world of coding with a new program called Deep TabNine, a "coding autocompleter." Programmers can install it as an add-on in their editor of choice, and when they start writing, it'll suggest how to continue each line, offering small chunks at a time. Think of it as Gmail's Smart Compose feature but for code.

Jacob Jackson, the computer science undergrad at the University of Waterloo who created Deep TabNine, says this sort of software isn't new, but machine learning has hugely improved what it can offer... Earlier this month, he released an updated version that uses a deep learning text-generation algorithm called GPT-2, which was designed by the research lab OpenAI, to improve its abilities. The update has seriously impressed coders, who have called it "amazing," "insane," and "absolutely mind-blowing" on Twitter...

Deep TabNine is trained on 2 million files from coding repository GitHub. It finds patterns in this data and uses them to suggest what's likely to appear next in any given line of code, whether that's a variable name or a function... Most importantly, thanks to the analytical abilities of deep learning, the suggestions Deep TabNine makes are of a high overall quality. And because the software doesn't look at users' own code to make suggestions, it can start helping with projects right from the word go, rather than waiting to get some cues from the code the user writes.
It's not free software. Currently a personal license costs $49 (with a business-use license costing $99), the Verge reports -- but the tool supports the following 22 languages...

Python, JavaScript, Java, C++, C, PHP, Go, C#, Ruby, Objective-C, Rust, Swift, TypeScript, Haskell, OCaml, Scala, Kotlin, Perl, SQL, HTML, CSS, and Bash.

A tiny and relatively unknown TLS library written in Rust, an up-and-coming programming language, outperformed the industry-standard OpenSSL in almost every major category. From a report: The findings are the result of a recent four-part series of benchmarks carried out by Joseph Birr-Pixton, the developer behind the Rustls library. The findings showed that Rustls was 10% faster when setting up and negotiating a new server connection, and between 20 and 40% faster when setting up a client connection. But while handshake speeds for new TLS connections are important, most TLS traffic relies on resuming previously negotiated handshakes. Here, too, Rustls outperformed the aging OpenSSL, being between 10 and 20% in resuming a connection on the server-side, and being between 30 and 70% quicker to resume a client connection. Furthermore, Rustls also fared better in sheer bulk performance -- or the speed at which data is transferred over the TLS connection. Birr-Pixton said Rustls could send data 15% faster than OpenSSL, and receive it 5% faster as well.

Microsoft plans to explore using the Rust programming language as an alternative to C, C++, and others, as a way to improve the security posture of its and everyone else's apps. From a report: The announcement was made yesterday by Gavin Thomas, Principal Security Engineering Manager for the Microsoft Security Response Center (MSRC). "You're probably used to thinking about the Microsoft Security Response Center as a group that responds to incidents and vulnerabilities," Thomas said. "We are a response organization, but we also have a proactive role, and in a new blog series we will highlight Microsoft's exploration of safer system programming languages, starting with Rust." The end game is to find a way to move developers from the aging C and C++ programming language to so-called "memory-safe languages." Memory-safe languages, such as Rust, are designed from the ground up with protections against memory corruption vulnerabilities, such as buffer overflows, race conditions, memory leaks, use-after free and memory pointer-related bugs.

The Brave web browser "claims to have delivered a '69x average improvement' in its ad-blocking technology using Rust in place of C++" reports ZDNet.

They cite a blog post by Brave performance researcher Dr. Andrius Aucinas and Brave's chief scientist Dr. Ben Livshits: The improvements can be experienced in its experimental developer and nightly channel releases... "We implemented the new engine in Rust as a memory-safe, performant language compilable down to native code and suitable to run within the native browser core as well as being packaged in a standalone Node.js module," the two Brave scientists said. The new engine means the Chromium-based browser can cut the average request classification time down to 5.6 microseconds, a unit of time that's equal to a millionth of one second.

Aucinas and Livshits argue that the micro-improvements in browser performance might not seem significant to end users but do translate to good things for a computer's main processor. "Although most users are unlikely to notice much of a difference in cutting the ad-blocker overheads, the 69x reduction in overheads means the device CPU has so much more time to perform other functions," the pair explain.
Their blog post notes that loading a web page today can be incredibly complex. "Since loading an average website involves 75 requests that need to be checked against tens of thousands of rules, it must also be efficient."

"JetBrains released its State of Developer Ecosystem 2019 report, which found while Java is still the most popular primary language and JavaScript is the most used overall, Python is gaining speed," reports SD Times: The report surveyed about 7,000 developers worldwide, and revealed Python is the most studied programming language, the most loved language, and the third top primary programming language developers are using... The top use cases developers are using Python for include data analysis, web development, machine learning and writing automation scripts, according to the JetBrains report. More developers are also beginning to move over to Python 3, with 9 out of 10 developers using the current version.

The JetBrains report also found while Go is still a young language, it is the most promising programming language. "Go started out with a share of 8% in 2017 and now it has reached 18%. In addition, the biggest number of developers (13%) chose Go as a language they would like to adopt or migrate to," the report stated...

Seventy-three percent of JavaScript developers use TypeScript, which is up from 17 percent last year. Seventy-one percent of Kotlin developers use Kotlin for work. Java 8 is still the most popular programming language, but developers are beginning to migrate to Java 10 and 11.
JetBrains (which designed Kotlin in 2011) also said that 60% of their survey's respondents identified themselves as professional web back-end developers (while 46% said they did web front-end, and 23% developed mobile applications). 41% said they hadn't contributed to open source projects "but I would like to," while 21% said they contributed "several times a year."

"16% of developers don't have any tests in their projects. Among fully-employed senior developers though, that statistic is just 8%. Like last year, about 30% of developers still don't have unit tests in their projects." Other interesting statistics:

• 52% say they code in their dreams.

• 57% expect AI to replace developers "partially" in the future.

• "83% prefer the Dark theme for their editor or IDE. This represents a growth of 6 percentage points since last year for each environment.

• 47% take public transit to work.

And 97% of respondents using Rust "said they have been using Rust for less than a year. With only 14% using it for work, it's much more popular as a language for personal/side projects." And more than 90% of the Rust developers who responded worked with codebases with less than 300 files.

Russ Cox (along with Rob Pike) is the tech lead for Google's Go team and its Go project. This week he responded on the Google group golang-nuts to a blogger who'd argued that "Go is Google's language, not ours."

First Cox points to a talk at Gophercon 2015 -- and its accompanying blog post -- which argued that Go's open source status is critical to its long-term success. He noted this week that "good ideas come from outside Google as often as they come from inside Google.... But getting to yes on every suggested new feature is not and never has been a goal." No one can speak for the entire Go community: it is large, it contains multitudes. As best we can, we try to hear all the many different perspectives of the Go community. We encourage bug reports and experience reports, and we run the annual Go user survey, and we hang out here on golang-nuts and on gophers slack precisely because all those mechanisms help us hear you better. We try to listen not just to the feature requests but the underlying problems people are having, and we try, as I said in the Gophercon talk, to find the small number of changes that solve 90% of the problems instead of the much more complex solution that gets to 99%. We try to add as little as possible to solve as much as possible.

In short, we aim to listen to everyone's problems and address as many of them as possible, but at the same time we don't aim to accept everyone's offered solutions. Instead we aim to create space for thoughtful discussions about the offered solutions and revisions to them, and to work toward a consensus about how to move forward...

The "proposal review" group meets roughly weekly to review proposal issues and make sure the process is working. We handle trivial yes and trivial no answers, but our primary job is to shepherd suggested proposals, bring in the necessary voices, and make sure discussions are proceeding constructively. We have talked in the past about whether to explicitly look for people outside Google to sit in our weekly meeting, but if that's really important, then we are not doing our job right. Again, our primary job is to make sure the issues get appropriate discussion on the issue tracker, where everyone can participate, and to lead that discussion toward a solution with broad agreement and acceptance. If you skim through any of the accepted proposals you will see how we spend most of our meetings nudging conversations along and trying to make sure we hear from everyone who has a stake in a particular decision.

It remains an explicit goal to enable anyone with a good piece of code or a good idea to be able to contribute it to the project, and we've continued to revise both the code contribution and proposal contribution docs as we find gaps. But as I said in 2015, the most important thing we the original authors of Go can do is to provide consistency of vision, to keep Go feeling like a coherent system, to keep Go Go. People may disagree with individual decisions. We may get some flat wrong. But we hope that the overall result still works well for everyone, and the decision process we have seems far more likely to preserve a coherent, understandable system than a standards committee or other process.
His conclusion? The Go language belongs to the Go community -- and, because it's open source, "the freedom to fork hopefully keeps me and the other current Go leadership honest."

"Release 8.3 of GDB, the GNU Debugger, is now available," according to an announcement on the info-gnu mailing list:

GDB is a source-level debugger for Ada, C, C++, Go, Rust, and many other languages. GDB can target (i.e., debug programs running on) more than a dozen different processor architectures, and GDB itself can run on most popular GNU/Linux, Unix and Microsoft Windows variants. GDB is free (libre) software. GDB 8.3 includes support for new native configurations (also available as a target configuration) for RISC-V GNU/Linux and RISC-V FreeBSD.

The announcement warns that Native Windows debugging "is only supported on Windows XP or later," and that "the Python API in GDB now requires Python 2.6 or later."

Alex Gaynor is a software engineer at Mozilla working on Firefox, after previously serving as a director of both the Python Software Foundation and the Django Software Foundation.

In a new blog post today, he argues that memory unsafe languages, "principally C and C++," induce an exceptional number of security vulnerabilities, and that the industry needs to migrate to memory-safe languages like Rust and Swift by default. One of the responses I frequently receive is that the problem isn't C and C++ themselves, developers are simply holding them wrong. In particular, I often receive defenses of C++ of the form, "C++ is safe if you don't use any of the functionality inherited from C" or similarly that if you use modern C++ types and idioms you will be immune from the memory corruption vulnerabilities that plague other projects. I would like to credit C++'s smart pointer types, because they do significantly help. Unfortunately, my experience working on large C++ projects which use modern idioms is that these are not nearly sufficient to stop the flood of vulnerabilities...

Modern C++ idioms introduce many changes which have the potential to improve security: smart pointers better express expected lifetimes, std::span ensures you always have a correct length handy, std::variant provides a safer abstraction for unions. However modern C++ also introduces some incredible new sources of vulnerabilities: lambda capture use-after-free, uninitialized-value optionals, and un-bounds-checked span.

My professional experience writing relatively modern C++, and auditing Rust code (including Rust code that makes significant use of unsafe) is that the safety of modern C++ is simply no match for memory safe by default languages like Rust and Swift (or Python and JavaScript, though I find it rare in life to have a program that makes sense to write in either Python or C++). There are significant challenges to migrating existing, large, C and C++ codebases to a different language -- no one can deny this. Nonetheless, the question simply must be how we can accomplish it, rather than if we should try.
The post highlights what he describes as "completely modern C++ idioms which produce vulnerabilities" -- including an example of dangling pointers "despite our meticulous use of smart pointers throughout..."

"Even with the most modern C++ idioms available, the evidence is clear that, at scale, it's simply not possible to hold C++ right."

angel'o'sphere shares a report: The annual Stack Overflow survey is one of the most comprehensive snapshots of how programmers work, with this year's poll being taken by almost 90,000 developers across the globe. This year's survey details which languages developers enjoy using, which are associated with the best paid jobs, which are most commonly used, as well as developers' preferred frameworks, databases, and integrated development environments.

Python's versatility continues to fuel its rise through Stack Overflow's rankings for the "most popular" languages, which lists the languages most widely used by developers. This year's survey finds Python to be the fastest-growing major programming language, with Python edging out Android and enterprise workhorse Java to become the fourth most commonly used language. [...] More importantly for developers, this popularity overlaps with demand for the language, with Julia Silge, data scientist at Stack Overflow, saying that jobs data gathered by Stack Overflow also shows Python to be one of the most in-demand languages sought by employers.

[...] Rust may not have as many users as Python or JavaScript but it has earned a lot of affection from those who use it. For the fourth year running, the language tops Stack Overflow's list of "most-loved" languages, which means the proportion of Rust developers who want to continue working with it is larger than that of any other language.[...] Go stands out as a language that is well paid, while also being sought after and where developers report high levels of job satisfaction. Full report here.

In what may be his final year of technology predictions, columnist Robert X. Cringely argues "I can't say that we're going to see anything beyond more beta tests of self-driving cars in 2019... We simply aren't ready and probably won't be for years to come...."

"The problem isn't with the self-driving cars, it's with the cars that aren't self-driving, cars that are driven by idiots like me." It will eventually happen. Once half the fleet has been replaced with cars that could be self-drivers if we allowed them to be, then there will be a huge financial incentive to get the other half off the street. This will be especially the case if climate change is still accelerating. I'm guessing that most cars from 2020-on could be self-driving with only a software upgrade, which is why Elon Musk is predicting Tesla will have full autonomy by the end of 2019. But notice that Elon isn't predicting Tesla will be allowed to have its cars drive themselves everywhere...

So why is the world talking so much about self-driving cars and full autonomy? Some of it is Tesla hype, some of it is marketing as the car companies try to get us to buy cars that will eventually be self-driving, but probably not until their second owners. And the other reason why we're talking so much about self-driving cars is because Uber is planning to go public later this year...an IPO that will go smoother if the driving public thinks autonomous cars are something that we'll be seeing soon. Uber has a labor problem. If it can spin a story that surly and expensive human drivers are soon to be replaced with electrons, that will be very reassuring to Wall Street. But as I explained, it also isn't true.

The world isn't yet ready -- something Uber and Tesla and all the others will suddenly admit in about a year (post-IPO).
Cringely also argues that the problem isn't just the "millions of drivers who are still controlling their vehicles the old fashion way, which is often in a barely competent fashion..."

"We keep our cars longer because they don't rust and we can't afford to replace them so often. The result is that while we could expect a complete turnover in car technology every decade, now it takes closer to two decades."

Titanium "has long been touted as the metal of the future," writes Dwell, "due to its strength, rust resistance, and amazing lightness." But can careful atom-stacking lead to something better?

An anonymous reader writes: Researchers have discovered a way to create a new "metallic wood" material that is as strong as titanium, but five times lighter, reports Dwell. "So far, the researchers have built a sheet of nickel with nanoscale pores that is almost 70 percent empty space... It was created by building tiny plastic spheres, suspending them in water, allowing the water to evaporate, and then electroplating the spheres with nickel. Researchers then dissolved the plastic spheres, producing an incredibly strong, porous metal that floats on water."
Researchers are also considering the possibility of filling its empty space with an energy-storing material. "For example, a prosthetic leg made from this material and infused with anode and cathode materials, could also be a battery."

An anonymous reader summarizes the changes in Thursday's release of Rust 1.32.0 stable: "Quality of life" improvements include a new dbg macro to easily print values for debugging without having to use a println statement. For example, dbg!(x); prints the filename and line number, as well as the variable's name and value, to stderr (rather than to standard output). Making it even more useful, the macro also returns the value of what it's debugging -- even all the boolean values returned by each execution of an if-then statement.

Rust macros can now match literals of any type (string, numeric, char) -- and the 2018 edition of Rust also allows ? for matching zero or one repetitions of a pattern.

In addition, all integral numeric primitives now provide conversion functions to and from byte-arrays with specified endianness.

merbs writes: Out of the three major sectors of the economy -- agriculture, manufacturing, and service -- two are already largely automated. Farm labor, which about half the American workforce used to do, now comprises around 2 percent of American jobs. And we all know the rust belt song and dance, beat out to outsourcing and mechanization. Which is largely why some 80 percent of all American jobs are service jobs. And this year, quietly but in the open, the robots and their investors came for them, too.

There's a case to be made that 2018 is the year automation took its biggest lunge forward toward our largest pool of human labor: Amazon opened five cashier-less stores; three in Seattle, one in Chicago, and one in San Francisco. Self-ordering kiosks invaded fast food and franchise restaurants in a big way. Smaller robot-centric outfits like the long-awaited auto-burger joint Creator opened, too, and so did a number of others.

In Las Vegas, our service job mecca, hotels' and casinos' widespread plans for automation in everything from bartending to waitstaff to hotel work led one of the city's most powerful hospitality unions to the brink of a 50,000-person strike last summer before a successful negotiation was reached... Combined, they act as a set of markers on a trendline we can no longer ignore. We face the prospect of major upheaval in the last dependable pool of jobs we've got.