Hacker News Reader

Comment by yannis | Hacker News Reader

Nice example of using "gob" to create RPC services. But why call it a "framework"?

I'd argue you don't learn much about RPC from this example code with gob handling the less straightforward parts. Going over what gob is doing would be a good addition.

For those curious as I am:

https://golang.org/pkg/encoding/gob/

Gob is apparently out of the box with Go.

I'm still learning through Go, there's so much available OOTB that I love about Go. I wish other languages would take Go's Standard Library as a good example of things to include with a language. I can do web applications entirely with Go's standard libraries. Course then you gotta worry about storing data in some database, but those libraries are usually done by Database vendors or the language community.

I don’t think binary serialisation counts as a good thing to include in the standard library. Unless Golang found a way to do it securely unlike other languages, which typically see binary serialisation as one of their larger mistakes.

It is safe to use using the rpc package. See Rob Pike's https://blog.golang.org/gobs-of-data for motivation.

Sort of. Gob requires registering concrete types you might use in interfaces, so I can't encode a type you haven't decided to whitelist. But the registration list is global in the library, so this doesn't work for access control (if your quorum leader can send it, your untrusted clients can also).

Lack of interop with other languages is still a bad idea (the lesson of Java RMI), and I thought Google agreed. Having all the C++ and Java and Python services speaking Stubby was one of the most futuristic experiences there.

Type creation in Go doesn't lead to code execution.

If you are speaking about Java, the only mistake they usually talk about is how the serialization algorithm and the API implementation, there are no regrets about the binary support.

And as for .NET, Python I never saw any reference about such regrets, while ISO C++ is still discussing papers for some kind of future support via static reflection.

I was thinking Java and .NET yes.

Here’s a discussion for .NET core not adding support for security reasons (eventually overruled for backwards compatibility reasons unfortunately). https://github.com/dotnet/corefx/issues/6564#issuecomment-21...

Java: https://www.bleepingcomputer.com/news/security/oracle-plans-...

On the context of .NET, not only backwards compatibility, performance is also a big reason, text serialization sucks in that regard.

Also the official path forward for WCF is gRPC, which also supports binary serialization.

As per Java, Brian Goetz has spoken multiple times about it, but the issue was mainly due to how the whole thing is designed, not necessarily due to using binary formats.

Reply on news.ycombinator.com