Apple's mobile apps routinely appear first in search results ahead of competitors in its App Store, a powerful advantage that skirts some of the company's rules on such rankings, according to a Wall Street Journal analysis. From the report: The company's apps ranked first in more than 60% of basic searches, such as for "maps," [Editor's note: the link may be paywalled; alternative source] the analysis showed. Apple apps that generate revenue through subscriptions or sales, like Music or Books, showed up first in 95% of searches related to those apps. This dominance gives the company an upper hand in a marketplace that generates $50 billion in annual spending. Services revenue linked to the performance of apps is at the center of Apple's strategy to diversify its profits as iPhone sales wane. While many of Apple's products are undoubtedly popular, they are held to a different standard by the App Store. Apple tells developers that downloads, user reviews and ratings are factors that influence search results. Yet more than two dozen of Apple's apps come pre-installed on iPhones and are shielded from reviews and ratings.

[...] Audiobooks.com, an RBmedia company, largely held the No. 1 ranking in "audiobooks" searches in the App Store for nearly two years. Then last September it was unseated by Apple Books. The Apple app had only recently begun marketing audiobooks directly for the first time. "It was literally overnight," said Ian Small, Audiobooks.com's general manager. He said the change triggered a 25% decline in Audiobooks.com's daily app downloads. [...] Apple's role as both the creator of the App Store's search engine and the beneficiary of its results has rankled developers. They contend Apple is essentially pinning its apps No. 1, compelling anyone seeking alternatives to consider Apple apps first. [...] Phillip Shoemaker, who led the App Store review process until 2016, said Apple executives were aware of Podcasts' poor ratings. Around 2015, his team proposed to senior executives that it purge all apps rated lower than two stars to ensure overall quality. "That would kill our Podcasts app," an Apple executive said, according to Mr. Shoemaker, who has advised some independent apps on the App Store review process since leaving Apple. The proposal was eventually rejected, Mr. Shoemaker said.

Senior full-stack engineer Ilya Suzdalnitski recently published a lively 6,000-word essay calling object-oriented programming "a trillion dollar disaster." Precious time and brainpower are being spent thinking about "abstractions" and "design patterns" instead of solving real-world problems... Object-Oriented Programming (OOP) has been created with one goal in mind -- to manage the complexity of procedural codebases. In other words, it was supposed to improve code organization. There's no objective and open evidence that OOP is better than plain procedural programming... Instead of reducing complexity, it encourages promiscuous sharing of mutable state and introduces additional complexity with its numerous design patterns. OOP makes common development practices, like refactoring and testing, needlessly hard...

Using OOP is seemingly innocent in the short-term, especially on greenfield projects. But what are the long-term consequences of using OOP? OOP is a time bomb, set to explode sometime in the future when the codebase gets big enough. Projects get delayed, deadlines get missed, developers get burned-out, adding in new features becomes next to impossible. The organization labels the codebase as the "legacy codebase", and the development team plans a rewrite.... OOP provides developers too many tools and choices, without imposing the right kinds of limitations. Even though OOP promises to address modularity and improve reusability, it fails to deliver on its promises...

I'm not criticizing Alan Kay's OOP -- he is a genius. I wish OOP was implemented the way he designed it. I'm criticizing the modern Java/C# approach to OOP... I think that it is plain wrong that OOP is considered the de-facto standard for code organization by many people, including those in very senior technical positions. It is also wrong that many mainstream languages don't offer any other alternatives to code organization other than OOP.
The essay ultimately blames Java for the popularity of OOP, citing Alan Kay's comment that Java "is the most distressing thing to happen to computing since MS-DOS." It also quotes Linus Torvalds's observation that "limiting your project to C means that people don't screw things up with any idiotic 'object model'."

And it ultimately suggests Functional Programming as a superior alternative, making the following assertions about OOP:

• "OOP code encourages the use of shared mutable state, which has been proven to be unsafe time and time again... [E]ncapsulation, in fact, is glorified global state."
• "OOP typically requires a lot of boilerplate code (low signal-to-noise ratio)."
• "Some might disagree, but OOP code is notoriously difficult to unit test... [R]efactoring OOP code is really hard without dedicated tools like Resharper."
• "It is impossible to write good and maintainable Object-Oriented code."

