This Week in Programming: What’s Holding Back Rust and Go?

This past week, we saw both the Rust and Go teams release their annual survey results for the past year, highlighting the languages’ various use cases and patterns, the positive steps they’ve taken in that time, and the hindrances still seen by developers using the languages. Of course, choosing whether to use one over the other is a choice that can depend strongly on the developer and the task at hand, the surveys show that it can also be a matter of the company your work for or the public cloud environment you use.

In simple terms of popularity, Go leads Rust in three common language indexes, the PYPL Popularity of Programming Language index, the TIOBE Index, and the Redmonk language rankings. If we’re looking for a simple reason for this, it might be found in the one aspect of the Rust survey highlighted by InfoWorld, the fact that developers cite barriers to Rust language adoption, which include not only a need for better documentation (something the team has been working on over recent years) but also the steep learning curve the language presents. They note that just 37% of users felt productive in less than a month, with it taking nearly a year for a majority of respondents to feel productive using the language. DevClass, meanwhile, remarks that Rust continues to be loved by developers but, as we noted, lags behind in popularity partly because companies are not adopting the language as much as Go and that “learning resources, better IDE integration, and GUIs would help to convince people to use Rust more.” Straight from the horse’s mouth, the Rust team writes that “When we asked why someone had stopped using Rust, the most common response was ‘My company doesn’t use Rust’.”

How I get out of bed each day. pic.twitter.com/f2iyXzaZMe

— Casey Liss (@caseyliss) April 21, 2020

As for the Go survey, JAXEnter focuses on one particular result from the survey that has ever been a sticking point for its developers — the lack of generics — with 79% saying the feature is needed. In keeping with looking at the down side of things, SDTimes examines why the language isn’t used more often, writing that “the reasons why developers can’t use Go more is because they are working on a project in another language (56%), working on a team that prefers another language (37%), and the lack of a critical feature in Go (25%),” pointing to “generics, better error handling, functional programming features, stronger type system, enums/sum types/null safety, increased expressivity, and improved performance and runtime control” as missing features of note. Meanwhile, The New Stack’s Lawrence Hecht gleans another insight from the survey results — that Microsoft Azure has a Go problem, as evidenced by the fact that “only 49% of this group are at least moderately satisfied using Go on Azure over the last year,” while “73% and 71% feel the same way about their Go experiences with Amazon Web Services (AWS) and Google Cloud Platform (GCP) respectfully.”

Wherever you stand on the debate over whether to use Rust or Go, now at least you’re armed with the various reasons not to use each.

This is new developers working on "legacy code" at literally EVERY every successful software company. https://t.co/p5srKncKnU

— @jpaulreed@mastodon.social (@jpaulreed) April 22, 2020

This Week in Programming

• TorchServe, An Open Source Server Model for PyTorch: Facebook and AWS have open sourced a new model server called TorchServe, which makes it easier to deploy and manage deep learning models built with the popular PyTorch open source library. The TorchServe model server automatically creates a prediction API backed by a scalable web server, runs preprocessing and postprocessing code on prediction requests, and provides features like logging, monitoring, and security. In a nutshell, AWS writes, it “makes it easy to deploy trained PyTorch models at scale without having to write custom code,” and comes with support for “any machine learning environment, including Amazon SageMaker, container services, and Amazon Elastic Compute Cloud (EC2).” On a related note, PyTorch 1.5 was just released with new and updated APIs, including what it calls a “significant update to the C++ frontend” — find the full details in the release notes.

https://twitter.com/catalinmpit/status/1252922899805155328

• gRPC Gets Busy With Kotlin, JavaScript: The gRPC team has been busy this past week, releasing both Kotlin support and gRPC-JS 1.0 for JavaScript, a “pure-TypeScript reimplementation of the original Node gRPC library, grpc.” gRPC is a Google-built open source project that provides the ability to perform remote procedure calls (RPCs), both for last-mile computing on mobile and web, but also as a way to connect microservices. In the case of Kotlin, a popular JVM-based programming language, developers can now build everything from mobile apps to cloud microservices using the newly open-sourced gRPC Kotlin, as well as deploy gRPC Kotlin services on Cloud Run. As for gRPC-JS (@grpc/grpc-js), it provides features that they say “should cover most use cases” and intends to replace the original Node gRPC library (grpc), which is set to be deprecated within the year.
• Amazon AppFlow Eases SaaS Integrations: Amazon has announced Amazon AppFlow, a new service that automates data flows between AWS services and external SaaS applications like Salesforce and Zendesk, among others. Basically, instead of requiring developers to build custom integrations between these services to securely transfer data, Amazon will do it for you automatically, according to criteria such as scheduled times, manual triggers, or events. TechCrunch comments that “Unlike some of its competitors, though, AWS is positioning this service more as a data transfer service than a way to automate workflows, and, while the data flow can be bi-directional, AWS’s announcement focuses mostly on moving data from SaaS applications to other AWS services for further analysis. For this, AppFlow also includes a number of tools for transforming the data as it moves through the service.”

• The End of Python 2.x: The CPython core developers have released Python 2.7.18, the last release of Python 2 — no really, this is the last release of Python 2.x, a move many years in coming. “It’s time for the CPython community to say a fond but firm farewell to Python 2,” they write. “Python 2.7 has been under active development since the release of Python 2.6, more than 11 years ago. Over all those years, CPython’s core developers and contributors sedulously applied bug fixes to the 2.7 branch, no small task as the Python 2 and 3 branches diverged.”
• GitHub Actions Grows, Gets Org-Wide Runners: GitHub is touting GitHub Actions’ “community momentum”, noting that GitHub Marketplace now has more than 3,200 Actions, which it says ” represents a 500% increase in less than six months.” Beyond the numbers, it also announced that organizations can now share self-hosted runners across multiple repositories in that organization, alongside general improvements, including directory defaults, job outputs to allow downstream data passing, and other customization features. In a separate announcement, GitHub also said that scheduled reminders are now officially out of beta and ready for use.

https://twitter.com/KeziyahL/status/1252625942679298050