Kite, a start-up that has been developing artificial intelligence technology to help developers write code for nearly a decade, is saying farewell and open-sourcing its code. Silicon Republic reports: Based in San Francisco, Kite was founded in 2014 as an early pioneer in the emerging field of AI that assists software developers in writing code -- an 'autocomplete' for programming of sorts. But now, after eight years of pursuing its vision to be a leader in AI-assisted programming, founder Adam Smith announced on the company website that the business is now wrapping up. According to him, even state-of-the-art machine learning models today don't understand the structure of code -- and too few developers are willing to pay for available services. "We failed to deliver our vision of AI-assisted programming because we were 10-plus years too early to market, ie, the tech is not ready yet," Smith explained. "You can see this in GitHub Copilot, which is built by GitHub in collaboration with OpenAI. As of late 2022, Copilot shows a lot of promise but still has a long way to go."

Copilot was first revealed in June 2021 as an AI assistant for programmers that essentially does for coding what predictive text does for writing emails. Developed in collaboration with OpenAI, GitHub had kept Copilot in technical preview until this summer, during which time it had been used by more than 1.2m developers. The AI was made available to all developers in June, at a cost of $10 a month or $100 a year. However, Smith said that the inadequacy of machine learning models in understanding the structure of code, such as non-local context, has been an insurmountable challenge for the Kite team. "We made some progress towards better models for code, but the problem is very engineering intensive. It may cost over $100m to build a production-quality tool capable of synthesizing code reliably, and nobody has tried that quite yet."

While the business could have still been successful without necessarily increasing developer productivity by 10 times using AI, Smith said he thinks that Kite's delay and unsuccessful attempt at monetizing the service prevented the start-up from taking flight. "We sequenced building our business in the following order: First we built our team, then the product, then distribution and then monetization," he explained, adding that Kite did not reach product-market fit until 2019, five years after starting the company. Despite the time taken to get to the market, Smith said Kite was able to capture 500,000 monthly active developers using its AI with "almost zero marketing spend." But the product failed to generate revenue because the developers refused to pay for it. Smith says most of their code has been open sourced on GitHub, including their "data-driven Python type inference engine, Python public-package analyzer, desktop software, editor integrations, GitHub crawler and analyzer, and more more."

While the popularity of jQuery is decreasing, React.JS "is currently the most widely used client-side framework," reports ZDNet, citing SlashData's 23rd State of the Developer Nation report (compiled from more than 26,000 developers last summer from 163 countries).

ZDNet believe it shows developers "experimenting less and sticking with what they know and what works." JavaScript remains the largest programming language community, SlashData found. According to its research, there are an estimated 19.6 million developers worldwide using JavaScript every day in everything from web development and mobile apps to backend coding, cloud and game design. Java, meanwhile, is growing rapidly. In the last two years, the size of the Java community has more than doubled from 8.3 million to 16.5 million, SlashData found. For perspective, the global developer population grew about half as fast over the same period....

Python also continued to grow strongly, adding about eight million new developers over the last two years, according to SlashData. It accredited the rise of data science and machine learning as "a clear factor in Python's growing popularity". Approximately 63% of machine-learning developers and data scientists report using Python, whereas less than 15% use R, another programming language often associated with data science.
Both the Kotlin and Rust communities doubled in size in the past two years, the article points out. But according to the survey, only 9% of developers were involved in blockchain technologies.

Yet 27% of respondents reported they were learning about (if not currently working on) cryptocurrency-based projects. ZDNet summarizes the findings: Of the three blockchain technologies covered in the report, non-fungible tokens (NFTs) were found to be of least interest to developers: 58% showed "no interest" in NFTs, which SlashData said was "likely due to its perception as a novelty".

The report found that one-quarter (25%) of developers currently work on, or are learning about, blockchain applications other than cryptocurrencies.

The CTO of a software company argues the software industry's current trajectory "is toward increasing complexity, longer product-development times, and greater fragility of production systems" — not to mention nightmarish problems maintaining code.

