10 ms·

It looks like this has a Marshal and Unmarshal function just like it's core library counterpart. So I'd guess you might be able to use this as a drop in replac

It looks like this has a Marshal and Unmarshal function just like it's core library counterpart. So I'd guess you might be able to use this as a drop in replacement. However I'm yet to prove that theory.

tptacek 8y ago
encoding/json's Marshal and Unmarshall uses reflect and struct tags. This library doesn't: you have to define a function to make your struct satisfy an interface.
- phamilton 8y ago
  Macros would solve this problem nicely if they we're available. I sure wish first class macros were on the golang roadmap.
  - tptacek 8y ago
    If you want to code in a language with macros, pick a language with macros. They tend not to look like Go (or C, or C++), because part of what makes macros effective is that coding in those languages is pretty close to working with their ASTs. Writing a Lisp-like macro for Go sounds like it would actually be more annoying than simply writing a codegen for it.
    - bpicolo 8y ago
      I don't think there's anything precluding Go from making it possible, other than the maintainers' desire to not have macros. Rust gives you the power here, and as a result has some tremendous serialization libs: https://github.com/serde-rs/serde https://github.com/serde-rs/serde Macros don't need to be as simple to use as in lisps to be useful - the rare library like serialization that can really benefit from them can be worth the language feature
      - tptacek 8y ago
        Rust is a good counterexample, yep.
    - phamilton 8y ago
      The end result with macros is far more seamless than with codegen, the point being that a consumer of the library doesn't even need to know about the macros. The code just works like the reflection approach, but without the runtime penalty. Codegen on the other hand makes an implementation detail a maintenance cost for the user of the library.
      - stcredzero 8y ago
        The end result with macros is far more seamless than with codegen, the point being that a consumer of the library doesn't even need to know about the macros. A double edged sword, that! Sometimes the end result with things like macros, is that it so seamless, that there is precious little to figure out what went wrong. Often, if your nifty new facility seems magic, its bugs are going to seem doubly magic. Not too long ago, I had to debug an exception for which no source code existed. It only existed as the confluence of 3 C++ templates. Codegen on the other hand makes an implementation detail a maintenance cost for the user of the library. I've heard veteran programmers say that there should be a separation of labor when it comes to libraries. Only certain people make good library writers, in the same way that only certain people make excellent musical accompanists. To be an excellent accompanist, the accompanist should have some sense of what it's like to be the lead. (So should themselves be able to take the lead.) The accompanist should have the perspective to not let his ego get in the way. The accompanist should be giving the lead what she wants, but modulated through their own expertise and sense of taste. (As opposed to mindlessly always giving everything asked for.) If there is a separation of responsibility, why would codegen be such a burden? If the library has to change so often, perhaps the responsibilities aren't distributed optimally?
        pcwalton 8y ago
        Macros usually make debugging easier than code generators do. That's because quasiquote and similar operators let you debug code, not code that generates code. I'm the first to admit that macros have downsides compared to not having them in the language, but ease of debugging generated code isn't one of those downsides.
    - pcwalton 8y ago
      S-expressions aren't actually necessary for macros to work. You just have to be able to separate "READ" from "EXPAND" (to use Lisp-ish terminology). I believe, but am not sure, that this is possible for Go. (Of course, whether this is a good idea is another thing entirely. I probably wouldn't have included macros if I had been put in charge of Go 1.0, given Go's goals of simplicity.) More on this from my former colleague Dave Herman, who did his dissertation on macros: http://calculist.org/blog/2012/04/17/homoiconicity-isnt-the-point/ http://calculist.org/blog/2012/04/17/homoiconicity-isnt-the-...
    - vorg 8y ago
      An alternative to both Lisp-like macros and code generation is to trigger macros via annotations in the syntax, and for the macro to manipulate the AST directly using the "go/ast" package. Apache Groovy, which has the same curly-braces style syntax as Golang, does it like this.
