go-iterator VS go

I already played around a bit wit the beta a while back and made an iterator library to get to know this new language. It's here for anyone interested: https://github.com/polyfloyd/go-iterator

Regarding call chaining, it is still possible to chain things with operations that return different types, but they have to be done with functions instead of methods, so the result is still the same, just it's a little less readable. There is a generic iterator implementation by polyfloyd that doesn't support method chaining, but imo being able to chain iterators is one of their biggest strengths, since implementing lazy evaluation manually for a single operation isn't that difficult, its when you need to perform multiple kinds of manipulations that it gets messy.

Go is an open-source, statically typed, compiled language designed at Google for simplicity, reliability, and efficiency. It ships with a rich standard library, first-class concurrency primitives (goroutines and channels), and produces single, statically-linked binaries — making it an excellent fit for microservices and containerised workloads.

TBH I don't have anything more to add that hasn't already been discussed here and in previous threads: https://github.com/golang/go/issues/77273

It's probably polarizing and I honestly don't know why I felt the need to rant about it. /shrug

I don't think that's an ongoing debate looks to me that it ended in 2019 https://github.com/golang/go/issues/31440#issuecomment-53724...

update the steps to remove the use of tokio, and include porting the scheduler and other missing parts from the go repo: https://github.com/golang/go

Like IPv6 addresses, UUIDs, the list goes on. Does it mean anything that Go themselves had to invent a custom uint128 type in the standard library because they didn't want to add it to the language? There's a very long list of instances of them stonewalling it here: https://github.com/golang/go/issues/9455

If verbosity is a main stickler, this is coming to golang 1.28 which will cut down on verbosity drastically:

https://github.com/golang/go/issues/12854#issue-110104883

Unlike Go where the language definition itself via its compiler strictly enforces the inclusion of modules (i.e., include exactly what you use, no more, no less), neither the C nor C++ language definitions have an equivalent enforcement. This can lead to two problems:

d

And later I put it in https://pkg.go.dev/github.com/golang/groupcache/singleflight (groupcache was written for dl.google.com)

And a private copy in Go's net package in Jun 2013: https://github.com/golang/go/commit/61d3b2db6292581fc07a3767...

It later moved to golang.org/x/net, and later to the Go standard library (well, internal: https://pkg.go.dev/internal/singleflight)

We now even have a copy with generics in Tailscale's tree at https://pkg.go.dev/tailscale.com/util/singleflight

So many variants of that code :)

golang – The Go language and compiler.