"To address such issues, companies usually just throw more people at the problem: more developers, more testers, and more technicians who intervene when systems fail. Surely there must be a better way," they write in IEEE Spectrum. "I'm part of a growing group of developers who think the answer could be functional programming...." Today, we have a slew of dangerous practices that compromise the robustness and maintainability of software. Nearly all modern programming languages have some form of null references, shared global state, and functions with side effects — things that are far worse than the GOTO ever was. How can those flaws be eliminated? It turns out that the answer has been around for decades: purely functional programming languages....

Indeed, software based on pure functions is particularly well suited to modern multicore CPUs. That's because pure functions operate only on their input parameters, making it impossible to have any interactions between different functions. This allows the compiler to be optimized to produce code that runs on multiple cores efficiently and easily....

Functional programming also has a solution to Hoare's "billion-dollar mistake," null references. It addresses that problem by disallowing nulls. Instead, there is a construct usually called Maybe (or Option in some languages). A Maybe can be Nothing or Just some value. Working with Maybe s forces developers to always consider both cases. They have no choice in the matter. They must handle the Nothing case every single time they encounter a Maybe. Doing so eliminates the many bugs that null references can spawn.

Functional programming also requires that data be immutable, meaning that once you set a variable to some value, it is forever that value. Variables are more like variables in math...

Pure functional programming solves many of our industry's biggest problems by removing dangerous features from the language, making it harder for developers to shoot themselves in the foot.... I anticipate that the adoption of pure functional languages will improve the quality and robustness of the whole software industry while greatly reducing time wasted on bugs that are simply impossible to generate with functional programming. It's not magic, but sometimes it feels like that, and I'm reminded of how good I have it every time I'm forced to work with a non-functional codebase.

This week the Adacore blog shared a story about the NVIDIA Security Team: Like many other security-oriented teams in our industry today, they were looking for a measurable answer to the increasingly hostile cybersecurity environment and started questioning their software development and verification strategies. "Testing security is pretty much impossible. It's hard to know if you're ever done," said Daniel Rohrer, VP of Software Security at NVIDIA.

In my opinion, this is the most important point of the case study — that test-oriented software verification simply doesn't work for security. Once you come out of the costly process of thoroughly testing your software, you can have a metric on the quality of the features that you provide to the users, but there's not much you can say about security.

Rohrer continues, "We wanted to emphasize provability over testing as a preferred verification method." Fortunately, it is possible to prove mathematically that your code behaves in precise accordance with its specification. This process is known as formal verification, and it is the fundamental paradigm shift that made NVIDIA investigate SPARK, the industry-ready solution for software formal verification.

