4 ms·

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

• tyingq 7y ago
  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.
  • giancarlostoro 7y ago
    For those curious as I am: https://golang.org/pkg/encoding/gob/ 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.
    • tybit 7y ago
      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.
      • yannis 7y ago
        It is safe to use using the rpc package. See Rob Pike's https://blog.golang.org/gobs-of-data https://blog.golang.org/gobs-of-data for motivation.
      • erik_seaberg 7y ago
        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.
      • wbl 7y ago
        Type creation in Go doesn't lead to code execution.
      • pjmlp 7y ago
        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.
        • tybit 7y ago
          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-219579151 https://github.com/dotnet/corefx/issues/6564#issuecomment-21... Java: https://www.bleepingcomputer.com/news/security/oracle-plans-to-drop-java-serialization-support-the-source-of-most-security-bugs/ https://www.bleepingcomputer.com/news/security/oracle-plans-...
          • pjmlp 7y ago
            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.