- laumars 8y ago
  You don't have to use structs tags (nor even structs) to use encoding/json. In fact I often don't as a lot of my usage is with maps rather than structs. I did some testing with gojay and it did work as a drop in replacement for most of my usage. However the performance improvements I saw in my benchmarks were not nearly as favourable as those published in the projects git repository. I'm sure I could get better results if I played around with their APIs a little more rather than just using the mashallers but frankly the utility I'm using it in favours the flexibility of encoding/json a little more anyway, even if that does cost me a little in performance (and to be clear, it really wasn't much as I needed to iterate the execution of my utility a thousand times just to get any meaningful differences between the two libraries. So we're not talking real world usages). That said, if you're building high performance servers then I'm sure gojay would really stand out. On reflection (no pun intended), my requirements wasn't really the target use case for this package.
  - tptacek 8y ago
    That's fine, but this library isn't a drop-in replacement for encoding/json; to be that, it has to work for people who expect tagged structs to round-trip through it, which won't happen with this library.
    - deleted 8y ago
      [deleted]
    - deleted 8y ago
      [deleted]
    - laumars 8y ago
      That's fine but I never stated "drop in for all use cases". A point I made very clear in my second post. But for some use cases it can be. As I had explained already. The rest should be abundantly clear which use case would apply to anyone who's spent more than five minutes in Go (or any programming language that supports reflection) and had read the first like of the packages readme (ie that it doesn't use reflection). It's definitely worth remembering that one doesn't have to use structs and tags to write nor read JSON in Go before people start bitching about boiler plate code and lack of macros.

tptacek 8y ago

encoding/json's Marshal and Unmarshall uses reflect and struct tags. This library doesn't: you have to define a function to make your struct satisfy an interface.

phamilton 8y ago
Macros would solve this problem nicely if they we're available. I sure wish first class macros were on the golang roadmap.
- tptacek 8y ago
  If you want to code in a language with macros, pick a language with macros. They tend not to look like Go (or C, or C++), because part of what makes macros effective is that coding in those languages is pretty close to working with their ASTs. Writing a Lisp-like macro for Go sounds like it would actually be more annoying than simply writing a codegen for it.
  - bpicolo 8y ago
    I don't think there's anything precluding Go from making it possible, other than the maintainers' desire to not have macros. Rust gives you the power here, and as a result has some tremendous serialization libs: https://github.com/serde-rs/serde https://github.com/serde-rs/serde Macros don't need to be as simple to use as in lisps to be useful - the rare library like serialization that can really benefit from them can be worth the language feature
    - tptacek 8y ago
      Rust is a good counterexample, yep.
  - phamilton 8y ago
    The end result with macros is far more seamless than with codegen, the point being that a consumer of the library doesn't even need to know about the macros. The code just works like the reflection approach, but without the runtime penalty. Codegen on the other hand makes an implementation detail a maintenance cost for the user of the library.
    - stcredzero 8y ago
      The end result with macros is far more seamless than with codegen, the point being that a consumer of the library doesn't even need to know about the macros. A double edged sword, that! Sometimes the end result with things like macros, is that it so seamless, that there is precious little to figure out what went wrong. Often, if your nifty new facility seems magic, its bugs are going to seem doubly magic. Not too long ago, I had to debug an exception for which no source code existed. It only existed as the confluence of 3 C++ templates. Codegen on the other hand makes an implementation detail a maintenance cost for the user of the library. I've heard veteran programmers say that there should be a separation of labor when it comes to libraries. Only certain people make good library writers, in the same way that only certain people make excellent musical accompanists. To be an excellent accompanist, the accompanist should have some sense of what it's like to be the lead. (So should themselves be able to take the lead.) The accompanist should have the perspective to not let his ego get in the way. The accompanist should be giving the lead what she wants, but modulated through their own expertise and sense of taste. (As opposed to mindlessly always giving everything asked for.) If there is a separation of responsibility, why would codegen be such a burden? If the library has to change so often, perhaps the responsibilities aren't distributed optimally?
      - pcwalton 8y ago
        Macros usually make debugging easier than code generators do. That's because quasiquote and similar operators let you debug code, not code that generates code. I'm the first to admit that macros have downsides compared to not having them in the language, but ease of debugging generated code isn't one of those downsides.
  - pcwalton 8y ago
    S-expressions aren't actually necessary for macros to work. You just have to be able to separate "READ" from "EXPAND" (to use Lisp-ish terminology). I believe, but am not sure, that this is possible for Go. (Of course, whether this is a good idea is another thing entirely. I probably wouldn't have included macros if I had been put in charge of Go 1.0, given Go's goals of simplicity.) More on this from my former colleague Dave Herman, who did his dissertation on macros: http://calculist.org/blog/2012/04/17/homoiconicity-isnt-the-point/ http://calculist.org/blog/2012/04/17/homoiconicity-isnt-the-...
  - vorg 8y ago
    An alternative to both Lisp-like macros and code generation is to trigger macros via annotations in the syntax, and for the macro to manipulate the AST directly using the "go/ast" package. Apache Groovy, which has the same curly-braces style syntax as Golang, does it like this.
laumars 8y ago
You don't have to use structs tags (nor even structs) to use encoding/json. In fact I often don't as a lot of my usage is with maps rather than structs. I did some testing with gojay and it did work as a drop in replacement for most of my usage. However the performance improvements I saw in my benchmarks were not nearly as favourable as those published in the projects git repository. I'm sure I could get better results if I played around with their APIs a little more rather than just using the mashallers but frankly the utility I'm using it in favours the flexibility of encoding/json a little more anyway, even if that does cost me a little in performance (and to be clear, it really wasn't much as I needed to iterate the execution of my utility a thousand times just to get any meaningful differences between the two libraries. So we're not talking real world usages). That said, if you're building high performance servers then I'm sure gojay would really stand out. On reflection (no pun intended), my requirements wasn't really the target use case for this package.
- tptacek 8y ago
  That's fine, but this library isn't a drop-in replacement for encoding/json; to be that, it has to work for people who expect tagged structs to round-trip through it, which won't happen with this library.
  - deleted 8y ago
    [deleted]
  - deleted 8y ago
    [deleted]
  - laumars 8y ago
    That's fine but I never stated "drop in for all use cases". A point I made very clear in my second post. But for some use cases it can be. As I had explained already. The rest should be abundantly clear which use case would apply to anyone who's spent more than five minutes in Go (or any programming language that supports reflection) and had read the first like of the packages readme (ie that it doesn't use reflection). It's definitely worth remembering that one doesn't have to use structs and tags to write nor read JSON in Go before people start bitching about boiler plate code and lack of macros.