Back in 2018, a Proof-of-Concept (POC) exercise was conducted. Two low-level security-sensitive applications were converted from C to SPARK in only three months. After an evaluation of the return on investment, the team concluded that even with the new technology ramp-up (training, experimentation, discovery of new tools, etc.), gains in application security and verification efficiency offered an attractive trade-off. They realized major improvements in the security robustness of both applications (See NVIDIA's Offensive Security Research D3FC0N talk for more information on the results of the evaluation).

As the results of the POC validated the initial strategy, the use of SPARK spread rapidly within NVIDIA. There are now over fifty developers trained and numerous components implemented in SPARK, and many NVIDIA products are now shipping with SPARK components.

In an press release published earlier today, the National Security Agency (NSA) says it will be making a strategic shift to memory safe programming languages. The agency is advising organizations explore such changes themselves by utilizing languages such as C#, Go, Java, Ruby, or Swift. From the report: The "Software Memory Safety" Cybersecurity Information Sheet (PDF) highlights how malicious cyber actors can exploit poor memory management issues to access sensitive information, promulgate unauthorized code execution, and cause other negative impacts. "Memory management issues have been exploited for decades and are still entirely too common today," said Neal Ziring, Cybersecurity Technical Director. "We have to consistently use memory safe languages and other protections when developing software to eliminate these weaknesses from malicious cyber actors."

Microsoft and Google have each stated that software memory safety issues are behind around 70 percent of their vulnerabilities. Poor memory management can lead to technical issues as well, such as incorrect program results, degradation of the program's performance over time, and program crashes. NSA recommends that organizations use memory safe languages when possible and bolster protection through code-hardening defenses such as compiler options, tool options, and operating system configurations. The full report is available here (PDF).

A new article from Wired calls Rust "the 'viral' secure programming language that's taking over tech."

"Rust makes it impossible to introduce some of the most common security vulnerabilities. And its adoption can't come soon enough...." [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."

"We serve about 100 million monthly visitors worldwide," says the CEO of Stack Overflow, "making us one of the most popular websites in the world. I think we are in the top 50 of all websites in the world by traffic."

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

The newest stable version of Rust, 1.65.0 includes generic associated types (GATs) — the ability to declare lifetime, type, and const generics on associated types. "It's hard to put into few words just how useful these can be," writes the official Rust blog.

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.

"Microsoft's GitHub Copilot is being sued in a class action lawsuit that claims the AI product is committing software piracy on an unprecedented scale," reports IT Pro.

Programmer/designer Matthew Butterick filed the case Thursday in San Francisco, saying it was on behalf of millions of GitHub users potentially affected by the $10-a-month Copilot service: The lawsuit seeks to challenge the legality of GitHub Copilot, as well as OpenAI Codex which powers the AI tool, and has been filed against GitHub, its owner Microsoft, and OpenAI.... "By training their AI systems on public GitHub repositories (though based on their public statements, possibly much more), we contend that the defendants have violated the legal rights of a vast number of creators who posted code or other work under certain open-source licences on GitHub," said Butterick.

These licences include a set of 11 popular open source licences that all require attribution of the author's name and copyright. This includes the MIT licence, the GNU General Public Licence, and the Apache licence. The case claimed that Copilot violates and removes these licences offered by thousands, possibly millions, of software developers, and is therefore committing software piracy on an unprecedented scale.

Copilot, which is entirely run on Microsoft Azure, often simply reproduces code that can be traced back to open-source repositories or licensees, according to the lawsuit. The code never contains attributions to the underlying authors, which is in violation of the licences. "It is not fair, permitted, or justified. On the contrary, Copilot's goal is to replace a huge swath of open source by taking it and keeping it inside a GitHub-controlled paywall...." Moreover, the case stated that the defendants have also violated GitHub's own terms of service and privacy policies, the DMCA code 1202 which forbids the removal of copyright-management information, and the California Consumer Privacy Act.
The lawsuit also accuses GitHub of monetizing code from open source programmers, "despite GitHub's pledge never to do so."

And Butterick argued to IT Pro that "AI systems are not exempt from the law... If companies like Microsoft, GitHub, and OpenAI choose to disregard the law, they should not expect that we the public will sit still." Butterick believes AI can only elevate humanity if it's "fair and ethical for everyone. If it's not... it will just become another way for the privileged few to profit from the work of the many."

Reached for comment, GitHub pointed IT Pro to their announcement Monday that next year, suggested code fragments will come with the ability to identify when it matches other publicly-available code — or code that it's similar to.

The article adds that this lawsuit "comes at a time when Microsoft is looking at developing Copilot technology for use in similar programmes for other job categories, like office work, cyber security, or video game design, according to a Bloomberg report."

It's been one week since Python 3.11 was released — and it's "faster than ever!" So says Jay Miller, a Microsoft developer writing about Microsoft's six-person "Faster CPython" team (which includes Python creator Guido van Rossum, and offers assistance to other core developers). Miller cites the team's report that Python 3.11 has already seen speedups of 10-60% in some areas of the language -- and offers this inside look at their work.

First, how the team came together: In 2020, Core Developer Mark Shannon drafted an Implementation plan for speeding up CPython (the most common implementation) by five times. This plan proposed a 4-stage process that, as Python's creator Guido van Rossum says, "was an effort that was too much for one volunteer to accomplish".

"Right from the start, my thought was well, we should try to see if Microsoft can hire Mark and a small team of people to support him." In the previous year Van Rossum came out of retirement and joined Microsoft as a Distinguished Engineer. "It was an important effort and it was too much for one person." Microsoft was open to the idea and a team of 6 engineers, including Van Rossum were established. That team has assisted other core developers in acting on this plan.
But the blog post also looks at how the team functions: Every contributor that made the switch from part-time to full-time contribution mentioned being able to get deeper into their work on the language.... The team meets regularly to discuss these things. "All six of us meet every Monday," says Van Rossum. "There's always more than enough to talk about. That is very different than as a core dev community getting together for a Sprint twice a year, like one day after the conference. That is a very special event, of course, but it doesn't feed me throughout the year." Van Rossum believes that knowledge of one another and their collaborative work gave the team a "leg up" because everyone "knows what communication styles people have and what everybody's weaknesses and strengths are...."

Shannon's original 4 stage plan has continued to evolve to have continuous optimizations for the next several years. "To make that as smooth as possible, you have to think in terms of smaller steps, right?" says [team member] Michael Droettboom. Droettboom has worked on long-term projects in the scientific community including the Hubble Space Telescope and more recently the James Web Space Telescope.... "We hope we can bring some knowledge from really large proprietary systems into what we develop for the Community." says Droettboom. "I think that's really valuable because then you're not just doing it in the abstract. Not just imagining what's going to make Python faster for real use cases, but actually measuring it." [Team member] Brandt Bucher adds in that developers working with these teams can test the impact of changes, "getting useful insights and contributions from people who maintain large, diverse codebases...." Many of the team's meetings feature core developers from other teams and companies.
The blog post highlights specific activities of team members:

• L Pereira is working on a change to how integers are represented inside Python, and "intends to change smaller integers to use native computation instead of the slower algorithms for arbitrarily large numbers."

• Irit Katriel implemented the new Exception groups and except* features in Python 3.11, and reports that "By simplifying the interpreter's internal representation of raised exceptions, I reduced the time it takes to raise and catch an exception by about 10%."

• Brandt Bucher (who helped create structural pattern matching for Python 3.10) is working on a Specialized Adaptive Interpreter (and tools like Specialist to help users move to Python).

• Long-time contributor Eric Snow is working on a per-interpreter Global Interpreter Lock.

And they've already begun working on features for future versions of Python. "You can also find out more about what the Faster CPython Team has in mind for 3.12 in their ideas repo on Github."

Developer Dan Leveille received "a sketchy voicemail from a random number about a class action lawsuit settlement..." he posted on Twitter. "I thought it was a scam and almost ignored it."

But he didn't — and ended up with $8,064.88 in his Venmo account.

Back in 2019 a lawsuit by U.S. developers accused Apple of "profit-killing" App Store commissions, reports TechForge Media. Apple settled that suit by agreeing to create a $100 million Small Developer Assistance Fund (for developers who sold in Apple's app store between June of 2015 and April of 2021). And this month Apple has finally started sending out those payments, Apple Insider reports: Developers had until May 20 to submit a request to an independent administrator to become a "Settlement Class Member." If they met the criteria, the developers stood to receive a payment from $250 to $30,000 in value....

Along with the fund, the settlement also introduced a number of changes to App Store policies, including modifications relating to customer and developer communication, new pricing tiers, and a promise by Apple to continue offering its 15% reduced App Store commission for at least three years.

Long-time Slashdot reader theodp writes: "What is your biggest pain point?", North Carolina State University PhD student Samim Mirhosseini and Microsoft Researchers Austin Z. Henley & Chris Parnin asked 32 computer science instructors at universities and community colleges. Their feedback is summed up in a just-posted paper that will be presented at SIGCSE 2023.

Instructors cited understanding what students are struggling with, answering students' questions, limited teaching assistant (TA) support, grading & feedback, course material preparation, and administrative tasks as challenges, pain points, and things they wish they could change. Interestingly, instructors indicated that some of the attempts to address pain points — including the increased use of TA's, interactive textbooks/exercises, automated grading, "flipped" classrooms [where lectures are assigned as video homework, with classtime reserved for interaction], and peer instruction — aren't always what they're cracked up to be.

- "Some TAs are not mature programmers," instructors noted. "TAs sometimes only run the unit tests and never read the code, [so] two submissions that were nearly identical, but one got [high] marks and the other got [low] marks."

- Automation brings its own challenges, instructors added, citing the problem of interactive textbooks that give grades but deduct points even if there is only a whitespace difference with the solution ("My students struggle so much with it and they spend hours trying to get the white space correct in their program when in reality that's not what I want them spending time on").

- Instructors also cited struggles with "how to design 'Copilot-proof' assignments, to prevent students from completing homework assignments in seconds with little conceptual knowledge.

- Regarding the flipped classroom, one instructor confessed, "I've checked and there's very few people watching these videos."

While grading was cited as "probably the biggest burden of the courses" and "an impossible task," one instructor still noted a preference to grade things themselves even if they have TAs "because [of] the feedback I can get from [...] their homework and assignments." Along the same lines, another noted that while they also wish for more automation of mundane tasks, they are strongly opposed to automating feedback to students because "I think this is the wrong direction for education. Striping away community and humanity from learning."

"Kathleen Booth, who has died aged 100, co-designed of one of the world's first operational computers and wrote two of the earliest books on computer design and programming," the Telegraph wrote this week.

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

While listening to a podcast about the Go programming language, backend architect Aviv Carmi heard some loose talk about forking the language to keep its original design while also allowing the evolution of an "extended flavor."

If such a fork takes place, Carmi writes on Medium, he hopes the two languages could interact and share the same runtime environment, libraries, and ecosystem — citing lessons learned from the popularity of other language forks: There are well-known, hugely successful precedents for such a move. Unarguably, the JVM ecosystem will last longer and keep on gaining popularity thanks to Scala and Kotlin (a decrease in Java's popularity is overtaken by an increase in Scala's, during the previous decade, and in Kotlin's, during this one). All three languages contribute to a stronger, single community and gain stronger libraries and integrations. JavaScript has undoubtedly become stronger thanks to Typescript, which quickly became one of the world's most popular languages itself. I also believe this is the right move for us Gophers...
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."

An anonymous reader quotes a report from ZDNet: Low-code and no-code development is often seen as the realm of citizen developers, but the segment of the enterprise where low-code and no-code has gained significant traction is among professional developers themselves. And, importantly, it's making their jobs better in two ways: providing tools for faster software development and deployment, as well as elevating their roles in enterprises to that of teachers and facilitators for potential citizen developers.

A recent survey of 860 developers by OutSystems finds a majority of low-code users -- most of whom also use traditional coding languages alongside low-code -- report that they are "very satisfied" with their team productivity (59%), compared to 41% of traditional developers. Most low-coders, 57%, are also very satisfied with the quality of tools at their disposal to complete their work, compared to 36% of their traditional coding counterparts. In addition, 71% of low-code users said they were able to stick to the typical 40-hour work week, compared to only 44% of traditional developers. Additionally, 63% of low-code developers indicate they are happy with their salary and benefits compared to 40% of traditional developers.

Not only is low-code and no-code making things easier, it is also elevating the roles of technology professionals within their enterprises, to facilitator, educators, and consultants. Industry observers agree. "The professional's role is now to customize and connect the low-code solution to the organization's resources," relates Moses Guttmann, CEO and co-founder of ClearML. Their roles "shift towards mainly automation and orchestration, taking a low-code process and helping the low-code infrastructure gain access to different resources within the organization. Think of it as abstracting the databases and providing access to the orchestration -- such as cloud infrastructure to execute the low-code application." This can only mean more Agile development for the next generation of applications, with business-savvy developers and tech-savvy business users working side by side. "Citizen developers are typically growth-minded, innovative problem solvers with an active understanding of the business' overarching goals," says Aaron White, CTO and co-founder of Vendr. "In tandem with overseeing the work completed in a low-code or no-code environment, professional developers -- especially those leading teams -- should strive to recognize these employees' talents, actively enabling them to contribute to the development process." "It takes away a lot of the day-to-day implementation-related tasks and allows developers to focus on more architectural and strategic concerns," says Om Vyas, co-founder and chief product officer for oak9. "It puts them in a position to have a greater business impact. But also, with low-code and no-code approaches, when the one-size-fits-all pattern does not work for you, it will create work for these professionals to amend or customize to add their own implementations."

In many cases, "a low-code/no-code approach may operate as a complete solution. That said, IT and engineering may need to step in from time to time, to fine-tune the details," White adds.

Apple just launched new ad placements on the App Store, and developers aren't happy with the types of ads surfacing beneath their apps. From a report: As spotted by MacRumors, several app developers have pointed out that ads for gambling have started appearing in the "You Might Also Like" sections beneath their App Store listings, which is just one of the new places Apple has started sticking ads. Developer Simon B. Stovring posted a screenshot of an ad for an online casino app appearing beneath his text editor Runestone. Stovring says he visited the page for his app 10 times and noticed that ads for gambling apps showed up on three visits. Marco Arment, the developer of the podcast app Overcast, said on Twitter he's "really not OK with" the gambling ads showing up on his app product page. Another user replied to Arment's tweet, noting that the App Store is even showing gambling ads beneath apps designed specifically to help users recover from a gambling addiction, while another noticed gambling ads have even popped up on children's education apps.

Apple has announced updates to the App Store Review Guidelines, offering guidance for apps offering cryptocurrency and NFTs. Apple Insider reports: The text for the rule has been changed to include the following: "Apps may not use their own mechanisms to unlock content or functionality, such as license keys, augmented reality markers, QR codes, cryptocurrencies and cryptocurrency wallets, etc." The rule change is no surprise, as Apple only allows alternative payment systems in certain countries.

An addition to the 3.11 rule is as follows: "Apps may use in-app purchase to sell and sell services related to non-fungible tokens (NFTs), such as minting, listing, and transferring. Apps may allow users to view their own NFTs, provided that NFT ownership does not unlock features or functionality within the app. Apps may allow users to browse NFT collections owned by others, provided that the apps may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than in-app purchase."

Finally, Apple has revised rule 3.1.5(iii) to include cryptocurrency exchanges. These companies let people buy and sell cryptocurrencies using traditional fiat currency. "Exchanges: Apps may facilitate transactions or transmissions of cryptocurrency on an approved exchange, provided they are offered only in countries or regions where the app has appropriate licensing and permissions to provide a cryptocurrency exchange."

Earlier this year, Microsoft announced that it would be releasing new hardware to encourage more developers to start using and supporting the Arm version of Windows. Dubbed "Project Volterra," all we knew about it at the time was that it would use an unnamed Qualcomm Snapdragon processor and NVMe-based storage, that it would support at least two monitors, and that it would have a decent number of ports. Today, Microsoft is putting Volterra out into the world, complete with a snappy new name: the Windows Dev Kit 2023. From a report: The Dev Kit 2023 will use a Snapdragon 8cx Gen 3 -- essentially the same chip as the Microsoft SQ3 in the new 5G version of the Surface Pro 9 -- plus 512GB of storage and a whopping 32GB of RAM for the surprisingly low price of $599.

We don't know exactly how fast the 8cx Gen 3 will be (Qualcomm says "up to 85 percent faster" CPU performance than the 8cx Gen 2, which would put it somewhere below but within spitting distance of modern Core i5 laptop CPU). But 512GB of storage and 32GB of memory should make the Dev Kit 2023 useful as a development and testing environment. Microsoft says the box can connect to up to three monitors simultaneously using its two USB-C ports and mini DisplayPort and that up to two of those displays can be 4K screens running at 60 Hz. Three USB-A ports, gigabit Ethernet, Wi-Fi 6, and Bluetooth 5.1 round out the connectivity options.

RedMonk has released its latest quarterly rankings of popular programming languages, arguing that "The idea is not to offer a statistically valid representation of current usage, but rather to correlate language discussion and usage in an effort to extract insights into potential future adoption trends."

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.

An anonymous reader quotes a report from the Register: GitHub Copilot -- a programming auto-suggestion tool trained from public source code on the internet -- has been caught generating what appears to be copyrighted code, prompting an attorney to look into a possible copyright infringement claim. On Monday, Matthew Butterick, a lawyer, designer, and developer, announced he is working with Joseph Saveri Law Firm to investigate the possibility of filing a copyright claim against GitHub. There are two potential lines of attack here: is GitHub improperly training Copilot on open source code, and is the tool improperly emitting other people's copyrighted work -- pulled from the training data -- to suggest code snippets to users?

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