楼主的意思是，定义一个命名的函数类型，然后给这个类型增加方法，从而实现某个接口

例如

type Foo interface { Foo() }

type Bar func()

func (b Bar) Foo() {}

上面的代码，定义了一个名为 Bar，底层类型为 func() 的类型，这就是标题所说的“函数类型”

这个 Bar 类型还定义了一个 Foo 方法，从而实现 Foo 接口，就是标题所说“使用函数类型实现接口”

大部分静态语言都做不到给任意的类型命名，更不用说给任意类型增加方法

Haskell 是可以的，其他不清楚了

@Jirajine rust 不能解决空指针的问题，解一个空指针，和对 None 用 unwrap 是同样性质的事情。既然你认为 unwrap 不是语言的问题，怎么到 go 里解空指针，就成了语言的问题？另外，go 里空指针一样可以调用方法，只要没有解指针的操作，那就是没问题。

我不想和你谈 checked exception，别的地方已经有很多讨论，也远远说不上“毫无疑问”： https://www.zhihu.com/question/60240474
王垠很多观点都是错的。

@Jirajine 你在说啥？以 io.Reader 为例，返回类型是 (int, error)，哪来什么 null pointer ？
就算返回的是指针，且函数有问题，那后面如果遇到解指针，那就会直接 panic，表明程序需要改，是不需要写代码做检查的。
rust 你以为就没有问题？你看看多少人直接用 unwrap 吧，编译器可不会禁止你用。

如果你认为需要一遍又一遍复制，那你不会写成函数吗？这么简单的减少代码的技巧都不会吗？

说了半天你都没明白，union type 没法保证什么吗？
明明 rust 返回的 Ok(val)，就分成 val = 0 和 val > 0 两种情况。既然抬出 union type，怎么不定义一个类型，分开这两种情况？ Ok(val) 分成 Ok(n) 和 Zero，这样编译器才知道你必须处理返回 0 的情况。问题就是，rust 不是这么设计的。明明就是需要约定俗成检查 0，明明就是约定俗成需要检查 Interrupted 。比 go 优雅在哪里？我看不到。
你不处理 Ok(0)，编译器报错吗？你不处理 Interrupted，编译器报错吗？

go 里你不需要知道返回哪些 error，你只需要知道你能处理哪些 error，把你能处理的处理掉，不能处理掉的就直接返回，就行了。java 的 checked execption 不知道多少人批评，有什么好学的？

例如一个函数，调用另一个函数，且知道可以处理 ErrFoo 和 ErrBar 类错误，其他不管，是这样写的
err := fn()
if e := ErrFoo{}; as(err, &e); {
// 处理 ErrFoo 类错误
} else if e := ErrBar{}; as(err, &e); {
// 处理 ErrBar 类错误
} else {
// 不知道怎么处理，直接返回
return err
}

处处都想要处理任何错误，本身就是个伪需求。

@Nugine0 一个函数可以返回多个值，你是缺乏这种思维。
你缺乏的思维，就是不正常的思维？
42, io.EOF 的意思是，读了 42 字节，并且已经到达字节流的末尾，不用再读，很难理解吗？
换成单返回值，就需要两次调用，一次返回 42，一次返回 0 。我前面已经说过，go 这种设计可以节省一次调用。
“要么成功，要么失败”，显然是错的，rust 的成功，也包含两种成功，一种表示 EOF，一种表示读了一些。rust 的失败，也不止一种失败，而且 Interrupted 是一种特殊的失败，它并不是真的失败，只是暂时的失败。
io 本来就有固有的复杂度，不要以为抬出 union type 就是银弹，明明就不是。
我不是说 rust 的设计有问题，rust 的设计反映了 io 本身的复杂。有问题的是你们这些人，无视事实，非要用不用标准，褒扬一个贬低另一个。

