Category: programming

In a new interview, he says the site’s been accessed about 50 billion times over the past 14 years — and then shares his thoughts on the notion that programmers could be replaced by no-code, low-code, or AI-driven pair programming:

A: Over the years, there have many, many tools, trying to democratize software development. That’s a very positive thing. I actually love the fact that programming is becoming easier to do with these onramps. I was speaking at Salesforce recently, and they’ve got people in sales organizations writing workflows, and that’s low code. You’ve got all these folks who are not software engineers that are creating their own automations and applications.

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

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

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

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

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

A: This is very much part of our vision….

Stack Overflow’s CEO adds that the site’s hot topics now include blockchain, machine learning, but especially technical cloud questions, “rising probably about 50% year over year over the past 10 years…. Related to this is an increase in interest in containerization and cloud-native services.”

[A] growing movement to write software in a language called Rust is gaining momentum because the code is goof-proof in an important way. By design, developers can’t accidentally create the most common types of exploitable security vulnerabilities when they’re coding in Rust, a distinction that could make a huge difference in the daily patch parade and ultimately the world’s baseline cybersecurity….

[B]ecause Rust produces more secure code [than C] and, crucially, doesn’t worsen performance to do it, the language has been steadily gaining adherents and now is at a turning point. Microsoft, Google, and Amazon Web Services have all been utilizing Rust since 2019, and the three companies formed the nonprofit Rust Foundation with Mozilla and Huawei in 2020 to sustain and grow the language. And after a couple of years of intensive work, the Linux kernel took its first steps last month to implement Rust support. “It’s going viral as a language,” says Dave Kleidermacher, vice president of engineering for Android security and privacy. “We’ve been investing in Rust on Android and across Google, and so many engineers are like, ‘How do I start doing this? This is great’….”

By writing new software in Rust instead, even amateur programmers can be confident that they haven’t introduced any memory-safety bugs into their code…. These types of vulnerabilities aren’t just esoteric software bugs. Research and auditing have repeatedly found that they make up the majority of all software vulnerabilities. So while you can still make mistakes and create security flaws while programming in Rust, the opportunity to eliminate memory-safety vulnerabilities is significant….

“Yes, it’s a lot of work, it will be a lot of work, but the tech industry has how many trillions of dollars, plus how many talented programmers? We have the resources,” says Josh Aas, executive director of the Internet Security Research Group, which runs the memory-safety initiative Prossimo as well as the free certificate authority Let’s Encrypt. “Problems that are merely a lot of work are great.”

Here’s how Dan Lorenc, CEO of the software supply-chain security company Chainguard, explains it to Wired. “Over the decades that people have been writing code in memory-unsafe languages, we’ve tried to improve and build better tooling and teach people how to not make these mistakes, but there are just limits to how much telling people to try harder can actually work.

“So you need a new technology that just makes that entire class of vulnerabilities impossible, and that’s what Rust is finally bringing to the table.”

An earlier post pointed out that “There have been a good amount of changes that have had to have been made to the compiler to get GATs to work,” noting that the request-for-comments for this feature was first opened in 2016.

And Rust’s types team also created a blog post with more detail:
Note that this is really just rounding out the places where you can put generics: for example, you can already have generics on freestanding type aliases and on functions in traits. Now you can just have generics on type aliases in traits (which we just call associated types)….

In general, GATs provide a foundational basis for a vast range of patterns and APIs. If you really want to get a feel for how many projects have been blocked on GATs being stable, go scroll through either the tracking issue: you will find numerous issues from other projects linking to those threads over the years saying something along the lines of “we want the API to look like X, but for that we need GATs” (or see this comment that has some of these put together already). If you’re interested in how GATs enable a library to do zero-copy parsing, resulting in nearly a ten-fold performance increase, you might be interested in checking out a blog post on it by Niko Matsakis.

All in all, even if you won’t need to use GATs directly, it’s very possible that the libraries you use will use GATs either internally or publically for ergonomics, performance, or just because that’s the only way the implementation works…. [A]ll the various people involved in getting this stabilization to happen deserve the utmost thanks. As said before, it’s been 6.5 years coming and it couldn’t have happened without everyone’s support and dedication.
Rust 1.65.0 also contains let-else statements — a new kind of let statement “with a refutable pattern and a diverging else block that executes when that pattern doesn’t match,” according to the release announcement.

And it highlights another new feature:

Plain block expressions can now be labeled as a break target, terminating that block early. This may sound a little like a goto statement, but it’s not an arbitrary jump, only from within a block to its end. This was already possible with loop blocks, and you may have seen people write loops that always execute only once, just to get a labeled break.

Now there’s a language feature specifically for that! Labeled break may also include an expression value, just as with loops, letting a multi-statement block have an early “return” value.

Carmi applauds Go’s readability-over-writability culture, its consistent concurrency model (with lightweight threading), and its broad ecosystem of tools. But in a second essay Carmi lists his complaints — about Go’s lack of keyword-based visibility modifiers (like “public” and “private”), how any symbol declared in a file “is automatically visible to the entire package,” and Go’s abundance of global built-in symbols (which complicate the choice of possible variable names, but which can still be overriden, since they aren’t actually keywords). After a longer wishlist — including null-pointer safety features and improvements to error handling — Carmi introduces a third article with “A Proposition for a Better Future.”
I would have loved to see a compile time environment that mostly looks like Go, but allows developers to be a bit more expressive to gain maintainability and runtime safety. But at the same time, allow the Go language itself to largely remain the same and not evolve into something new, as a lot of us Gophers fear. As Gophers, why not have two tools in our tool set?