GitLab's CEO and co-founder says there was one big takeaway from their recent "2019 Global Developer Report: DevSecOps": that early adopters of a strong Devops model experience greater security. "Security teams in a longstanding DevOps environment reported they are three times more likely to discover bugs before code is merged," according to the GitLab blog, "and 90% more likely to test between 91% and 100% of code than teams who encounter early-stage DevOps."

But after polling over 4,000 software professionals, the survey also found positive results from another workplace arrangement, which they report under the headline "Remote work works." According to our survey respondents, working remotely leads to greater collaboration, better documentation, and transparency.

In fact, developers in a mostly remote environment are 23% more likely to have good insight into what colleagues are working on and rate the maturity of their organization's security practices 29% higher than those who work in a traditional office environment.

Google's Go programming language will not add a try() function in its next major version, "despite this being a major part of what was proposed," reports the Register: Error handling in Go is currently based on using if statements to compare a returned error value to nil. If it is nil, no error occurred. This requires developers to write a lot of if statements. "In general Go programs have too much code-checking errors and not enough code handling them," wrote Google principal engineer Russ Cox in an overview of the error-handling problem in Go.

There was therefore a proposal to add a built-in try function which lets you eliminate many of the if statements and triggers a return from a function if an error is detected. The proposal was not for full exception handling, which is already present in Go via the panic and recover functions. That proposal has now been abandoned. Robert Griesemer, one of the original designers of Go, announced the decision in a post Tuesday...

"Based on the overwhelming community response and extensive discussion here, we are marking this proposal declined ahead of schedule. As far as technical feedback, this discussion has helpfully identified some important considerations we missed, most notably the implications for adding debugging prints and analyzing code coverage.

"More importantly, we have heard clearly the many people who argued that this proposal was not targeting a worthwhile problem. We still believe that error handling in Go is not perfect and can be meaningfully improved, but it is clear that we as a community need to talk more about what specific aspects of error handling are problems that we should address."

"Everyone knows security needs to be baked into the development lifecycle, but that doesn't mean it is," writes ZDNet, reporting on a new survey they say showed that "long-standing friction between security and development teams remain."

The results came from GitLab's "2019 Global Developer Report: DevSecOps" survey of over 4,000 software professionals. Nearly half of security pros surveyed, 49%, said they struggle to get developers to make remediation of vulnerabilities a priority. Worse still, 68% of security professionals feel fewer than half of developers can spot security vulnerabilities later in the life cycle. Roughly half of security professionals said they most often found bugs after code is merged in a test environment.

At the same time, nearly 70% of developers said that while they are expected to write secure code, they get little guidance or help. One disgruntled programmer said, "It's a mess, no standardization, most of my work has never had a security scan." Another problem is it seems many companies don't take security seriously enough. Nearly 44% of those surveyed reported that they're not judged on their security vulnerabilities.
ZDNet also cites Linus Torvalds' remarks on the Linux kernel mailing list in 2017, complaining about how security people celebrate when code is hardened against an invalid access. "[F]rom a developer standpoint, things really are not done. Not even close. From a developer standpoint, the bad access was just a symptom, and it needs to be reported, and debugged, and fixed, so that the bug actually gets corrected. So from a developer standpoint, the end point of hardening is just the starting point, and when you think you're done, we're really only getting started."

Torvalds then pointed out that the user community also has a third set of entirely different expectations, adding that "the number one rule of kernel development is that 'we don't break users'. Because without users, your program is pointless, and all the development work you've done over decades is pointless... and security is pointless too, in the end." Juggling the interest of users and developers, Torvalds suggests security people should adopt "do no harm" as their mantra, and "when adding hardening features, the first step should *ALWAYS* be 'just report it'. Not killing things, not even stopping the access. Report it. Nothing else."

An anonymous reader quotes the Atlantic: Suze Orman wants young people to stop "peeing" away millions of dollars on coffee. Last month, the personal-finance celebrity ignited a controversy on social media when a video she starred in for CNBC targeted a familiar villain: kids these days and their silly $5 lattes. Because brewing coffee at home is less expensive, Orman argued, purchasing it elsewhere is tantamount to flushing money away, which makes it a worthy symbol of Millennials' squandered resources...