@Nugine0 能不能不要双标？你不会看前面有人给出的 rust 代码和我给出的 go 代码？
rust 的 match 有四个 case，go 的 if 有三个。你要是说 go 这种设计反人类，那 rust 同样也反人类。
正常函数？你自己不适应就叫不正常？
要么成功要么失败才正常，那 Ok(0), Ok(n), Err(ErrorKind: Interrupted), Err(e)，四种情况，符合你不反人类的标准吗？没有心智负担是吧？
说好的 union type 呢？怎么还一个套一个的？怎么不用同一个 union type 表达所有情况？
能不能不要双重标准？

lint ？前面有人说了是语言机制，到你这里倒成了需要 linter 来做了？
你要是认为 linter 也算是机制的一部分，那还有什么好谈论的？ go 也有一堆 linter，前面说的什么忘记检查等等，全都可以提示。

明明就是狭隘偏执，非要说得自己代表全人类，和自己熟悉的设计不同，就是反人类了，好大的脸！

@natashahollyz 资本主义国家再死十倍二十倍，也比不上大饥荒死的几千万

水电偏蓝，核电偏绿，火电偏红，唯有风电没有色差

你也太小看古人了吧，几千年前就有牙医了，拔个牙齿都不会，连麻醉都有了

@12101111 posix 有没有，关 go 的 io.Reader 什么事？ go 支持一堆 non-posix 的平台。而且实现了 io.Reader 的类型，又不限于系统 io 。它是个 byte stream 接口，和 posix io 毫无关系。这个设计允许少一次 Read 调用，难道和 posix 不同，就叫有问题？

没错啊，你的 match 里有 _ ，然后后面新增了其他 kind，编译器不会报错，你就不知道新增了一个 kind，你就不知道需要特别处理这个新增的 kind 。前面有人不是说 rust 会提示你处理所有情况吗？我就明确说了，不会。你只能用兜底的分支去处理，你不看文档，你就不知道多了。

read_to_end? 你内存只有 32G，要你处理一个 128G 的文件，你也用 read_to_end?

看看 tokio 从 go 的运行时学来多少东西吧，rust 只不过把运行时的实现扔出去了而已，你用了 async，你就撇不开 async executor，这就是和 go 类似的运行时，也离不开 M:N 式的调度器。

@Jirajine 都说了 io::ErrorKind 标记了 #[non_exhaustive]，编译器并不会检查。rust 也不能保证你处理了每一种情况。

go 这样写：
for {
n, err := r.Read(buf)
if n > 0 {
//handle data
}
if is(err, io.EOF) {
break
}
if err != nil {
// handle error
}
}

不是比你那样更简洁？

@Jirajine Read::read 文档里还有一个约定：An error of the ErrorKind::Interrupted kind is non-fatal and the read operation should be retried if there is nothing else to do.
按照你的标准，这算不算糟糕？你要检查有没有错，如果有错，是不是 Interrupted，要不要重试，还要检查有没有读完，你真的可以随时用 ? 这个语法糖吗？
文档里的这个约定，是用语言机制保证的，还是仅仅由文档来约定的？不看文档，你知道要特别处理 Interrupted 吗？

@Jirajine 难道 rust 可以保证你检查了返回值是 0 ？ rust 只是多了?这个语法糖而已，难道就不是检查错误且要检查返回值是 0 ？
另外，我看你也不怎么熟悉 rust，io::ErrorKind 明明是标记为 non_exhaustive，文档里也明确写了 This list is intended to grow over time and it is not recommended to exhaustively match against it.
你说的是错的。

@12101111 我讨论的是 go 标准库定义的 io.Reader 接口，你拿 posix read 的文档来说个屁啊，根本就是两回事，看到都叫 EOF 就以为是一回事吗？不懂能不能别插嘴？
io.Reader 文档： https://pkg.go.dev/io#Reader
When Read encounters an error or end-of-file condition after successfully reading n > 0 bytes, it returns the number of bytes read. It may return the (non-nil) error from the same call or return the error (and n == 0) from a subsequent call.
定义得清清楚楚。
真的，不懂就闭嘴。王垠都还学习过一下，称得上半桶水，你是根本不懂，生搬硬套。