181–190 of 207 posts
Earlier quoted context omitted.
Claude will migrate your whole repo in an hour.
I assume they will eventually add those to `go fix` too, so you don't even need Claude for the most basic refactors (the more complex ones, sure).
Earlier quoted context omitted.
In Rust this is solved by defining a local trait and methods implemented for a trait are only available if the trait is imported. This is in contrast to Go where methods are not namespaced at all. But there are almost certainly many other ways of solving the problem. I was a little surprised how often I ran into this issue when using libraries that started defining structures as generic containers.
Yes, so that is exactly what I don't understand, that makes compilation flow sensitive in a way that Go avoids by design in order to remain fast.
But traits wouldn't really make sense for Go -- my point was that there is are solutions for this problem in other languages; Go's original design goals don't gel well with generics which leads to these kinds of issues. They felt generics weren't necessary so they didn't design Go with them in mind.
> Since the addition of generics in Go 1.18 and iterators in Go 1.23, it has become possible for library-defined types to achieve comparable ergonomics to built-in types ... For those who've been following Golang more diligently than myself: Is there a way now to define a slice-based type that enforces strict typing of its index, and yet preserves the compactness of the standard syntax "s[i]"?
Earlier quoted context omitted.
People use Go vs Java not because of the language differences but because of massive improvement that GO runtime is compared to JVM. It is crazy that people still don't understand why JVM sucks, and why GO's approach to minimize GC pause latency is far superior design decision compared to whatever JVM has been trying to do with its GC iterations for god knows how many years with gazzillion different variants that all…
Pretty outdated take. Java’s GCs are a generation ahead of Go’s.
Go wins not by technical ingenuity, but by simply not making fundamentally bad decisions in the first place.
Earlier quoted context omitted.
You mean how Ada, Delphi, D, OCaml compile?
And your point is? They didn't know how to do it "correctly" -- it took outside help from Philip Wadler (who helped with Generics in Java) to make it work acceptably. Of course the core team were a big bunch of dumb old stupidheads and they made a dumb language for dumb people, so you win, you're smarter than them.
Of course the language is for dumb people, Rob Pike even said it officially, poor souls that apparently cannot master better tools, even though they are able to work around Google's stupid hiring practices.
Earlier quoted context omitted.
Go only took off thanks to Docker pivot from Python into Go, and Kubernetes from Java into Go, after the respective teams got some Go folks into the project. The usual RIX approach, followed the whole devops hype cycle that created all those CNCF projects half of which no one in devops space actually knows they exist.
And the kubernetes code and APIs still read like corporate Java for years after, too
Alone the code generation machinery that Kubernetes used to have for working around lack of generics.
Earlier quoted context omitted.
Actually welcome to Smalltalk, 1980's, because that is where collections, and iteration with blocks, comes from as inspiration to Java, and all the folks that think LINQ was a .NET invention.
And, as with most important lessons in programming, welcome to LISP in the 1950s, because that is where Smalltalk got its inspiration. :-)
Earlier quoted context omitted.
Really wearing the team's t-shirt there, Go was barely proven on the language adoption battlefield when Go heads preverted the direction Docker and Kubernetes were going, it wasn't even 1.0. Lots of languages are full of dead projects that never gained notoriety. In fact, YouTube downloader which is another "success" only happened, because once again, it was a gopher that forced a RIG, it was working perfectly fine.
> Really wearing the team's t-shirt there Ad hominem is a logical fallacy. > Go was barely proven on the language adoption battlefield when Go heads preverted the direction Docker and Kubernetes were going, it wasn't even 1.0. Exactly. All these projects chose Go many years before anyone, outside of Docker, had heard of Docker. This idea that Go was some kind of underground language until Docker and Kubernetes arrive…
Earlier quoted context omitted.
Yes, so that is exactly what I don't understand, that makes compilation flow sensitive in a way that Go avoids by design in order to remain fast.
Not really, Go already disallows import loops so even if Go did have exportable traits the compilation flow would be the same. But traits wouldn't really make sense for Go -- my point was that there is are solutions for this problem in other languages; Go's original design goals don't gel well with generics which leads to these kinds of issues. They felt generics weren't necessary so they didn't design Go with them i…
So even if generics were there from the 'get-go', I am not sure this exact feature would be added anyway. In fact, it is mostly contrary to Go's structural polymorphism, let alone parametric polymorphism.
Typically what you want would be defined as a function, a specific wrapper type... If it is not already a common method of each shape.
So far, I don't feel like the design of Go's generics suffers from any real issue. The implementation is not 100 percent done yet. But the plan looks sound to me.
Earlier quoted context omitted.
Pretty outdated take. Java’s GCs are a generation ahead of Go’s.
Yeah, they have to be in order to make up for the braindead decision of making every variable a pointer to heap allocated memory. Go wins not by technical ingenuity, but by simply not making fundamentally bad decisions in the first place.