Thank you, rsc, for all your work. Development in Go has become much more enjoyable in these 12 years: race detector, standardized error wrapping, modules, generics, toolchain updates, and so on. And while there are still things to be desired (sum types, better enum/range types, immutability, and non-nilness in my personal wishlist), Go is still the most enjoyable ecosystem I've ever developed in.
Readit Newsainar-g commented on Russ Cox is stepping down as the Go tech lead groups.google.com/g/golan... · Posted by u/bojanz
ainar-g commented on C23 is cancelled due to missing the publication deadline iso.org/standard/82075.ht... · Posted by u/ainar-g
Source on the reasons, from the editor: https://pony.social/@thephd/112791335889843647.
> make requests even if you don't have the .proto around
Like this?
> grpcurl -d '{"id": 1234, "tags": ["foo","bar"]}' \
grpc.server.com:443 my.custom.server.Service/Method
If I recall correctly, ProtoBuf has a reflection layer, and it's probably using that.
Re. bad tooling. grpcurl[1] is irreplaceable when working with gRPC APIs. It allows you to make requests even if you don't have the .proto around.
ainar-g commented on How GCC and Clang handle statically known undefined behaviour diekmann.uk/blog/2024-06-... · Posted by u/todsacerdoti
> While the compiled programs stayed the same, we no longer get a warning (even with -Wall), even though both compilers can easily work out statically (e.g. via constant folding) that a division by zero occurs [4].
Are there any reasons why that is so? Do compilers not reuse the information they gather during compilation for diagnostics? Or is it a deliberate decision?
Sure, here you go:
https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(filename...
Ah, so extremely localized uses of pointers, got it, thanks.
>in Go pointers never point to values on the stack
This is only the case for pointers that the compiler can't prove not to escape:
>In the current compilers, if a variable has its address taken, that variable is a candidate for allocation on the heap. However, a basic escape analysis recognizes some cases when such variables will not live past the return from the function and can reside on the stack.
That could be true, but I've done a few optimizations of allocations in Go code, and I don't recall pointers to stack values ever being optimized (unless the entire branch is removed, of course). If anyone could provide an example of the code that does pointer operations yet doesn't cause allocations, I'd appreciate it!
Go newbie here. Can anybody elaborate on this piece of the docs?
""" You might be thinking that it would be more usual to have an ops.Add(ColorOp{Color: red}) method instead of using op.ColorOp{Color: red}.Add(ops). It’s like this so that the Add method doesn’t have to take an interface-typed argument, which would often require an allocation to call. This is a key aspect of Gio’s “zero allocation” design. """
Why would there be an allocation? Of what? How are we saving it?
Whenever you do:
v := interfaceType(concreteTypeValue)
dataPtr := &concreteTypeValue
typePtr := typeData[concreteType]()
v := interfaceData{
data: dataPtr,
typ: typePtr,
}
ainar-g commented on Demystifying the protobuf wire format kreya.app/blog/protocolbu... · Posted by u/CommonGuy
As a counterpoint to the horror stories, I've had a few relatively good experiences with protocol buffers (not gRPC). On one project, we had messages that needed to be used across multiple applications, on a microcontroller, on an SBC running Python, in an Android app, in a web service, and on web UI frontend. Being able to update a message definition in one place, and have it spit out updated code in half a dozen languages while allowing for incremental rollout to the various pieces was very handy.
Sure - it wasn't all guns and roses, but overall it rocked.
To be fair, if that's what you need ProtoBuf isn't the only option. Cap'n Proto[1], JSON Schema[2], or any other well supported message-definition language could probably achieve that as well, each with their own positives and negatives.