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

 


Forgot your password?
Close
typodupeerror
×
Programming Google

'Biggest Change Ever' to Go Brings Generics, Native Fuzzing, and a Performance Boost (go.dev) 35

Posted by EditorDavid from the ready-set-Go dept.
"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.
This discussion has been archived. No new comments can be posted.

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

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

Comments Filter:

  • Go is yet another C-like statically typed, compiled programming language designed at Google[10] by Robert Griesemer, Rob Pike, and Ken Thompson.[11] Go is syntactically similar to C, but with memory safety, garbage collection, structural typing,[5] and CSP-style concurrency.[12] The language is often referred to as Golang because of its former domain name, golang.org, but the proper name is Go.

    • Re: (Score:3, Informative)

      by Anonymous Coward

      its also referred to as golang because trying to search for "go how do I do something" will turn up a bunch of useless results, while "golang how do I do something" will not. No one using it calls it golang in discussion, but good luck searching for specific things dealing with the language without using 'golang'

  • The original language designers stubbornly insisted Go did not want nor need generics.

    • Wow. It's almost as if... some time elapsed... and people considered it... and changed their minds on something.

      I know that makes them anachronistic holdovers on 2022. What tools they must be.

    • My understanding is that this is some sort of partial implementation of genetics

    • Re: (Score:2)

      by nagora ( 177841 )

      Generics are generally an indication that the language's object model is flawed; it's basically a patch.

      • OK - I'll bite ...

        So how would you write a type-safe generic list, for example, in a language that doesn't support generics but has a suitable object model ?

      • And why would that be the case?

        Hint: half of the generics are not even using objects but native types, aka int64 or float64.

        • Re: (Score:2)

          by nagora ( 177841 )

          Native types not being objects is the sort of flaw I'm talking about.

          • Well,
            you have to either bite this bullet or that one.
            You can not have both.

            If "native types" are objects, they are obviously not native types anymore.

    • You're lying: [archive.org]

      Why does Go not have generic types?

      Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do.

      Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. Meanwhile, Go's built-in maps and slices, plus the ability to use the empty interface to construct containers (with explicit unboxing) mean in many cases it is possible to write code that does what generics would enable, if less smoothly.

      This remains an open issue.

      • 15 years to add something that was commonplace in other languages at the time because they didn't "feel an urgency" is because Pike and Thompson have stated in interviews that they hated C++ with a passion and wouldn't add features they deemed made the language resemble C++.

        That they have a FAQ entry stating you can kludge your way around it and achieve code "less smoothly" suggests its omission was a design flaw from day 1.

        • So you admit lying about "original language designers stubbornly [insisting] Go did not want nor need generics". Glad we cleared that up.

          • Semantics of C# and Java generics were well understood when the language was created - their goal was to create a minimalist language that left out features they didn't require.

            Direct quote from Thompson "we started off with the idea that all three of us had to be talked into every feature in the language, so there was no extraneous garbage put into the language for any reason."

            So they considered generics to be "extraneous garbage".

            So fuck off with your 'lying', now you're just trolling.

            • Stop lying again. You're the one who's just trolling here. That sentence did NOT mean that generics were "extraneous garbage". That sentence means that they accepted the approach that whatever all three of them thought was a good idea was assumed to be almost certainly not garbage, and therefore reasonably safe to add without backing themselves into a corner, but that they were much less confident regarding adding things about the design of which they weren't 100% sure at that time. That sentence most assur

            • Java and C# diverged greatly on this point.

              Java goofed BIG-TIME by type erasure, making it impossible to use reflection on generic types (IIRC).

              C#/.NET did not make that mistake.

              I happen to use this feature in C# very frequently, to do object mapping and reduce boilerplate code among many other reasons. I'm sure that if I had to, I could live without it, but I sure wouldn't like that.

          • So you admit that you are an asshole?
            Someone being misinformed and repeating his misinrromed opinion - alas, even on the intertubes - does not make him a liar.
            It only makes him: wrong
            Dumbass.

  • Too little, too late (Score:4, Informative)

    by arQon ( 447508 ) on Sunday March 20, 2022 @05:06AM (#62373627)

    Go has lots of good (or at least, good-ish) things about it, but the absence of generics was one the worst of multiple crippling mistakes and limitations to it *10 years* ago.

    95% of the "developers" who adopt new languages do so solely because it's the flavor of the month, not to actually solve problems or produce real work in. While Go did have that position for a while, those gadflies have long since moved on to whatever the NEXT Shiny Thing was at least twice, and the simple reality is that there aren't many cases where Go - even in this new improved form - is actually the "best" tool for the job, just as it hasn't been so far; and plenty for which it's flat-out unsuitable thanks to the GC. (Though I'm sure that won't stop the likes of Tata or Capita recommending it for something 3 years from now. :P).
    It was never competing with C/C++, any more than it was competing with JS: it's a "tween" language, and while that is the realm that a lot of these "experimental" (or "ego", or however else you like to think of them) languages play in, it's one that's also occupied by 800lb PHP gorillas at one end and Java ones at the other, who barely even notice all these insects like Ruby and Go, no matter how hard the press tries to sell them.

    Since Go never got even remotely close to critical mass, and is only rarely a good choice even for the limited scope it CAN work in, it just doesn't have a path to growth and never will. It had its shot, and it missed - there are no technical OR nontechnical (staffing etc) incentives to use it for almost any new project, nor to port any existing system to it, etc.
    So it's already long since been doomed to be just a footnote, along with a hundred other languages that have come and gone over the years, all with the exact same hype cycle and the exact same end result. Like the rest of those, I'm sure it'll retain a diehard group of fans for a few more years, and plenty of devs who end up having to return to dealing with PHP and similar horrors on the their next project may occasionally think fondly of it - but also like all those others it's never going to have some magical resurgence, and will just slowly continue its ride into irrelevance.

    It's great that the language has finally improved, but that needed to happen 7 or 8 years ago while at least SOME people still cared about it and were willing to consider it, but that time is long gone. Technically it's outlasted plenty of other Google projects though, so, congrats on that least. :)

    • Go is actually pretty popular. It's memory safe and type safe, and it offers better performance and lighter footprint than Java, c#, and others of that nature, even when they're native compiled, in addition to being notoriously easy to learn, on par with python, and having very fast compile times.

      It's actually more built for back-end applications running on servers in environments where quickly being able to prototype and make iterative improvements to your code. Not really meant to be user facing as it has

    • Re: (Score:3)

      by _merlin ( 160982 )

      Although I don't actually use Go for real work (I'm mostly a C++ guy), I can see the benefits of it that I think you're completely missing: it's a compiled language with C-like syntax that has Erlang-like threading and messaging. Erlang can do lots of cool stuff, but it's interpreted, and the syntax is unfamiliar to a lot of developers. Go performs better than Erlang and has more approachable syntax for developers familiar with C-like languages (including C++, Java, C#, etc.).

      • Erlang is compiled, and AFAIK always was.

        • Re: (Score:2)

          by _merlin ( 160982 )

          Erlang is compiled to BEAM [wikipedia.org] bytecode. The loader performs an additional optimisation pass and converts it to the internal representation used by the interpreter. It isnâ(TM)t compiled to native code. An x86-64 JIT was added in 2020, but it's relatively unsophisticated, e.g. it can't switch between the JIT and interpreter on-the-fly (if you're using the JIT, all code needs to be JIT compiled to machine code before it can be run), it compiles one virtual machine instruction at a time using hand-written

    • This is a terrible take. Golang is used in lots of large production environments. Twitch, discord and docker to name just a few. This is not some toy language flavor of the month bullshit like you claim. It is a better option than JS for all web server applications. Package management can be done using actual GIT HASHES instead of arbitrary version numbers through npm/yarn. It is portable and doesn't run on a VM. It is SIMPLE and forces proper error handling. Honestly, this sounds like a post from someone w

Slashdot Top Deals

One man's constant is another man's variable. -- A.J. Perlis

Close