Insert Your Favorite Programming Language Here – InApps 2022

Let’s face it: we can let our programming language biases and fandom get in the way. We can hate on PHP the way a native Bostonite hates on the New York Yankees and blindly heap praise on Go like an Apple fanboy with an unopened iPhone in hand. We read the latest surveys and language rankings with baited breath, in hopes of justifying our prejudices and emboldening our biases.

This “programming language dogma,” as API evangelist Kin Lane puts it, is more than just fandom, however, and it can really get in the way of getting things done. In the world of API design, however, its absence has been a boon. “The absence of programming languages in the API design, management, and testing discussion is why they have been so successful,” Lane writes. “People in these disciplines have been focused on the language agnostic aspects of just doing business with APIs.”

Now surely, this is not to say that there aren’t advantages of one language over another. Of course, there are. Different languages are good for different things, but the idea of “language agnosticism” caught my eye. Lane continues, explaining how these dogmas can trap us as developers.

“It is hard for developers to transcend their primary programming language, and learn multiple languages, or think in a language agnostic way,” Lane writes. “It is not easy for us to think out of our boxes, and consider external views, and empathize with people who operate within other programming or platform dimensions.”

Meanwhile, another story this week touches on the same idea. In much the same way that Lane advocates for language agnostic API design, Pulumi, an infrastructure startup out of Seattle, is working to simplify things by letting you stick with the language you rode in on, rather than saddling you with learning yet another. As Techcrunch’s Frederic Lardinois writes of the new service, Pulumi “wants to make it easier for developers and ops team to define their infrastructure by writing code. Instead of using a cloud-specific configuration language, the service’s tools allow developers to define the infrastructure for their applications in the same programming languages they already use for the applications.” Currently, the platform lets users choose from JavaScript, TypeScript, Python and Go, with support for .NET, Java, C# and node.js on the way.

And with that, we can get on with the language-specific or agnostic business of taking a look at the latest developments the world of computer programming in the week past…

This Week in Programming

• Ruby on Rails Has Still Got It: That’s right, despite all the poo poo-ing you might have heard about Ruby on Rails, demand for Ruby on Rails is still huge, according to Gartner software developer Yoel Blum, who explored the idea by looking at job postings on LinkedIn. According to Blum, “Rails is more popular than Django, Laravel or Express,” even beating out ASP.NET, and “is probably the most used full stack web technology for U.S web-based startups.” By the same methodology, Blum finds that Ruby rounds out the top five languages, nearly tied with PHP, with Python, Java, and Javascript leading the pack. Additionally, Blum looks at coding camps and finds that “Rails is still the most taught web framework in prominent coding boot camps… because boot camps know the market and care about their graduate’s employment prospects.” There’s that programming language dogma for you, huh? People may tell you that Ruby on Rails is so 2005, but it looks like it may be so 2018 too.
• Continuing the Conversation about Rust: Rust core team member Aaron Turon continues his insightful look into the growing pains the Rust community has been experiencing lately and the steps they’re taking to address them in part three of his listening and trust series. We looked at the first post, about the difficulties the Rust community faced in the RFC process, a few weeks back and now Turon turns his focus on “one of the most intense discussions the Rust community has had: the module system changes that were part of last year’s ergonomics initiative.” The best part of these posts, in my humble opinion, is that they don’t focus on the technical issues at hand, but rather the social and group dynamics that are present in any number of large, open-source projects. If these sorts of contemplative, navel-gazing blog posts from someone who plays a key role in developing an open source language are of interest to you, keep an eye out, as at least one more post is in the works.

• Google’s Flutter Release Preview Available: Moving on to some news, SDTimes reports that the Flutter release preview 1 is now available. Flutter is Google’s mobile SDK for creating native applications, and this release “signals our confidence in the stability and quality of what we have, and our focus on bug fixing and stabilization,” Google wrote in a post. First announced last month at Google I/O, SDTimes reports that Flutter “has seen a 50 percent increase in active users and has become one of the top 100 software repos on GitHub.”
• End of Life for NET Core 2.0: A quick heads up, as Microsoft announced this week that .NET Core 2.0 will reach End of Life on Sept. 1, 2018. According to their schedule, “as a non-LTS release, [NET Core 2.0] is supported for 3 months after the next release. .NET Core 2.1 was released on May 30, 2018. As a result, .NET Core 2.0 will be supported until Sept. 1, 2018.”
• GitLab Releases a Web IDE: The latest announcement by GitLab — the GitLab Web IDE — seems to be a head turner for many. While some seem to question the need for a web-based IDE from GitLab, others applaud the news as yet another player entering the field. Unlike many introductory blog posts, though, this one doesn’t summarily list features and leave you with a link. Instead, the post offers some insights into the internal debate that led to the birth of this Web IDE. “At some point, it dawned on us that the repository view might be the right vessel. Jacob set up a proof of concept where he made our file viewer work in the context of a file editor. It removed the page refresh when switching between files and it approached editing from a branch perspective instead of per file. The result was the beginning of the Web IDE, although it was called the ‘repo editor’ at that time.”

Feature image via Pixabay.