Jul 19, 2019 newsletter

Microsoft plans to explore Rust as an alternative to C and C++ to improve security, accelerate innovation, and tap into its vibrant developer community

Microsoft is searching for a replacement to C and C++, both of which are used to build Windows and many other Microsoft services. One contender is Rust, which, unlike C and C++, is a memory-safe language that is built with protections against memory corruption vulnerabilities, such as buffer overflows and memory leaks. Microsoft’s own programming language C# features many of the same memory access improvements, but lacks some of the advanced features of Rust.

Rust was initially developed by the team at Mozilla as a safer and faster programming language to rebuild the Firefox browser. Developers, however, are taking notice of the fast-growing language and putting it to use: Rust was the most loved programming language in the Stack Overflow Developer Survey for 2016, 2017, 2018, and 2019.

The potential adoption of Rust across the Microsoft ecosystem is driven by a need to eliminate time-consuming memory bug patches, streamline development, and ride the wave of developer interest in Rust. Microsoft security engineers recently noted that over the last 12 years, roughly 70% of all Microsoft's yearly patches were related to memory safety bugs; by using a language that is designed to avoid many of these issues, Microsoft can focus more of its attention on building, rather than bug-fixing, its products. Similar to TypeScript’s improvements to JavaScript, Rust provides us with a powerful example of how to prevent bugs at the lowest-level in the software supply chain.

And, as Rust continues its race as the dark horse language to the top of the developer popularity rankings, Microsoft sees a growing opportunity to align itself and its ecosystem with the next thriving community of developers. Should Rust achieve a breakout moment, Microsoft would be well-positioned to attract app developers to its platforms.

Open source maintainers and developer community square off, but Golang developers ultimately quash proposed ‘try’ function

In early June, the team behind Go proposed adding a built-in error check function ‘try’ into the next version of the Go language. The new error handler was intended to minimize boilerplate code by reducing the number of if statements needed when calling functions that may return errors. The simple proposal, however, sparked intense debate within the Go community. Members of the community felt that the changes would likely not reduce boilerplate code and would demote robust error handling to an easily-ignored afterthought. Moreover, many developers feared that Google would try to force the proposed changes into the language, despite uproar from the community.

As of last week, however, the Go team announced that the proposal had been declined and would not be included in future versions of Go. In a GitHub comment, the Go team noted: "we have heard clearly the many people who argued that this proposal was not targeting a worthwhile problem."

Many admired the outspokenness of the Go community and praised the Go team for declining the proposal, while others feared that Go’s progress as a language would suffer from a now overly-democratic decision-making process. Google, as the creator of Go, awkwardly straddles both sides of the table, hoping to grow Go's loyal developer community but seeking new ways to expand Go into an even more robust and innovative language. Many open source projects, including Go, are not immune from pressure from the tech giants that created and released them. For now, the Go community has prevailed, but the divisive story offers a cautionary tale for the future.

For contrast, a recent debate about whether or not the Google logo should be featured on the footers of each page of the Golang website showed that Google is willing to flex its strength in other ways. Despite complaints that the logo made Go seem like a Google commercial product, the changes were approved without much community discussion. While open source technology has increased developer access to powerful technologies, it also opens up the ecosystem to thorny issues when big tech gets involved. As open source software proliferates, power will continue to seesaw between its maintainers and the developers that use it.

GitLab released its 2019 Global Developer Report, suggests there is much room for improvement in a new wave of developer-led security practices

The latest survey from GitLab asked over 4,000 respondents across various industries, roles, and geographic locations to share their thoughts on software development, security, and operations. Much of the survey indicates that security is a work in progress at many companies, with developers and security professionals seeing a need for greater focus on applying security-driven processes throughout the development life cycle.

Accordingly, 69% of all respondents say that developers are expected to write secure code, yet 68% of security professionals feel that less than half of developers are able to spot security vulnerabilities. When developers are not able to see security issues, security teams later in the process must catch issues and request fixes. By contrast, earlier detection of security problems helps save developer time and resources.

The survey, however, notes a growing set of application security methods being used by development teams. Dependency scanning, made popular by an entire ecosystem of new automated code scanning tools, tops the list. All told, the most popular methods are:

  • 56% - Dependency scanning
  • 42% - Cloud security
  • 41% - Container security
  • 35% - SAST
  • 29% - License compliance
  • 22% - DAST

GitLab is likely trying to position itself as a DevSecOps trailblazer, unifying the most crucial development workflows under one platform. A few weeks ago, GitLab announced the latest version of its code repository hosting platform. Security dashboards, auto remediation tools, and security approvals brought serious security workflows to the traditional code repository workflows. Security and code management on the GitLab platform are now deeply intertwined, a strong indication of its enterprise-focused ambitions aimed at streamlining complex software development processes in large engineering teams. While GitHub soared in popularity with its hospitality to the open source world, GitLab is attempting to hijack the intensifying demand for developer-led security on its path toward becoming a more dominant platform.

Small bytes

  • 10x engineers: comparing research and stereotypes [JASON CRAWFORD]
  • Shape up: a free book about how to stop running in circles and ship work that matters [RYAN SINGER]
  • What programmers can learn from rappers [DEV.TO]
  • How COBOL still powers the global economy at 60 years old: appreciating the history of software development [TPR]


  • Learn Regex The Easy Way will walk you through everything you need to know about regular expressions [GITHUB]
  • Vector is an open-source utility for collecting, transforming, and routing logs, metrics, and events [VECTOR.DEV]
  • GitMerch will create a shirt using your contribution graph on GitHub [GITMERCH]
  • The Glitch VS Code extension brings collaborative editing and instant application deployment on Glitch to your editor [VS CODE]
  • ImportDoc will let you use the content of any Google Doc in any web page [IMPORTDOC]
  • Place Keanu is an image placeholder tool for when you need a little more Keanu in your life [PLACEKEANU]
Never miss the big news

Every week, our team will send you three of the most important stories for developers, including our analysis of why they matter. Software development changes fast, but src is your secret weapon to stay up to date in the developer world.

Featured articles
Made with by Software. Read more about our mission.