In the face of coffee shaming, young people usually point to things like student loans and housing prices as the true source of the generation's instability, not their $100-a-month cold-brew habits... Orman and her compatriots now receive widespread pushback when denigrating coffee aficionados, a change that reflects the shifting intergenerational tensions that are frequently a feature of the post-Great Recession personal-finance genre. The industry posits that many of the sweeping generational trends affecting Americans' personal stability -- student-loan debt, housing insecurity, the precarity of the gig economy -- are actually the fault of modernity's encouragement of undisciplined individual largesse. In reality, those phenomena are largely the province of Baby Boomers, whose policies set future generations on a much tougher road than their own. With every passing year, it becomes harder to sell the idea that the problems are simply with each American as a person, instead of with the system they live in. "There's a reason for this blame-the-victim talk" in personal-finance advice, the journalist Helaine Olen wrote recently. "It lets society off the hook. Instead of getting angry at the economics of our second gilded age, many end up furious with themselves."

That misdirection is useful for people in power, including self-help gurus who want to sell books... [W]hen it comes to money, says Laura Vanderkam, the author of All the Money in the World: What the Happiest People Know About Getting and Spending, there are usually only a couple of things that actually make a difference in how stable people are. It's the big stuff: how much you make, how much you pay for housing, whether or not you pay for a car.

An anonymous reader quotes LWN: Python 3.8 is feature complete at this point, which makes it a good time to see what will be part of it when the final release is made. That is currently scheduled for October, so users don't have that long to wait to start using those new features.

The headline feature for Python 3.8 is also its most contentious. The process for deciding on Python Enhancement Proposal (PEP) 572 ("Assignment Expressions") was a rather bumpy ride that eventually resulted in a new governance model for the language. That model meant that a new steering council would replace longtime benevolent dictator for life (BDFL) Guido van Rossum for decision-making, after Van Rossum stepped down in part due to the "PEP 572 mess".

Out of that came a new operator, however, that is often called the "walrus operator" due to its visual appearance. Using ":=" in an if or while statement allows assigning a value to a variable while testing it... It is a feature that many other languages have, but Python has, of course, gone without it for nearly 30 years at this point. In the end, it is actually a fairly small change for all of the uproar it caused.

Todd Austin, a professor at the University of Michigan, is working on an approach known as Morpheus that aims to frustrate hackers trying to gain control of microchips by presenting them with a rapidly changing target. At a conference in Detroit this week organized by the U.S. Defense Department's Defense Advanced Research Projects Agency (DARPA), Austin described how the prototype Morpheus chip works. MIT Technology Review reports: The aim is to make it incredibly difficult for hackers to exploit key software that helps govern the chip's operation. Morpheus does this by repeatedly randomizing elements of the code that attackers need access to in order to compromise the hardware. This can be achieved without disrupting the software applications that are powered by the processor. Austin has been able to get the chip's code "churning" to happen once every 50 milliseconds -- way faster than needed to frustrate the most powerful automated hacking tools. So even if hackers find a vulnerability, the information needed to exploit it disappears in the blink of an eye.

There's a cost to all this: the technology causes a slight drop in performance and requires somewhat bigger chips. The military may accept this trade-off in return for greater security on the battlefield, but it could limit Morpheus's appeal to businesses and consumers. Austin said a prototype has already resisted every known variant of a widely-used hacking technique known as a control-flow attack, which does things like tampering with the way a processor handles memory in order to allow hackers to sneak in malware. More tests lie ahead. A team of U.S. national security experts will soon begin probing the prototype chip to see if they can compromise its defenses, and Austin also plans to post some of Morpheus's code online so that other researchers can try to find flaws in it, too.

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.

Former Supreme Court Justice John Paul Stevens passed away Tuesday evening of complications following a stroke he suffered on July 15. He was 99 years old. An anonymous Slashdot reader shares a lightly edited version of Ars Technica's 2010 story that originally marked his retirement from the Supreme Court: In April 2010, the Supreme Court's most senior justice, John Paul Stevens, announced his retirement. In the weeks that followed, hundreds of articles were written about his career and his legacy. While most articles focus on 'hot button' issues such as flag burning, terrorism, and affirmative action, Stevens' tech policy record has largely been ignored. When Justice Stevens joined the court, many of the technologies we now take for granted -- the PC, packet-switched networks, home video recording -- were in their infancy. During his 35-year tenure on the bench, Stevens penned decisions that laid the foundation for the tremendous innovations that followed in each of these areas.

