Go, Rust, GitHub Lead 2021 Stories – InApps is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn Go, Rust, GitHub Lead 2021 Stories – InApps in today’s post !

Read more about Go, Rust, GitHub Lead 2021 Stories – InApps at Wikipedia



You can find content about Go, Rust, GitHub Lead 2021 Stories – InApps from the Wikipedia website

Well, well, well, here we are, having careened into the final days of 2021 with nasal swabs jutting from our noses, Zoom-fatigue having morphed into something more like Zoom-existential-dread, and hopefully, a method or two in place to prevent the eternal doomscroll we perfected in 2020. We made big plans, changed big plans, pondered just how burned out we all really were, and then were later told that, worry not, we’d reverted to pre-pandemic productivity levels.

It’s been a year, hasn’t it?

Each week, I sit down and pick out what I feel are the most interesting, important, worthwhile bits of news, as well as the topics that seem to be at the tips of everyone’s tongues, in the world of software development (and its related fields), and compile them into that week’s This Week In Programming column. While the topics may vary greatly from week to week, some narratives stick with us and are visited again and again.

All that’s to say, there have been a few, in my humble opinion, standout stories from the year past, and I am here to present them to you in no particular order — a brief and certainly not all-inclusive recap, if you will, of a few of the big stories from the year past in programming.

A Decade (or So) Later, Go Gets Generics

As we wrote in the very first weeks of 2021, the time has come, long at last, for Gophers to rejoice, “for the question of whether or not the Go programming language will adopt generics has finally, after many years of debate, been answered this week with the acceptance of a proposal made last month.” In fact, the question of generics has been roiling the Golang community for so long that it was the very first topic that we tackled in this very column, and the same arguments over adding generics have been made long before and ever since.

Read More:   How FluentD Can Help Monitor Microservice Architectures Through Unified Logging – InApps 2022

In the most recent proposal made earlier this year, Golang team member Ian Lance Taylor remarked that generics had, in fact, been “one of the most commonly requested language features” since the language was first released in 2009. To say that generics has been a constant topic of discussion and debate would be an understatement, and even Taylor related the feature’s troubled history in his last proposal, writing that “One of the first (flawed) attempts to add generics to Go dates back all the way to 2010.”

This most recent proposal, however, addressed enough of the concerns to get accepted, and the December 2021 release of Go 1.18 Beta 1 was the first to offer access to the long-awaited feature.

As we noted back in October, however, the Go team decided to tap the brakes on generics just a little bit and not bring the feature straight into the core library. Instead, the proposal by Rob Pike, one of Go’s original designers, was to move the changes into the golang/x/exp repository for the time being, where they “can be tested in production, but can be changed, adapted, and grown for a cycle or two, letting the whole community try them out.” According to a comment by Taylor, “The only public-facing package that uses type parameters in 1.18 will be the constraints package.”

Nonetheless, generics are indeed finally available, and there are plenty of folks out there kicking the tires and examining just when you might want to use the new feature already.

Of course, that’s not the only thing that’s happened in the realm of Go this year — the project also quickly accepted the proposal to add fuzzing to Go’s standard library, which was then released in beta in the Go development branch, dev.fuzz, in Go 1.17 — but generics was definitely the defining feat for Go in 2021.

Rust Is Here to Make Everything Memory Safe

2021 has been a big year for Rust, we would say.

In recent years, many a headline had been written about how difficult the language was to learn and issues around its lack of tooling, but 2021 has been more about the numerous in-roads and developments for the popular open source systems language.

Read More:   Itopia Launches Ready-to-Code Spaces for Remote Developers – InApps 2022

In 2021, Rust is becoming increasingly synonymous with memory safety, and is similarly considered to be the smart replacement for C and C++, as well as for new applications concerned with security. To quote just one recent interview about the choice of Rust, “If you want to go for security on this layer today, Rust is the language to use. That’s it. […] If you start fresh, which we did, you start with Rust.”

