@ttimasdf

开源的系统确实可玩性高 而 linux 下最臃种的系统也都比 windows 轻量 你说的是易用性而不是可玩性 举例的 sophia script for windows... 这东西很普 而不是所有使用者都知道你说的这些东西 所以依然有门槛 而自动配置功能...你是真不知道工具怎么用？ 接触 linux 一段时间了还想不到怎么配置最强大方便？还是说你就是希望有人把汤匙放你嘴边？依照使用经验和你举例对比 windows 的东西还是一样... 大概没什么东西可以抄 缺乏想像力

这是应用层处理资料逻辑 目前来看读行方式才是好的处理方法

消秏资源又更多 websocket 配 ack 消息本身也是消秏资源更多

至于短连线你要做的事情就更多了 并且一样有丢包问题

tcp 本身的 ack 又不对应用层开放 然而 tcp 广范支援 所以...

你这样还会有万一 ack 消息没收到卡住怎么办 你有个超时 用户体验就有问题 这就是既要又要

@vx7298

这可以

不过 go 连类 c 的 macro 都没有...

@flyqie

可 最好是 runtime 重整 巨臃肿
泛型我个人觉得还是可以接受 如果降低编译效能考量 拿掉也不是不可以接受

@vfs

有泛型还是挺省力的 不用写太多 switch type 和反射 异常有 panic recover 即可不用太多东西

我也觉得这过于複杂

什么 vpn?

windows 下你只能用 wsl
使用 msys2 下的 mingw 版本 go 不支援信号功能

@Trim21

回传*T 非 nil 为成功 回传 error 为失败 回传 nil 为可接受失败(nil,nil)的意思？
rust 有这能力？ 其它语言这样搞还要判断回传类型 又多了麻烦

@Trim21

你这表示指的是"或"的意思吗 如果是不能表示回传两个 nil 如果是结构含两者那我说过了很丑
必需得要写新结构

@Trim21

这不是白说了吗 我需要同时判断两者

@hez2010

单返回值也只能够一直嵌套结构这种很丑的做法

@hez2010

重点在於不是所有错误都是不可接受的 照这种情况便要在接近的外层捕获 而单返回值也不能够表示 return nil, nil 这种状况 所以我才提那个例子 可以处理 error 也可以 panic

@hez2010

这叫多返回值 能返回的不只两个 其优点是避免了过多的结构嵌套 因为不是所有东西都值得写一个新的结构去包裹
重要的东西写结构更好 只是通常第二返回值为错误

错误处理方式当然直接中断是方便的 但中断本身消耗的资源就多一些 而且你不会知道什么时候会抛错 有些错误是不需要中断的这时候抛错的缺点就跑出来了 需要外部包裹捕获错误的代码 而且 go 并没有缺少中断抛错的方式 所以反而更好

近期我发现一种写法可能更好 那就是写个函数里头判断是否为 nil 不为则 panic 配上 go 里头强大的 import 很好用
go 的 import 具有普通 import 、import as 、import 仅作为依赖、import 至当前命名空间
比 java 的不知道好多少倍 不用写包全名 不用因命名空间让代码不够整洁
如下
package Panic

func PanicIfErr(err error) {
if err != nil {
panic(err)
}
}
=================================
package main

import (
"strconv"
. "example.org/panic"
)

func main() {
a := "123"
i, err := strconv.Atoi(a)
PanicIfErr(err)
println(i)
}