The essay proposes a new extended flavor of Go called Goat — a “new compile-time environment that will produce standard, compatible, and performant Go files that are fully compatible with any other Go project. This means they can import regular Go files but also be safely imported from any other Go file.”

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

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

“Come join the discussion, we need your input.”

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

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

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

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

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

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

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

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

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

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

Their methodology? “We extract language rankings from GitHub and Stack Overflow, and combine them for a ranking that attempts to reflect both code (GitHub) and discussion (Stack Overflow) traction.” Below are this quarter’s results:

1. JavaScript
2. Python
3. Java
4. PHP
5. C#
6. CSS
7. C++
7. TypeScript
9. Ruby
10. C
11. Swift
12. R
12. Objective-C
14. Shell
15. Scala
15. Go
17. PowerShell
17. Kotlin
19. Rust
19. Dart

Their analysis of the latest rankings note “movement is increasingly rare…. the top 20 has been stable for multiple runs. As has been speculated about in this space previously, it seems increasingly clear that the hypothesis of a temporary equilibrium of programming language usage is supported by the evidence…. [W]e may have hit a point of relative — if temporary — contentment with the wide variety of languages available for developers’ usage.”

And yet this quarter TypeScript has risen from #8 to #7, now tied with C++, benefiting from attributes like its interoperability with an existing popular language with an increased availability of security-related features. “There is little suggestion at present that the language is headed anywhere but up. The only real question is on what timeframe.”

Unlike TypeScript, Go’s trajectory has been anything but clear. While it grew steadily and reasonably swiftly as languages go, it has appeared to be stalled, never placing higher than 14th and having dropped into 16 for the last three runs. This quarter, however, Go rose one spot in the rankings back up to 15. In and of itself, this is a move of limited significance, as the further one goes down the rankings the less significant the differences between them are, ranking-wise. But it has been over a year since we’ve seen movement from Go, which raises the question of whether there is any room for further upward ascent or whether it will remain hovering in the slot one would expect from a technically well regarded but not particularly versatile (from a use case standpoint) language.

Like Go, Kotlin had spent the last three runs in the same position. It and Rust had been moving in lockstep in recent quarters, but while Rust enters its fourth consecutive run in 19th place, Kotlin managed to achieve some separation this quarter jumping one spot up from 18 to 17.

One noteable update? Adding scoped threads to the standard library:

Rust code could launch new threads with std::thread::spawn since 1.0, but this function bounds its closure with ‘static. Roughly, this means that threads currently must have ownership of any arguments passed into their closure; you can’t pass borrowed data into a thread. In cases where the threads are expected to exit by the end of the function (by being join()’d), this isn’t strictly necessary and can require workarounds like placing the data in an Arc.

Now, with 1.63.0, the standard library is adding scoped threads, which allow spawning a thread borrowing from the local stack frame. The std::thread::scope API provides the necessary guarantee that any spawned threads will have exited prior to itself returning, which allows for safely borrowing data.
The official Rust RFC book says “The main drawback is that scoped threads make the standard library a little bit bigger,” but calls it “a very common and useful utility…great for learning, testing, and exploratory programming.

“Every person learning Rust will at some point encounter interaction of borrowing and threads. There’s a very important lesson to be taught that threads can in fact borrow local variables, but the standard library [didn’t] reflect this.” And otherwise, “Implementing scoped threads is very tricky to get right so it’s good to have a reliable solution provided by the standard library.”

The main goal of Vim9 script is to drastically improve performance. This is accomplished by compiling commands into instructions that can be efficiently executed. An increase in execution speed of 10 to 100 times can be expected. A secondary goal is to avoid Vim-specific constructs and get closer to commonly used programming languages, such as JavaScript, TypeScript and Java.

The performance improvements can only be achieved by not being 100% backwards compatible. For example, making function arguments available by creating an “a:” dictionary involves quite a lot of overhead. In a Vim9 function this dictionary is not available. Other differences are more subtle, such as how errors are handled. For those with a large collection of legacy scripts: Not to worry! They will keep working as before. There are no plans to drop support for legacy script. No drama like with the deprecation of Python 2.

“Many of these leaks allow hackers to access the private accounts of developers on Github, Docker, AWS, and other code repositories, security experts said in a new report.”

The availability of the third-party developer credentials from Travis CI has been an ongoing problem since at least 2015. At that time, security vulnerability service HackerOne reported that a Github account it used had been compromised when the service exposed an access token for one of the HackerOne developers. A similar leak presented itself again in 2019 and again last year.

The tokens give anyone with access to them the ability to read or modify the code stored in repositories that distribute an untold number of ongoing software applications and code libraries. The ability to gain unauthorized access to such projects opens the possibility of supply chain attacks, in which threat actors tamper with malware before it’s distributed to users. The attackers can leverage their ability to tamper with the app to target huge numbers of projects that rely on the app in production servers.

Despite this being a known security concern, the leaks have continued, researchers in the Nautilus team at the Aqua Security firm are reporting. A series of two batches of data the researchers accessed using the Travis CI programming interface yielded 4.28 million and 770 million logs from 2013 through May 2022. After sampling a small percentage of the data, the researchers found what they believe are 73,000 tokens, secrets, and various credentials.

“These access keys and credentials are linked to popular cloud service providers, including GitHub, AWS, and Docker Hub,” Aqua Security said. “Attackers can use this sensitive data to initiate massive cyberattacks and to move laterally in the cloud. Anyone who has ever used Travis CI is potentially exposed, so we recommend rotating your keys immediately.”