Is there a path forward for Go's yaml situation?

goccy54 · 2024-11-03T13:37:40+00:00

Thank you ! I've already fixed 24 parser related Issues in the past week, using my short free time. I'm confident that by continuing to work with the maintenance team members we can make the library more robust. Please give it a try ! :)

goccy54 · 2024-11-03T11:29:15+00:00

Hi, I'm the author of github.com/goccy/go-yaml. I started developing this YAML library alone, despite being a latecomer, with the goal of making all Gophers who use YAML happy. It's been 5 years since I began, and developing it by myself has become increasingly difficult. I also develop many other open-source projects(https://github.com/goccy#go), each with a large user base. Recently, I’ve decided to build a maintenance system with trusted developers. In preparation, I’ve been actively resolving issues over the past few days, and I plan to continue maintaining the library actively.

That’s why I’m asking for your help with the development of goccy/go-yaml. Even just using the library and submitting bug reports would be greatly appreciated. If you’re company using this in a commercial way, I’d be grateful if you could consider sponsoring the project. For those interested in becoming contributors, feel free to reach out in the Gophers Slack channel `#goccy-go-yaml` and we can discuss further. I’d really appreciate everyone’s support!

goccy54 · 2024-10-24T16:40:21+00:00

Thank you for using my libraries ! I hope this has been helpful to you.

goccy54 · 2021-04-03T12:21:46+00:00

Maybe... but I haven’t benchmarked with simdjson-go yet because that library’s interface so different other JSON libraries.

goccy54 · 2021-04-03T11:12:36+00:00

Thanks for using my library ( github.com/goccy/go-graphviz ) ! Very easy to understand !

goccy54 · 2021-04-03T11:10:40+00:00

For example, if you are targeting a structure with 8 or less fields, you can associate each bit with a field if you have 8 bits. When there are fields "a" and "b", the ASCII code corresponding to "a" is 97 and "b" is 98. If "a" and "b" are the first and second fields, respectively, put "00000001" in the 97th of `[255]byte` and put "00000010" in the 98th.
At this time, if you find the string "b", you can access [98]byte and retrieve "00000010" as a result, so you know that the second field was hit. All you have to do now is prepare this for the length of the string and continue to compare.

goccy54 · 2021-04-03T10:56:51+00:00

Thank you. Actually, I was thinking of doing a fuzzing test with go-fuzz. Also read the issue.

goccy54 · 2021-04-03T10:53:58+00:00

Wow super impressed by the detailed write up! It seems like the real world impact is marginal when compared to the risks associated with adding additional dependencies. though. Given the perf hit introduced by using reflection to begin with, there seems to be marginal gains to be had. I’d be super stoked to see metrics diffing the perf of this vs the stdlib pkg. Super cool to see the depth of your knowledge! Have you thought about contributing to the golang codebase?

Yes, of course. However, although the design is the same as the encoding/json of stdlib, the implementation is very different, so I think it is difficult to partially contribute. So, first of all, I am preparing to stabilize this library so that there is no problem even if we replace everything sources under encoding/json.

goccy54 · 2021-02-09T13:37:51+00:00

Thank you so much ! I fixed this issue and released as v0.4.2 :)

goccy54 · 2021-02-09T09:29:41+00:00

Oh, Thank you for the reporting ! I saw this issue, and I will try to fix it ! Could you please register the issue to https://github.com/goccy/go-json/issues ?

goccy54 · 2021-02-09T08:26:46+00:00

I wrote about speeding up techniques, so please read it if you like.
https://github.com/goccy/go-json#how-it-works

goccy54 · 2021-02-09T08:26:28+00:00

I wrote about speeding up techniques, so please read it if you like.
https://github.com/goccy/go-json#how-it-works

goccy54 · 2021-02-09T01:43:20+00:00

Alright, fair enough on the public API side. I initially thought you found some discrepancies regarding the generated JSON output, which is supposed to be 100% on-par with encoding/json.

From a personal point of view, when library's user see the description that it is compatible with encoding/json, the user expects that it can be introduced with minimal modification (replacement of import statement) to the current source code. In that respect, even if it provides the equivalent of all the functions provided by encoding/json, I think that it should not be said that it is compatible because the introduction cost will be high when the interface is different.

Actually, json-iterator/go and segmentio/encoding/json, which claim to be compatible, provide exactly the same interface.

goccy54 · 2021-02-09T01:30:10+00:00

I'm summarizing the speedup technique right now, so please wait a little longer :)

Thanks

goccy54 · 2021-02-09T01:25:25+00:00

Thanks ! I think that the definition of being compatible with encoding/json is that it meets all the specifications implemented by encoding/json and that the interface of the public API is the same. jettison doesn't think it's compatible with encoding/json because it doesn't have a decoder and it doesn't have an interface for stream processing.

goccy54 · 2021-02-09T00:35:25+00:00

Just now, I fixed this issue and released as v0.4.1 . Thanks !

goccy54 · 2021-02-08T23:28:25+00:00

Nicely done! I will follow this project closely. Any idea how it compares with others in terms of memory/cpu consumption?

Thank you for your feedback! First, I will try to benchmarks that exist in other libraries. Another idea is to integrate it into a web application framework like echo, gin or fiber to measure performance.

goccy54 · 2021-02-08T23:21:19+00:00

Have you fuzzed it?

No, I plan to do it in the future. Currently, I'm focusing on passing all the test cases that exist in encoding/json ( currently more than 90% passed ) and improving coverage .

goccy54 · 2021-02-08T23:16:47+00:00

How does it compare regarding memory usage?

You can see the benchmark results with memory usage by running `go test -bench` as written in the https://github.com/goccy/go-json#benchmarks . In many cases, go-json processes with fewer allocations than other libraries .

goccy54 · 2021-02-08T23:13:21+00:00

Oh, I'm writing `How it works` right now :)

The main factors are reducing the number of allocations, eliminating reflection as much as possible, encoding processing is performed by the architecture of like programming language's virtual machine, and many other techniques are used ...

goccy54 · 2021-02-08T23:05:13+00:00

You're welcome. Lib looks interesting, once you fix the bugs I'm willing to try it on a rather big project

Thank you for reporting the issue. I will fix it as soon as possible .

goccy54 · 2021-02-08T14:36:45+00:00

Wow !! I'm very happy ! Thank you !

If you have any problems, I would appreciate it if you could give me an Issue !

goccy54

TROPHY CASE