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

在我看来，是因为前端的领域（ UI ）本来就比较难快速上手，轮子多，不同轮子的造法不同，用法（思维）又不一样，加上各家有各家的细节，肯定要写多一些才让人能懂。另外前端竞争大，文档写好一些，争取多一些用户。

后端的从业者，基础可以的话，尤其是本科科班出生，换一门语言上手的曲线还是不陡的，除非换了一种编程范式，但这不是文档能解决的事。

go doc 的默认文档就是一坨屎, 根本就不是文档.

@lscho #3 我觉得同时代出的 rust 文档好多了，跟前端后端没关系，go 的文档就是很烂很简陋

感觉你期待的就教学文档。 适合全新入门。
go 列出来的是 “关键元素” 文档。 适合有一定了解。

适合的场景不一样吧。

Go 的文档还算可以了，算比较简单易懂的了

怎么前端都在卷 go ，俺也是在转 go 的路上哈哈

后端编程语言，谁看文档。。要么看源码要么不看。react 文档真是业界楷模，是真怕你学不会

Go.dev 是代码文档，不是使用文档，另外两个是你给的是使用文档，不是一个维度的文档

所以使用 go 包时，找对应的包自己的使用文档或问 ai 0.0

#3 go 是函数式编程？我人麻了

这是 transmissionrpc 的文档对比

官方: https://github.com/transmission/transmission/blob/main/docs/rpc-spec.md
go: https://pkg.go.dev/github.com/hekmon/transmissionrpc/v3
python: https://transmission-rpc.readthedocs.io/en/stable/

感觉都不如问 ai, 大部分给出的都像是代码注释自动生成的, 前端 ui 文档应该都是有手工维护的.

@jqtmviyu 这个 Python 的文档也是从代码注释生成的，只不过 sphinx 比 godoc 的功能多多了，所以生成的文档效果好很多…

@lscho 我第一次听说一个没有 map/filter/reduce/fold,没有 immutable,没有 sum type,没有 pattern matching,不支持 tail recursion optimization 的语言能叫函数式的

因为你发的 go 文档是自动生成的，其他俩是手写的。

要不你去看看 pixijs 的文档，还有 fabricjs 。全靠自己尝试。

Go 的文档风格是极简风格的。它舍弃了比如 Java 语言的 javadoc ，使用带有特定语法格式的文本表达的格式化文档，使文档更容易编写。一般来说，以 Kotlin 举例，kdoc 需要这么写
```java
/**
* Title
*
* @param[foo] description for foo
* @param[bar] desc for bar
* @return blahblah...
*/

```
而 Go 则倾向于使用人类语言来描述：
FunctionName returns blahblah. The parameter foo is blah, the bar is ....

显而易见，Go 这种文档是更容易编写的。你不能只看到它阅读困难，它好写，人们可能就爱写，比 kdoc 写一堆 @param 然后描述空着似乎强了那么一些呢。

学 go 之前先学学 c 语言会比较好点