Golang's Most-Downloaded Beta Ever Brings Support for Generics, Fuzzing (thenewstack.io) 27
From Mike Melanson's "This Week in Programming" column:
The second beta of Go 1.18 was released this week, following up the first beta, which the team writes was "the most downloaded Go beta ever, with twice as many downloads as any previous release." With it comes support for generics in both gopls [the official Go language server] and Visual Studio Code's Go extension.
In addition to the long-awaited generics feature, Go 1.18 introduces fuzzing and the new Go workspace mode.
Having put the first beta through its paces, the team also writes that it "has also proved very reliable; in fact, we are already running it in production here at Google." Nonetheless, Beta 2 is here to make sure everything is good, as Beta 1 uncovered some "obscure bugs in the new support for generics".
The release candidate is also expected later this month, with the final Go 1.18 release slated for March. And while we're talking about Go 1.18, Go AWK creator Ben Hoyt decided to take a look at Go performance from version 1.2 to 1.18 using the performance of his own tool "when compiled using each released version of Go from 1.2 (the earliest version I could download) to 1.18 (which is in beta now)." As you might expect (or hope, rather), Go has picked up the pace over recent versions. "Overall, countwords is now about 5x as fast as it would have been with Go 1.2, and sumloop is 14x as fast! (Though I first released GoAWK when Go was already at version 1.11, so it wasn't around for the huge early gains.)," Hoyt writes.
"For an actively-developed compiler like Go, it's cool to be able to get performance improvements just by waiting and letting others do all the hard work. :-)"
In addition to the long-awaited generics feature, Go 1.18 introduces fuzzing and the new Go workspace mode.
Having put the first beta through its paces, the team also writes that it "has also proved very reliable; in fact, we are already running it in production here at Google." Nonetheless, Beta 2 is here to make sure everything is good, as Beta 1 uncovered some "obscure bugs in the new support for generics".
The release candidate is also expected later this month, with the final Go 1.18 release slated for March. And while we're talking about Go 1.18, Go AWK creator Ben Hoyt decided to take a look at Go performance from version 1.2 to 1.18 using the performance of his own tool "when compiled using each released version of Go from 1.2 (the earliest version I could download) to 1.18 (which is in beta now)." As you might expect (or hope, rather), Go has picked up the pace over recent versions. "Overall, countwords is now about 5x as fast as it would have been with Go 1.2, and sumloop is 14x as fast! (Though I first released GoAWK when Go was already at version 1.11, so it wasn't around for the huge early gains.)," Hoyt writes.
"For an actively-developed compiler like Go, it's cool to be able to get performance improvements just by waiting and letting others do all the hard work. :-)"
Re: Cheer! Go! Cheer! Go! Cheer! Go! (Score:2)
Anything is better than Java. Who the fuck wants a programming language that has zero ways of dealing with two dependencies that require different versions of a third dependency? Yeah sure, there's shading, but it's an ugly as hell hack that doesn't even work in many cases. Java is a fucking abortion.
Re: (Score:2)
generics (Score:3)
but often I see them implemented by a language as at least one of (a) retardedly limited (b) retardedly complicated (c) retardedly cryptic
T foo(T x, T y) { return x + y; }
if T is hoisted into generic-land, then that + operator breaks nearly universally across languages. Languages like C# do not give you a way of specifying that the generic type must be a core numeric type and then let you treat its instances like one - I think its a limitation of the clr
Does Golang do better?
just as it turns out that generics are useful, it also turns out that forcing the universe into "everything is a function" doesnt make for fluently readable code.
Re: generics (Score:2)
That works fine in Rust so long as you implement the Add trait for T. If you don't, it won't compile.
I've never tried to implement that in C# classes, but I'm not sure that would be a CLR limitation. The CLR actually behaves more like an actual machine, unlike say Java where some language specific constructs (like the garbage collector) are part of the so called "virtual machine." You can theoretically compile just any language to the CLR, in fact somebody is working on making Rust compile to the CLR. Thoug
Re: (Score:2)
I did some work on NETMF for a research project back in the late 2000s.
For example generics are first-class primitives in the CLR.
Re: (Score:2)
In Ruby that would rarely break anything, and where it did it would be easy to add + methods.
Very typical pattern in duck-typing.
Re: (Score:2)
What does `boolean foo(boolean x, boolean y) { return x+y; }` return?
Does addition suddenly change into a boolean and?
What about `int[]` does in concatenate, or perform a matrix operation?
Re: (Score:2)
so it doesnt matter
why would you blather on about types that ARENT numeric (as the post described) and, more interesting dont have an addition operator defined (as the post used)
Why not ask what the language is supposed to do if you hand it a video file for a string, yeah? doesnt play, yeah? garbage in garbage out yeah? same with your brain
Re: (Score:2)
Re: (Score:2)
Booleans are essentially numeric types
So what does it mean when you add them? Perhaps you could answer the ignorant twat that asked, yes?
Oh thats right, you are stretching as much as he was, just in a different direction.
These are excuses not reasons
Dos Equis (Score:5, Funny)
Having put the first beta through its paces, the team also writes that it "has also proved very reliable; in fact, we are already running it in production here at Google."
That reminds me of my favorite "The Most Interesting Man in the World" meme, which I saw pinned to someone's cubicle wall a long time ago:
"I don't always test my code. But when I do, I do it in production."
About Bloody time (Score:3)
Now, a generic is progress - we are finally half-way there. I would still prefer to go ALL THE WAY and take a cast in preference to that. "Yes, I know what I am doing you f*cking nanny state chocolate f*cktory, stop trying to prevent me from doing that".
Why bother with GoLang? (Score:2)
C#/.Net and Java are infinitely more sophisticated.
C is infinitely more nasty, but has its place for tiny microcontollers.
Golang looks like it was invented by C programmers who never heard of Lisp/Java/.Net and discovered mark/sweep garbage collection.
So maybe in 20 years time GoLang will be as powerful as C#?
Re: (Score:3)
Re: (Score:2)
Actually, one of them was one of the two guys who wrote C. Gent by the name of Kernighan. Got his book The Go Programming Language sitting on my desk now.
Hmm. Well, that explains a lot, actually.
I remember when C first came out thinking (with many others) that nobody would use such a terrible language. It would cause endless problems with memory corruptions, buffer overflows etc.
So I will probably be wrong about Golang as well.
Mark/Sweep garbage collection is a fantastic technology ... if you do not know of any of the newer gc techniques.
Zig vs Go (Score:4, Interesting)
A couple of weeks ago, someone suggested zig to me.
I've given it a go (pun intended) and it's turning out to be pretty much exactly what I'm looking for - a C replacement that solves some of C's problems without being an OO or functional theoreticians wet dream. It's practical, non OO, supports name spaces and generics, works well with C, has great error handling, compiles quickly and the build language for zig is zig.
Go in comparison was a bit of a pain in the neck and I didn't find it provided a features or an environment that I found very compelling.
Zig isn't perfect yet. It's not got to 1.0 yet. I've managed to crash the compile with some inline assembly. For general coding tasks of the type you might code in C, it's great.
Re: (Score:2)
I'm not entirely sure how I feel about it (zig) yet, but it's if nothing else very interesting.
Thanks for the info.
Re: (Score:2)
Also look at Nim. It's also a better Go IMO.
It's different from Zig, but interops with C easily, given that it is usually used by compiling it to C (also to C++ or Javascript).
It is more mature than Zig and is a richer language. It can be a better C/C++/Go, depending on whether or not you use a GC.
Go's primary advantage is support from Google and a larger ecosystem. The language itself is very uninteresting and unappealing.
Re: (Score:2)
I've watched the video. I'm not converted yet - like the claim of familiarity with examples of UFCS with very non familiar argument structures. But It might be fine so I'll keep my mind open for a while. My small intestine wanted to reach up and strangle my ventromedial hypothalamus when I saw the long dotted list of function names and a claim that arg1.f.(arg2, arg3 ...) is a natural and better alternative for f(arg1, arg2, arg3 ...). If you are stringing together functional transformations all the time, i
Re: (Score:2)
Don't get me wrong - it's definitely better than go.
NEVER... (Score:1)
Re: (Score:2)
Even when it creates variables you don't want to use !
You have to find a way to use stuff you don't want !
Why bother with it at all? (Score:1)
It should have been there since the start. I don't see this as a feature but the MVP finally being complete. Although I have to say appart from its fast compile time and relatively quick learning curve. What is the advantage of Golang over say Rust? Rust is faster, uses less memory, has generic and has a package manager that actually works. To be honest I don't really understand the niche that Golang is trying to fill it's neither a good competitor for high level languages (too low level) nor a good one for