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.

https://github.com/golang/go/issues/32245 and more. But it looks this is not in the recent todo list of Go core team.

Official fieldalignment in short erases all comments, due to AST shortcomings when it comes to handling comments. Structslop uses DST (decorated AST) to workaround this problem and has somewhat slightly different algorithm of generated indexes to sort structs.

Hello Filippo, thanks for the update.In 1.20 planning you mentioned the proposal to expose a session identifier. Do you still plan to work on this feature?I have some sustainability issues with SFTPGo but I can try sponsoring something for this addition. However I'm pretty sure I won't be able to cover the full cost of development and maintenance so I understand if you have no interest in working on it. Thank you

For now, compiler doesn't do any layout optimizations/realignments, just struct padding.

In case you are wondering why DST and not AST, in general sense AST does not associate comments to nodes, but it holds fixed offsets. Original fieldalignment tool just erases all struct/field/floating comments due to this issue and while there is a CL with a possible fix, it's still a work in progress as of this time.

OP here,

How are you doing caching without a mod time?

https://github.com/golang/go/issues/44854

Are you re-naming or hashing for cache clearing?

The wanted to fix a bug in current implementation where you can create instances of private types using type inference, but it breaks aliases, so until then it's a no go.

With extended backwards compatibility and extended forwards compatibility accepted it doesn't matter that much. If your go.mod says go 1.20 it will always be subject to 1.20 semantics and syntax, no matter which version you chose to compile (as long as it's not terribly far).

Yes.

When you're in a "tight loop" (e.g. a matrix multiplication, which is basically 3 nested loops that only load data, do math, write data), Java's virtual threads just won't yield. So if you write your app in the "wrong" way, you lose concurrency.

There's a lot of discussion about this from the Go side. The original issue was this one: runtime: tight loops should be preemptible https://github.com/golang/go/issues/10958

> it's possible to write a tight loop (e.g., a numerical kernel or a spin on an atomic) with no calls or allocation that arbitrarily delays preemption. This can result in arbitrarily long pause times as the GC waits for all goroutines to stop.

The proposed (and ultimately accepted solution) is described here: https://github.com/golang/go/issues/24543

> has put significant effort into prototyping cooperative preemption points in loops, which is one way to solve this problem. However, even sophisticated approaches to this led to unacceptable slow-downs in tight loops (where slow-downs are generally least acceptable).

> I propose that the Go implementation switch to non-cooperative preemption using stack and register maps at (essentially) every instruction. This would allow goroutines to be preempted without explicit