- 主题:zz为什么go没有像JAVA一样的注解
非严格对应的话，C#的attribute勉强可以算？
【 在 zhangyoung 的大作中提到: 】
: python也有注解
: c#没这玩意儿
--
修改:adoal FROM 122.234.57.*
FROM 122.234.57.*
翻译一下，设计的时候没想过要支持，现在想支持整个设计都得改，而且这功能也不是不可替代，大家先用简单的。
另一个例子: 泛型。十六年了，终于还是加上了。没泛型的恶心代码，多复制几次吐吐就习惯了。
【 在 littleSram 的大作中提到: 】
:
https://developer.51cto.com/article/685841.html :
: --Go Contributor @ianlancetaylor 给出了明确的答复，Go 在设计上更倾向于明确的、显式的编程风格。
:
: 思考的优缺点如下：
:
: 优势
: ..................
发自「今日水木 on Android」
--
FROM 221.216.116.*
注解比泛型加起来容易的多吧
【 在 wudashu 的大作中提到: 】
: 翻译一下，设计的时候没想过要支持，现在想支持整个设计都得改，而且这功能也不是不可替代，大家先用简单的。
: 另一个例子: 泛型。十六年了，终于还是加上了。没泛型的恶心代码，多复制几次吐吐就习惯了。
: 发自「今日水木 on Android」
--
FROM 114.249.23.*
一个功能加不加，和难不难没关系。
go的原则是一切从简，除非用户呼声够大，否则不可能加的。
如果可以选，我推荐试试kotlin，比go先进十年。go能干的它都能干。
【 在 littleSram 的大作中提到: 】
:
: 注解比泛型加起来容易的多吧
: --
:
发自「今日水木 on Android」
--
FROM 221.216.116.*
很多产品都这么吹自己
真这么好，就会很快拿下市场的
【 在 wudashu 的大作中提到: 】
: 如果可以选，我推荐试试kotlin，比go先进十年。go能干的它都能干。
: ...................
--
FROM 47.144.172.*
kotlin native 现在怎么样了？
【 在 wudashu 的大作中提到: 】
: 一个功能加不加，和难不难没关系。
: go的原则是一切从简，除非用户呼声够大，否则不可能加的。
: 如果可以选，我推荐试试kotlin，比go先进十年。go能干的它都能干。
: ...................
--
FROM 47.243.39.*
好像可以，等有空好好学一遍c#，泛型操作符重载都不错
【 在 adoal 的大作中提到: 】
: 非严格对应的话，C#的attribute勉强可以算？
--
FROM 101.93.88.*
听说现在 enum 的呼声也非常高
那么问题来了，为啥不干脆直接上 rust
【 在 wudashu 的大作中提到: 】
: 翻译一下，设计的时候没想过要支持，现在想支持整个设计都得改，而且这功能也不是不可替代，大家先用简单的。
: 另一个例子: 泛型。十六年了，终于还是加上了。没泛型的恶心代码，多复制几次吐吐就习惯了。
: 发自「今日水木 on Android」
: ...................
--
FROM 203.211.108.*
最近有个关于 golang 帖子又在 hacker news 和 reddit 上面又火了
reddit 上面有个吐槽我觉得非常贴切：
Go's problem isn't that it "wasn't designed as a language for the web"; it can be more generally stated as "wasn't designed as a language for the 21st century".
【 在 wudashu 的大作中提到: 】
: 一个功能加不加，和难不难没关系。
: go的原则是一切从简，除非用户呼声够大，否则不可能加的。
: 如果可以选，我推荐试试kotlin，比go先进十年。go能干的它都能干。
: ...................
--
FROM 203.211.108.*
是啊，我也对那些要这个要那个的人很不能理解，为什么不直接用C++，不喜欢C++就用Rust，再不就Java，C#也行啊，为什么一定要把Go改成其他语言的样子？不是本末倒置，舍近求远吗？
【 在 eGust 的大作中提到: 】
: 听说现在 enum 的呼声也非常高
: 那么问题来了，为啥不干脆直接上 rust
--
FROM 101.85.35.*