大佬们，为什么我感觉 go 文档要比前端文档难懂

你看的部分是接口和结构体定义。可以找一下有无 example 或测试用例，比如 go-git 在问当中就有 https://pkg.go.dev/github.com/go-git/go-git/v5#readme-examples

一般不看这玩意，直接看包的文档。标准库的直接在 IDE 看。

不是 go 文档要比前端文档难懂，是后端比前端文档难懂

go 作为函数式编程、低语法糖，已经是后端里文档最容易写最容易看懂的语言之一了

@lrvy 但是 go git 提供的两个 example 属于 get starter 级别的，我想找那种读取特定仓库特定时间段 commit 的 func ，好像还是得去结构体定义里找

你给出的三种文档都不同项目……

你找一个小学生写的英语文章，再找一个著名作家写的汉语文章，然后问为什么汉语写的文章特别优秀？

文档都是人写的，和写文章一模一样，水平高就写得好，反而与“语言”的关系不大。

不要怀疑，大部分 go 的文档（包括官方文档）都写得依托狗屎，对于第一次看相关功能或者想要深入了解的人来说没多大参考价值。写得晦涩难懂七零八散，最要命的是功能都写不全。很多关键功能文档里都不会写的，你只能去看别人代码怎么用或特意去搜才知道

用了多年 Go ，我的建议是你要快速了解一个包或者内置包怎么用，直接谷歌关键字搜别人写的文章或问 ai 就行

我觉得主要是因为 go 以前没有统一文档，go docs 这么久了，也没有重视开发（ go.dev 才几年），也没有要求大家都要写。

各个 go 项目基本都是自己的文档，前端你要对比的话应该拿 https://www.npmjs.com/package/three 这种和 go 这个做对比更合适，其实都是需要另外找文档。

而 vue react 这些更多是独立的一个文档了，所以体验肯定比较好的。

我一般都是先到 git 主库上找文档的，例如你给到的项目 https://github.com/go-git/go-git/blob/master/_examples/README.md

首先 go-git 本身就不是按 Go 语言思维从零开始做的项目，它要模仿 git ，把原本用 C 语言写的项目翻译为 Go ，这种“翻译”类型的项目多数情况下都要求你原本就对 C 语言版的 git 比较熟悉。

作为框架对比，可以看看 https://goframe.org/ ，虽然写的不一定很好，但起码够用了。

其实就是文档烂，三言两语带过，有些文档还不如函数方法名字长，作用全靠看名字猜，能懂就怪了。

go 很多文档根本没法看，很多根本就没有文档，全靠 example 、test 、自己全都试一遍。

把文档给 AI ，让 AI 帮你就行了

前端面向过程编程是这样的，你想做什么文档就教你怎么做。
后端面向对象这种思维就是废话多，就像是你想吃饭非得教你读菜单起锅烧炉结果菜单上的字不认识。

这不是 GO 的问题是项目的问题，前端项目之所以文档好一些还是因为风格和习惯的问题

好家伙, 什么叫"比前端还难懂"
前端在后端眼里就是个高级 UI

难道不都是看 *_test.go 和 examples 吗， 不要太指望开源项目的文档。

react 的是人写的.
go 的这个文档是通过代码里的注释直接生成的, 我从来不看这玩意.

我入行是写 C#的，我甚至不知道写代码要看文档，想知道这个函数干啥的，IDE 点一下跳到源码看看结构看看注释就懂了
后面写 node js ，才发现原来这种语言离开了互联网就一个字也写不动，没文档根本不知道有什么函数和方法
现在写 go ，找回了一大半 C#的感觉吧，基本上不太需要看网页文档，跳源码看注释就行

go 这圈子里文档相关做的就是不好的。基于注释生成文档这个路线走歪了，很多包的作者选择不做友好的文档，真就用注释当文档。

@Vegetable 基于注释生成文档是很正常的路线吧？很多语言都有这个做法。

我觉得 Rust 标准库的文档写的非常好，说明清晰，几乎都有示例。光看 LSP 的 Hover 提示就知道怎么用了。