131–140 of 273 posts
Earlier quoted context omitted.
? nothing is wrong, it's just a different way to spell template void F(T p) { ... }
can i say T : SomeConstraint ?
template
void F(T p) { ... }
void F(SomeConstraint auto p) { ... }
I'm really mixed about this. As a developer I would love having generics in Go. I can think of a few places in my code I can greatly simplify if they were implemented now. However, as someone who reads other people's Go code, I'm not a huge fan. One of the greatest things about Go is that a developer can usually one-shot read and understand almost anybody's code because there's a simplicity "forcing-function" applied…
parametric polymorphism does not make code harder to read you know what's hard to read? hand-rolled for loops & select blocks combined to wrangle concurrency. the no1 benefit of parametric polymorphism in Go is going to be abstracting over concurrency
every language designer who does not understand c++ is doomed to reinvent it I mean, seriously, func F[T any](p T) { ... }
Earlier quoted context omitted.
What is wrong with that syntax?
? nothing is wrong, it's just a different way to spell template void F(T p) { ... }
Generics in Go are vastly different than templates in C++. They might be used for similar things, but whereas Go's generics actually build up on Go's structural typing, templates are ... something completely different again.
I mean; C++ templates are Turing complete. They are in the same ballpark as Scala's type machinery. And I say that with adoration.
Side tracking a bit: I wish there was a popular programming language like Go with rust-like package manager, Python style syntax and ability to hack, compilable, classic (classes, methods), and fast. Or I wish Go had classic OOP and raise Exception methods. Basically, I want fast statically typed python with better package management. Or other way to put it, I want Go with classic OOP and Exceptions.
- Python's OOP, stdlib, exceptions
- Go's fast compilation and binaries
- Rust's package manager (never used but I heard it's amazing)
- Java's third-party packages & tooling
- F#'s expressiveness, FP, type system (never used it, only read a few intro articles, but it looks very nice?)
I'm tyring to move on from Python but finding it difficult to decide what to learn next.
Earlier quoted context omitted.
If we're dealing in anecdata, mine is that "Go compiles fast!" is true right up until something in your dependency tree hauls in kubernetes repos, perhaps multiple times. Thanks the "first principles" design of go mod, that's becoming increasingly unavoidable. Kotlin does compile much slower than I would like, but at least I only haul in one version of libraries and 0% of it is generated code. Java is basically insta…
> Thanks the "first principles" design of go mod, that's becoming increasingly unavoidable. That's interesting, could you explain this more? Context: I used to use Go a lot, but mostly haven't since Go modules, and I'm curious to know the details of the problem and why it happens.
If your git repositories aren't tagged just so, then go mod throws its hands up and simply invents a whacky snapshot version. Because it can't itself properly determine "earlier version" from "later version" on that snapshot, you often wind up with multiple snapshots from the same repo, not infrequently transmitted through other dependencies.
This is just jolly good fun when it turns out that your dependencies are pulling in incompatible versions of things. Since the official Kubernetes policy for downstream consumers is "we don't care about downstream consumers", it happens more quickly than one would expect.
As much as I have hated playing whack-a-mole with Maven or Bundler, I hate even more playing whack-an-adamantium-and-invisible-with-xray-eyes-mole against go mod.
We have a very large Go codebase here at Stream and not having generics is just not really as big of an issue as you think it is. There are plenty of work arounds if you get used to not having generics in the language. The fast compile times of Go are amazing. I was doing some Kotlin a few weeks ago and the difference is crazy. Go: Install deps, compile everything done in 5s. Doing the same in Kotlin, laptop freezes,…
I remember thinking something similar about my Java 1.4 codebase back in the early 2000s. It's fine, right? What could I be missing? The answer is: A lot.
And then all that momentum, all the tools, the books, the conference presentations, the code ... all of it. Pop! It died. Because code generation sucks. It is the worst solution to any problem solvable by a type system.
Earlier quoted context omitted.
I remember thinking something similar about my Java 1.4 codebase back in the early 2000s. It's fine, right? What could I be missing? The answer is: A lot.
I miss Java 1.4. It was small and concise. Java 5 added so much that none knows all of it. Just look at the length of Java Generics FAQ. It's hilarious.
- read that from start to end exactly zero times,
- picked up generics in a day or two,
- struggled with advanced types twice, half a day each time
- struggled with type erasure twice, also about half a day each time.
Meanwhile generics often saves me a number of minutes pr hour and makes everything cleaner and easier to read.
I used Java before generics but once it arrived I never looked back and neither did anyone i know.
Two more levels of blogs down, the actual proposal.[1] Definition: // Print has a type parameter T and has a single (non-type) // parameter s which is a slice of that type parameter. func Print[T any](s []T) { ... } Call: Print[int]([]int{1, 2, 3}) Above, "any" is really just a synonym for "interface{}". You can have more restrictive type constraints on parameterized types by specifying other Go interfaces. This is v…
My understanding from the “Featherweight Go” paper https://arxiv.org/abs/2005.11710 is that generic types will not simply be a synonym for interface{} because the compiler will be able to monomorphize them - they do not require dynamic dispatch like interfaces.
Earlier quoted context omitted.
If we're dealing in anecdata, mine is that "Go compiles fast!" is true right up until something in your dependency tree hauls in kubernetes repos, perhaps multiple times. Thanks the "first principles" design of go mod, that's becoming increasingly unavoidable. Kotlin does compile much slower than I would like, but at least I only haul in one version of libraries and 0% of it is generated code. Java is basically insta…
I'm currently working on a project that depends on the k8s APIs and I haven't noticed ballooning compile times. I'm only pulling in k8s.io/api, k8s.io/apimachinery, and k8s.io/go-client though.