On Friday, February 26, 2021 at 5:50:44 PM UTC+2 Ian Lance Taylor wrote:
> > OK, but the reflect package generally does not allocate, so what is > the advantage of reflect2? Are there benchmarks showing where > reflect2 is significantly faster? The problem is in the fact that benchmarking of json-iterator is itself a package specific one. This is not like if we could take 10-15 packages, which use reflect package, to benchmark those. And we could each of the end-user Go projects, to make it work with reflect2 - and run the same benchmark. Then we could patch again, to target go-reflect. Then we could do benchmarking again. > > > (I'll note that while this may not be a good idea for the overall > ecosystem, I expect that it is possible to port reflect2 to support > gccgo/GoLLVM.) In that case it would be critical to resolve these issues: https://github.com/modern-go/reflect2/issues/16 . Should those methods and types be referenced? perhaps something else should be used? Or it should - but we would have to implement the missing ones? btw this is what never being answered, during all the previous discussions. It might make sense to really work on various reflections APIs - to learn why it is typically grow into a situation when alternatives are written. Perhaps it makes sense to react on various issues and demands, of libgo, earlier then the whole Go package (for reflection, in this case) would be formed? At least it would be clear that is not reasonable to spend time on designing/implementing an alternative, compared to patching libgo's package. Also is a "corner edge" case, with json-iterator - it would give some disadvantages, in case of other end-user Go package. And that is what authors of such "alternative" do not want to deal with - so reflect2 is, unsurprisingly, unmaintained even by the original author. > > > Ian > > > > On Fri, Feb 26, 2021 at 10:00 AM Ian Lance Taylor <ia...@golang.org> > wrote: > >> > >> On Fri, Feb 26, 2021 at 6:11 AM Yan Titarenko > >> <local.tou...@gmail.com> wrote: > >> > > >> > CC'ing to committers. > >> > > >> > Ian, > >> > please provide some advise. > >> > >> I'm sorry, I don't have anything useful to add beyond what I've already > said. > >> > >> I don't know why people are using the reflect2 package. The package > >> does not support gccgo/GoLLVM. The first step is to understand why > >> people use reflect2, and whether we can improve the standard reflect > >> package to address whatever problems led to the creation of reflect2. > >> > >> Ian > >> > >> > >> > On Wed, Feb 24, 2021 at 2:00 PM Yan Titarenko <local.tou...@gmail.com> > wrote: > >> >> > >> >> Hi. > >> >> > >> >> Since there where no comments on > https://github.com/json-iterator/go/issues/501 - I decided that an open > discussion (not necessarily on behalf of this project - there could be > other projects/use cases, which could a cause for contributions, into the > reflection library). > >> >> > >> >> I tried to test with Golang 1.15.8. I tried an old version of > llvm-goc/gollvm - but can re-check, using the latest version of gollvm. > >> >> Also hence that one of the checks was done on x86_64 Windows 10. > >> >> > >> >> It is not clear what kind of patch (and in favor of which > engineering targets) would be required, yet - so we are not at the point > where we could excavate OS/arch dependent issues. > >> >> > >> >> I see a lot of errors like > >> >> > >> >> ./any.go:259:15: undefined: "github.com/goccy/go-reflect".TypeOfPtr > >> >> ./reflect_array.go:36:15: undefined: > >> >> "github.com/goccy/go-reflect".UnsafeArrayType > > >> >> . > >> >> I tried to do two things: I tried to revert back from reflect2 to > libgo's reflect - and I tried to use goccy's go-reflect, instead of > reflect2. > >> >> It is interesting that both attempts brought similar errors - but > they also brought some unique errors. > >> >> But nothing that would bring specific practical wage, just case of > that. > >> >> > >> >> Yan > >> >> > >> >> -- > >> >> You received this message because you are subscribed to the Google > Groups "golang-nuts" group. > >> >> To unsubscribe from this group and stop receiving emails from it, > send an email to golang-nuts...@googlegroups.com. > >> >> To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/ab44891f-eca6-47cb-a4b1-c6292d6015a7n%40googlegroups.com. > > > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups "golang-nuts" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an email to golang-nuts...@googlegroups.com. > >> To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAKOQZ8zbyemhzCd_1cEAkrc5FAwcdDOyo%3DxSBNafcA_mTpdYnQ%40mail.gmail.com. > > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/791e254c-a2a4-4ef4-b1c6-3e34e00a2a16n%40googlegroups.com.