For example, Stevens penned the 1978 decision that shielded the software industry from the patent system in its formative years. In 1984, Hollywood's effort to ban the VCR failed by just one Supreme Court vote; Stevens wrote the majority opinion. And in 1997, he wrote the majority opinion striking down the worst provisions of the Communications Decency Act and ensuring that the Internet would have robust First Amendment protections. Indeed, Justice Stevens probably deserves more credit than any other justice for the innovations that occurred under his watch. And given how central those technologies have become to the American economy, Stevens' tech policy work may prove one of his most enduring legacies. In this feature, we review Justice Stevens' tech policy decisions and salute the justice who helped make possible DRM-free media devices, uncensored Internet connections, free software, and much more. As the report mentions, Stevens was the Supreme Court's cryptographer. "Stevens attended the University of Chicago, graduating in 1941. On December 6 -- the day before the Japanese attacked Pearl Harbor -- Stevens enrolled in the Navy's correspondence course on cryptography."

"Stevens spent the war in a Navy bunker in Hawaii, doing traffic analysis in an effort to determine the location of Japanese ships," the report adds. "He was an English major, not a mathematician, but he proved to have a knack for cryptographic work."

Slashdot reader DevNull127 writes: Another very minor kerfuffle has broken out in the community for the Go programming language. When its official Twitter account asked for feedback on the new look of its web site, one developer suggested that it had been a mistake to add the Google logo to the lower-right of the home page. "A lot of people associate it with a commercial Google product."

Following the suggested procedure, he then created an issue on GitHub. ("Go is perceived by some as a pure Google project without community involvement. Adding a Google logo does not help in this discussion.") The issue received 61 upvotes (and 30 downvotes), eventually receiving a response from Google software engineer Andrew Bonventre, the engineering lead on the Go Team.

"Thanks for the issue. We spent a long time talking about it and are sensitive to this concern. It's equally important to make it clear that Google supports Go, which was missing before (Much like typescriptlang.org). Google pays for and hosts the infrastructure that golang.org runs on and we hope the current very small logo is a decent compromise." He then closed the issue.

The developer who created the issue then responded, "I get that you've discussed this internally. This is a great opportunity to discuss it with the community. I'm thankful to Google for financing the initial and ongoing development of Go but Google is not the only company investing [in] Go. I would like to move the Google logo into an separate section, together will the major stakeholders of the project."

In a later comment he added "I value Google's participation in Go and I'm not arguing to change that. Having the Google logo in the corner of each golang.org page suggests that this is a pure Google project when it is not..."

For some perspective, another Go developer had also suggested "animate the gopher's eyes on the website."

"Thanks, but we're not going to do this," responded the engineering lead on the Go Team. "We've discussed it before and it would be way too distracting."

Cloudflare has published a detailed and refreshingly honest report into precisely what went wrong earlier this month when its systems fell over and took a big chunk of the internet with it. The Register reports: We already knew from a quick summary published the next day, and our interview with its CTO John Graham-Cumming, that the 30-minute global outage had been caused by an error in a single line of code in a system the company uses to push rapid software changes. [...] First up the error itself -- it was in this bit of code: .*(?:.*=.*). We won't go into the full workings as to why because the post does so extensively (a Friday treat for coding nerds) but very broadly the code caused a lot of what's called "backtracking," basically repetitive looping. This backtracking got worse -- exponentially worse -- the more complex the request and very, very quickly maxed out the company's CPUs.

The impact wasn't noticed for the simple reason that the test suite didn't measure CPU usage. It soon will -- Cloudflare has an internal deadline of a week from now. The second problem was that a software protection system that would have prevented excessive CPU consumption had been removed "by mistake" just a weeks earlier. That protection is now back in although it clearly needs to be locked down. The software used to run the code -- the expression engine -- also doesn't have the ability to check for the sort of backtracking that occurred. Cloudflare says it will shift to one that does. The post goes on to talk about the speed with which it impacted everyone, why it took them so long to fix it, and why it didn't just do a rollback within minutes and solve the issue while it figured out what was going on.

You can read the full postmortem here.

Last year, Oracle filed a lawsuit against the U.S. government complaining about the procurement process around the Pentagon's $10 billion, decade-long JEDI cloud contract. "They claimed a potential conflict of interest on the part of a procurement team member (who was a former AWS employee)," reports TechCrunch. "Today, that case was dismissed in federal court." From the report: In dismissing the case, Federal Claims Court Senior Judge Eric Bruggink ruled that the company had failed to prove a conflict in the procurement process, something the DOD's own internal audits found in two separate investigations. Judge Bruggink ultimately agreed with the DoD's findings: "We conclude as well that the contracting officer's findings that an organizational conflict of interest does not exist and that individual conflicts of interest did not impact the procurement, were not arbitrary, capricious, an abuse of discretion, or otherwise not in accordance with law. Plaintiff's motion for judgment on the administrative record is therefore denied."