But the proof is in the pudding, as they say, and that can be seen with some big-time cases of Rust adoption that really showcase the language’s maturity in the programming language landscape. For example, 2021 has seen Rust make some serious inroads into both Windows and Linux.

Back in April, we wrote that Microsoft was getting Rusty, noting the company’s newly offered course on getting started with Rust alongside the first preview of Rust for Windows, which allows developers to “use any Windows API (past, present, and future) directly and seamlessly via the windows crate.” Microsoft had previously touted Rust as the industry’s “best chance” at safe systems programming, discussing their intentions to slowly switch away from C/C++ to Rust to build its infrastructure software, and this year they started doing just that.

As for Linux, the idea of the Linux kernel getting in-tree support was rather nascent in mid-2020, but by April 2021 it seemed increasingly likely that Rust was headed to the Linux Kernel’s development branch, and by December it was declared that Rust support was “good enough.” While support is “still to be considered experimental,” Rust for Linux project maintainer Miguel Ojeda wrote that “support is good enough that kernel developers can start working on the Rust abstractions for subsystems and write drivers and other modules.”

And, if you need further proof that Rust is good for this sort of thing, look no further than Amazon Web Services‘ efforts with Bottlerocket, a Linux distribution for containers that is largely written in Rust.

GitHub Puts All That Training Data (Your Code) to Use

There is likely no single company we mention more in our weekly This Week In Programming column than GitHub, and this year was no exception.

One particular story from GitHub really stood out, however: the controversy around GitHub Copilot, its perceived copyright infringement and considerations around open source licensing.

Read More:   A Short Stack o’ Controversy at the Tectonic 2015 Summit – InApps Technology 2022

When GitHub first introduced Copilot in June, they revealed that it was built using the OpenAI Codex and “trained on billions of lines of public code,” which many assumed included code under the viral GPL license. The GPL license requires that all derivative works carry that same license, and so accusations immediately surfaced that, if nothing else, GitHub Copilot was in copyright violation.

Unlike Intellisense, Copilot doesn’t merely finish a single line of code, but rather suggests entire blocks of code, and it wasn’t long before the tool was spotted spitting out entire chunks of easily identifiable code. It’s not like GitHub hadn’t thought of this, however, and GitHub CEO Nat Friedman argued that the code most commonly suggested by Copilot was transformed and fell under free use, as outlined in a paper by OpenAI. Not only that but, as one blog post pointed out, GitHub’s terms of service likely covered their use of any code they hosted in training the model. Another post argued that the easy way out of this conundrum would be for Copilot to simply offer attribution when it spits out verbatim code.

On the other end of the spectrum, some called on the Electronic Frontier Foundation (EFF) and Free Software Foundation (FSF) to file class-action lawsuits, and the FSF put out a call for papers, saying that Copilot “as it stands is unacceptable and unjust.” So far, however, no papers have been published, no lawsuits actually filed that we know of, nor any true legal test put to GitHub’s “AI pair programmer.”

On the contrary, at least one report says that GitHub has seen an uptick in Copilot users, and the tool has expanded its reaches to JetBrains’ IntelliJ and PyCharm versions 2021.2 and above and Neovim 0.6 prerelease with Node.js, as well as including support for multiline code completions for Java, C, C++, and C#. And for those of you that find yourselves with a bad taste in your mouth about the whole thing, but nonetheless intrigued, there’s always the numerous open source GitHub Copilot alternatives that you could give a whirl.

In all, GitHub Copilot is just one (somewhat controversial) example of the various features put out by GitHub in the time since its Microsoft acquisition — and over 2021 — that appear to be solidifying Microsoft’s ownership of many a developer lifecycle.




Source: InApps.net

Rate this post
Content writer

Let’s create the next big thing together!

Coming together is a beginning. Keeping together is progress. Working together is success.

Let’s talk

Get a custom Proposal

Please fill in your information and your need to get a suitable solution.

    You need to enter your email to download

      Success. Downloading...