4

'Biggest Change Ever' to Go Brings Generics, Native Fuzzing, and a Performance B...

 2 years ago
source link: https://developers.slashdot.org/story/22/03/19/2248232/biggest-change-ever-to-go-brings-generics-native-fuzzing-and-a-performance-boost
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

'Biggest Change Ever' to Go Brings Generics, Native Fuzzing, and a Performance Boost

Catch up on stories from the past week (and beyond) at the Slashdot story archive

binspamdupenotthebestofftopicslownewsdaystalestupid

freshfunnyinsightfulinterestingmaybe

offtopicflamebaittrollredundantoverrated

insightfulinterestinginformativefunnyunderrated

descriptive

typodupeerror

Do you develop on GitHub? You can keep using GitHub but automatically sync your GitHub releases to SourceForge quickly and easily with this tool so your projects have a backup location, and get your project in front of SourceForge's nearly 30 million monthly users. It takes less than a minute. Get new users downloading your project releases today.
×

"Supporting generics has been Go's most often requested feature, and we're proud to deliver the generic support that the majority of users need today," the Go blog announced this week. *

It's part of what Go's development team is calling the "biggest change ever to the language".

SiliconANGLE writes that "Right out of the gate, Go 1.18 is getting a CPU speed performance boost of up to 20% for Apple M1, ARM64 and PowerPC64 chips. This is all from an expansion of Go 1.17's calling conventions for the application binary interface on these processor architectures."

And Go 1.18 also introduces native support for fuzz testing — the first major programming language to do so, writes ZDNet:

As Google explains, fuzz testing or 'fuzzing' is a means of testing the vulnerability of a piece of software by throwing arbitrary or invalid data at it to expose bugs and unknown errors. This adds an additional layer of security to Go's code that will keep it protected as its functionality evolves — crucial as attacks on software continue to escalate both in frequency and complexity. "At Google we are committed to securing the online infrastructure and applications the world depends upon," said Eric Brewer, VIP infrastructure at Google....

While other languages support fuzzing, Go is the first major programming language to incorporate it into its core toolchain, meaning — unlike other languages — third-party support integrations aren't required.

Google is emphasizing Go's security features — and its widespread adoption. ZDNet writes:

Google created Go in 2007 and was designed specifically to help software engineers build secure, open-source enterprise applications for modern, multi-core computing systems. More than three-quarters of Cloud Native Computing Foundation projects, including Kubernetes and Istio, are written in Go, says Google. [Also Docker and Etc.] According to data from Stack Overflow, some 10% of developers are writing in Go worldwide, and there are signs that more recruiters are seeking out Go coders in their search for tech talent..... "Although we have a dedicated Go team at Google, we welcome a significant amount of contributions from our community. It's a shared effort, and with their updates we're helping our community achieve Go's long-term vision.
Or, as the Go blog says:

We want to thank every Go user who filed a bug, sent in a change, wrote a tutorial, or helped in any way to make Go 1.18 a reality. We couldn't do it without you. Thank you.

Enjoy Go 1.18!

* Supporting generics "includes major — but fully backward-compatible — changes to the language," explains the release notes. Although it adds a few cautionary notes:

These new language changes required a large amount of new code that has not had significant testing in production settings. That will only happen as more people write and use generic code. We believe that this feature is well implemented and high quality. However, unlike most aspects of Go, we can't back up that belief with real world experience. Therefore, while we encourage the use of generics where it makes sense, please use appropriate caution when deploying generic code in production.

While we believe that the new language features are well designed and clearly specified, it is possible that we have made mistakes.... it is possible that there will be code using generics that will work with the 1.18 release but break in later releases. We do not plan or expect to make any such change. However, breaking 1.18 programs in future releases may become necessary for reasons that we cannot today foresee. We will minimize any such breakage as much as possible, but we can't guarantee that the breakage will be zero.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK