141–150 of 277 posts
Wasn't Go supposed to be "simple"? I remember how Go advocates used to boast about not having generics and now it almost seems like Go is trying to become some sort of C# or Java Frankenstein. I'm not even trying to badmouth Golang - just legitimately confused.
> First, generic methods are now supported > Generic functions can now be used without explicit type arguments Great! This was an ergonomic code issue I hit when trying to create a universal handler/controller generic that could hydrate/populate function arguments (from a request body) without having an actual copy of the arguments: https://github.com/xeoncross/mid/blob/main/handler.go#L12
Earlier quoted context omitted.
That must be why traffic lights and electrical wires and transit maps are all black and white...
That’s an interesting point. The reason traffic lights are colored is because they are showing distinct states of the same thing and the color is the means of differentiating. Same for transit maps: different routes are colored to distinguish them from other routes, which is especially useful if they overlap. But that’s not what syntax highlighting does. The equivalent of your examples would be to not highlight the s…
Earlier quoted context omitted.
Generics were always planned, of course: https://www.youtube.com/watch?v=rKnDgT73v8s&t=3267s Rejecting templates does not mean rejecting generics.
> Generics were always planned, of course ... This is provably incorrect. The position held for many years by the language authors was[0]: 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 t…
By run-time they mean compile-time? There shouldn't be a run-time penalty right?
Also, is there some measure of the additional compilation cost now that generics has been added?
I really want to like Go, but I can't stand looking at Go code. The error handling is such a turn off.
The SIMD stuff is incredible. I have been having lots of fun with it. You can use LLMs as a scalar to SIMD transpiler, it works amazingly well. Sure a SIMD expert writing assembly can probably do a better job than an LLM using these new intrinsics, but it’s still massively faster.
It's relatively straightforward to read and to write code using Go's SIMD package (the caveat being that you have to convert your data to SoA manually), and it gives comparable performance to other languages, since there's little in the way of GC overhead, bounds checking, etc, in this case.
So SIMD not only increases performance on its own, but it also closes the performance gap between Go and C++ / Rust, which has been a major cause for rewrites in the past. The memory usage overhead due to GC doesn't go anywhere of course, so there are still performance reasons to "Rewrite in Rust", but it's now become much easier to just optimise the hell out of Go code instead.
I have recently been spending time learning go, really really liking the language, awesome standard lib, excellent tooling and great experience. It sounds like the dumbest thing in the world, but I love the import system auto-adding stuff inside of vscode when I need it. just slick.