Today's ruling opens the door for the announcement of a winner of the $10 billion contract, as early as next month. The DoD previously announced that it had chosen Microsoft and Amazon as the two finalists for the winner-take-all bid.

Security engineer Ivan writes: For some reason Apple allows "subscription scam" apps on the App Store. These are apps that are free to download and then ask you to subscribe right on launch. It's called the freemium business model, except these apps ask you to subscribe for "X" feature(s) immediately when you launch them, and keep doing so, annoyingly, over and over until you finally subscribe. By subscribing you get a number of "free days" (trial) and then they charge you weekly/monthly/yearly for very basic features like scanning QR Codes.

I've been trying to monitor apps that have these characteristics: 1. They have In-App purchases for their subscriptions. 2. They have bad reviews, specially with words like "scam" or "fraud". 3. Their "good" reviews are generic, potentially bot-generated. This weekend I focused on 5 apps from 2 different developers and to my surprise they are very similar, not only their UI/UX but also their code is shared and their patterns are absolutely the same. A side from being classic subscription scam apps, I wanted to examine how they work internally and how they communicate with their servers and what type of information are they sending.

Amazon announced Thursday that it will spend up to $700 million over the next six years retraining 100,000 of its US employees, mostly in technical skills like software engineering and IT support. From a report: Amazon is already one of the largest employers in the country, with almost 300,000 workers (and many more contractors) and it's particularly hungry for more new talent. The company currently has more than 20,000 vacant US roles, over half of which are at its headquarters in Seattle. Meanwhile, the US economy is booming, and there are now more open jobs than there are unemployed people who can fill them, according to the Bureau of Labor Statistics. "The purpose isn't really to create a job ladder from fulfillment center to CEO, but rather to meet employees where they are and to create opportunities for them to build on the skills that they have," Ardine Williams, Amazon's vice president of workforce development, said in an interview Thursday morning. Amazon joins a number of other companies who have announced multimillion-dollar investments in retraining in recent years, as a tightening labor market and technological change forces businesses to evolve. Amazon has already spent thousands of dollars on worker retraining in its Career Choice program, which helps hourly associates pay for degree programs in other, high-demand fields. CEO Jeff Bezos said in a shareholder letter last year that more than 12,000 US employees have participated in the program since it began in 2012. Amazon said they will expand the program Thursday.

theodp writes: TechCrunch reports that Google kicked off the 2019 Computer Science Teachers Association (CSTA) Conference in style with the announcement of Code with Google, a new coding resource for teachers which collects Google's own free course curriculum on teaching computer science and coding. Google also announced a $1 million grant to the teachers group alongside the unveiling of Code with Google. To hear Google tell it, Code with Google -- much like bacon -- makes everything better. An English and Language Arts teacher, blogs Google Education VP Maggie Johnson, "didn't know much about computer science, but wanted her students to get familiar with coding because it can help with other skills, such as critical thinking and collaboration. So she tried a [Google] CS First activity where students coded different endings [video] to the story they read in class. Melissa says that, in a short time, 'the kids were problem solving, troubleshooting, and helping one another. It was incredible to hear the conversations about coding and the other concepts we were learning in the room.'" Johnson is also on the Board of tech-bankrolled Code.org, which reported it had spent $91.4 million (thru Dec. 2018) to get CS into K-12 schools (Google is a $3+ million Code.org Gold Sponsor). Not too surprisingly, one of the CSTA 2019 keynotes will be delivered by employees of Platinum Conference Sponsor Google, including a former CSTA Executive Director (CSTA is currently led by Code.org's former Director of State Government Affairs -- it's a small K-12 CS world!).

