201–207 of 207 posts
Earlier quoted context omitted.
> What do you think Kubernetes is? Essentially an abstraction layer above the infrastructure (physical or virtual). Considering it was released by google AFTER the launch of google cloud platform, i honestly see it as a way to make apps more easily portable off AWS.
Google Cloud platform is based on the internal proprietary version of Kubernetes, Borg.
Earlier quoted context omitted.
This will also be an outdated take in a few months. What’s next?
I assume you're referring to value classes? The very fact that Project Valhalla had to create new opt-in syntax for value classes, in order to get what Go does by default on all its types, is the admission of defeat of a herculean battle of attempting to optimize desite fundamental problems with Java's design. Value classes won't make criticism outdated, because they don't fix any fundamental problems, they just prov…
If your argument is that optional syntax is bad, sure, we can do that, but it has nothing to do with GC performance.
Earlier quoted context omitted.
I assume you're referring to value classes? The very fact that Project Valhalla had to create new opt-in syntax for value classes, in order to get what Go does by default on all its types, is the admission of defeat of a herculean battle of attempting to optimize desite fundamental problems with Java's design. Value classes won't make criticism outdated, because they don't fix any fundamental problems, they just prov…
It will make criticism outdated with regards to “you can’t do X” when you actually can do X. Your argument still doesn’t refute that that Java’s GC’s are leagues ahead of Go’s. If your argument is that optional syntax is bad, sure, we can do that, but it has nothing to do with GC performance.
Go's GC is nowhere near as complex, and yet it performs much better, because Go decided not to shoot itself in the foot.
Earlier quoted context omitted.
It will make criticism outdated with regards to “you can’t do X” when you actually can do X. Your argument still doesn’t refute that that Java’s GC’s are leagues ahead of Go’s. If your argument is that optional syntax is bad, sure, we can do that, but it has nothing to do with GC performance.
My criticism was not "you can't do this" - my criticism was that Java requires an overengineered GC to compensate for its fundamental language flaws that make optimization all but impossible. Go's GC is nowhere near as complex, and yet it performs much better, because Go decided not to shoot itself in the foot .
Except this criticism will be outdated. (but then you moved the goal post to syntax).
> Go's GC is nowhere near as complex, and yet it performs much better
Benchmarks prove otherwise.
Earlier quoted context omitted.
My criticism was not "you can't do this" - my criticism was that Java requires an overengineered GC to compensate for its fundamental language flaws that make optimization all but impossible. Go's GC is nowhere near as complex, and yet it performs much better, because Go decided not to shoot itself in the foot .
> my criticism was that Java requires an overengineered GC to compensate for its fundamental language flaws that make optimization all but impossible. Except this criticism will be outdated. (but then you moved the goal post to syntax). > Go's GC is nowhere near as complex, and yet it performs much better Benchmarks prove otherwise.
> Benchmarks prove otherwise
Well, good luck running the benchmarks on your production servers.
Honestly the more I see this the less I like Golang. Generics was the worst thing ever added to the language. We're making it easier for library builders and harder for ordinary code to be written.
Is there a categorical division between “library builders” and “ordinary code”? That’s not one I’ve heard before. (I’m aware of the difference between application and library code, but every large codebase I’ve ever worked in is a mixture of both.)
App builders just want to build stuff and make it work and move on to the next app. Nothing wrong with that but a different mindset and approach.
Earlier quoted context omitted.
The beauty of go is YAGNI. Language design makes it much harder for people so do stupid and cute things. During my design process if I start realizing that I’m missing maps, More expressive Types, Or more complex polymorphism. I ask myself if I really need those things. If I really do. I move off of go. That’s the beauty of the language. Go does not need more complicated language features because it’s can handle the…
Ok, and what if you realize you want these things a million lines in? Do you still move off of Go? Generic programming isn’t some fancy research language feature like dependent types. It’s just a bare minimum feature in any modern typed language. It’s perplexing that after C# and Java both notably shipped without generics initially then added them later that they decided to ship Go without generics.. only to end up a…
I had a team convinced that a particular subsystem was a mess and that they needed a stronger type system to build it properly because Go would just lead to hacks. They built a better one in Rust, deployed it, and moved traffic over.
Ditto, to some extent, if you're building desktop applications. Many large desktop applications already have multiple components or processes under the hood, and if you're at millions of lines, introducing that complexity may be worth it.
However, not all programs fit the above category. Sometimes you really do need a single lightweight binary and it needs to do a lot of stuff. But I think it's relatively uncommon to need one single binary that is simultaneously very large, architecturally diverse, and unable to delegate substantial complexity to other processes or services.
I see this most in the Kubernetes world, where something that starts as a simple binary gradually increases in scope and complexity. I've seen vendors struggle to keep up and start playing whack-a-mole with that complexity, but generally Go still scales surprisingly well here. Outside of K8s, there are also domains where you may strongly prefer a single-process or single-binary application, such as edge computing or developer tools.
Luckily, products where Go excels in these spaces also tend to have a natural upper bound on their domain complexity, because the operating model is generally about doing one or a few things well.
If Go's type system actually starts fighting you rather than merely being an inconvenience, then yeah, I would seriously look into moving off Go.
If you're working in a space that doesn't fit any of the above, I'd genuinely be interested in hearing about what you're building.