Slashdot reader volvox_voxel shares an excerpt from the latest blog post from software engineer Ken Shirriff, who is well known for his work on restoring some of the rarest computing hardware to its working condition: We've been restoring an Apollo Guidance Computer1. Now that we have the world's only working AGC, I decided to write some code for it. Trying to mine Bitcoin on this 1960s computer seemed both pointless and anachronistic, so I had to give it a shot. Implementing the Bitcoin hash algorithm in assembly code on this 15-bit computer was challenging, but I got it to work. Unfortunately, the computer is so slow that it would take about a billion times the age of the universe to successfully mine a Bitcoin block. He wasn't kidding about how long it would take to successfully mine a Bitcoin block. "The Apollo Guidance Computer took 5.15 seconds for one SHA-256 hash," writes Shirriff. "Since Bitcoin uses a double-hash, this results in a hash rate of 10.3 seconds per Bitcoin hash. Currently, the Bitcoin network is performing about 65 EH/s (65 quintillion hashes per second). At this difficulty, it would take the AGC 4x10^23 seconds on average to find a block. Since the universe is only 4.3x10^17 seconds old, it would take the AGC about a billion times the age of the universe to successfully mine a block."

Netflix Hangouts is a new Chrome extension that tries to make it easier to get away with watching Netflix while you're supposed to be working. Just go to the show you want to catch up on during work hours, and press the extension's icon in your Chrome menu to bring up a fake four-person conference call. Then you can sit back and watch the show in the window's bottom right feed while three fake colleagues get down to business. The Verge reports: The extension was developed by Mschf Internet Studios, which has produced a few internet curiosities like this over the years. There was the Slack channel that offered $1,000 in prize money for the first person to correctly guess each word of the day (it was shut down by Slack after just a week), a man who ate various foods as disgusting ice cream toppings, and who could forget Tabagotchi, the lovable virtual avatar that slowly died as you opened more and more tabs? Netflix Hangouts is the latest in a long line of services designed to let you slack off at work.

Mozilla is funding a project for bringing the Julia programming language to Firefox and the general browser environment. From a report: The project received funding part of the Mozilla Research Grants for the first half of 2019, which the browser maker announced on Friday. In April, when Mozilla opened this year's submissions period for research grants, the organization said it was looking for a way to bring data science and scientific computing tools to the web. It said it was specifically interested in receiving submissions about supporting R or Julia at the browser level. Both R and Julia are programming languages designed for high-performance numerical, statistical, and computational science.

Mozilla engineers have worked in previous years to port data science tools at the browser level, as part of Project Iodide. Previously, as part of this project, Mozilla engineers ported the Python interpreter to run in the browser using WebAssembly. "This project, Pyodide, has demonstrated the practicality of running language interpreters in WebAssembly," Mozilla engineers said.

Matt Klein, a member of the Go steering committee recently apologized for the angst caused to some people by "the try() kerfuffle... Change is hard, but sometimes it's for the best."

Tech columnist Mike Melanson covers the kerfuffle over the newly-proposed feature, while trying "not to over-dramatize what is happening." There is disagreement and conflicting views, but working through those views is how the open source sausage is made, is it not? Of course, in the Go community, how the core team receives those opposing views may be a point of soreness among some who vehemently opposed the vgo package versioning for Go and felt that, in the end, it was rammed through despite their objections. As one Gopher points out, it is better to debate now than summarily accept and then later deprecate...

As Go makes its way to Go 2.0, with Go 1.14 currently taking center stage for debate, there is, again, as Klein points out, some kerfuffle about a newly proposed feature called try(), which is "designed specifically to eliminate the boilerplate if statements typically associated with error handling in Go." According to the proposal, the "minimal approach addresses most common scenarios while adding very little complexity to the language" and "is easy to explain, straightforward to implement, orthogonal to other language constructs, and fully backward-compatible" as well as extensible for future needs.

Much of the disagreement around try() comes in the form of whether or not the resultant code is more or less readable than current implementations of error handling. Beyond that, however, some say that even if try() were accepted, it has faults that would prevent them from recommending or even allowing its use among their teams. Meanwhile, another point of contention is offered in an open letter to the Go team about try by William Kennedy who often writes about Go, and focuses on not style or function, but rather whether or not a solution is needed at all. According to Kennedy, "the perceived error handling complaints are perhaps overblown and these changes are not what the majority of Go developers want or need" and that try() may be a solution searching for a problem, and even the cause of more problems than it solves."Since this new mechanic is going to cause severe inconsistencies in code bases, disagreements on teams, and create an impossible task for product owners to enforce consistent guidelines, things need to be slowed down and more data needs to be gathered," Kennedy writes.

He goes on to point out those very sensitivities that may have lingered from previous discussions in the Go community. "This is a serious change and it feels like it's being pushed through without a concerted effort to understand exactly what those 5% of Go developers meant when they said they wanted improved error handling...."