这是一个创建于 267 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
darksword21 PRO 你换个语言不就得了
|
 |
2
Leviathann 2025 年 4 月 27 日  4
他们把这当作优点，你以为
|
 |
3
bronyakaka 2025 年 4 月 27 日 2
要不前辈咋说别写业务，比 java 还啰嗦
|
 |
4
linanwy 2025 年 4 月 27 日 via iPhone
先用 js bigint 语法写，然后让 AI 转成 go 。不直接写 go
|
 |
5
sthwrong 2025 年 4 月 27 日 1
java 写大数一样啰嗦，甚至更啰嗦。
|
 |
6
0dJ6Tu8Za734L89T 2025 年 4 月 27 日
Java 不也这样吗
|
 |
7
w568w 2025 年 4 月 27 日 4
不允许重载运算符的语言都是这样的，然而重载运算符也有别的问题。
我觉得比较好的处理方法是中缀函数（ Infix Operators ），比如 Kotlin 、Scala 、Swift 和 Haskell 都有这样的功能： ```kotlin infix fun Int.foo(x: Int) = this + x * x print(2 foo 3) // 输出 11 ``` |
 |
8
roundgis 2025 年 4 月 27 日 via Android 2
这种不支持运算符重载的写数学计算都别扭
换 cpp c# kotlin 吧 |
 |
9
lujiaxing 2025 年 4 月 27 日 8
所以为什么说 golang 不适合写业务呢. 不是开玩笑的. 这种表达能力极其羸弱的编程语言, 就很适合写 infr, 比如写消息队列组件, 写个 Redis 替代品, 或者写编译器. 说白了就是适合写各种重算法轻逻辑的程序. 但是如果去写业务逻辑, 尤其是那种极其复杂, 不正交的业务逻辑那就是灾难.
|
 |
10
haierspi 2025 年 4 月 27 日
我咋没感觉到恶心... 可能我写 go 的时间 比 写 rust 多很多的原因?
|
 |
11
mx1700 2025 年 4 月 27 日 via Android
你不懂，大道至简
|
 |
12
wangritian 2025 年 4 月 27 日 2
语言都是工具，没什么恶心不恶心的，如果你是重度计算业务就不该考虑 go
选择语言肯定是奔着它的适用范围和生态去的 go 写业务的好处是没人能写太骚的代码，你拿过来绝对容易看懂，但没法优雅 |
 |
13
erwin1030 OP 1
回复给我看懵了 ，用 go 肯定是现在的场景就要用 go 呀。 我不是想知道能不能优化么。而且他一个东西不好还不能说了
|
 |
15
JustBecause 2025 年 4 月 27 日
@erwin1030 #13 也给我看蒙了，又不是独立开发者，用啥语言肯定是跟着项目走啊，这还能换的呢？
|
 |
16
lesismal 2025 年 4 月 27 日 4
性能，资源开销，语言特性，开发效率，标准库，三方库，社区资源。。。
没有一个语言能满足所有方面。 作为公司，在各方面相对平衡的情况下，性能、资源开销是更需要追求的，因为这意味着用户体验、企业成本。 curd boy 热衷于脚本语言或者 java 全家桶之类的写起来爽的层面的同时，可能也把自己能达到的高度限制了，这不是错事，因为绝大部分人都是普通 curd boy 。但这也改变不了好公司的技术栈好工程朝着 go rust 这些语言上倾斜的大趋势。 |
 |
17
xgdgsc 2025 年 4 月 27 日 via Android
调 julia
|
 |
18
Donahue 2025 年 4 月 27 日
我不理解为什么设计成
sum = sum.add(a, b) 而不是 sum = big.add(a, b) 为什么这个 add 是结构体的方法而不是 big 包的函数？这样设计为了性能吗，避免多余的内存分配开销么？感觉这样写有点不太符合直觉 |
 |
19
Nasei 2025 年 4 月 27 日
可以这么写
low.Div(low, big.NewInt(10)) |
 |
20
5261 2025 年 4 月 27 日
以前我觉得 go 的语法恶心，自从开始 Rust 后，我觉得 go 和 java 是世界上最美妙的语言（狗头） 哈哈
|
 |
21
kivmi 2025 年 4 月 27 日
@bronyakaka java 可以使用静态类方法，稍微好看点
|
|
22
kivmi 2025 年 4 月 27 日 1
go 的内存， 谁创建，谁管理，所以用之前，必须分配内存啊，不像 java 还可以使用静态类方法
|
 |
23
arielherself 2025 年 4 月 27 日 via iPhone
很多语言都不是由研究编程语言的人设计的，所以就会存在很多缺点。
|
 |
25
lance6716 2025 年 4 月 28 日 via Android 1
虽然 go 确实比较啰嗦，但你这三行里面有两行都是自己多写了才啰嗦的啊，看看文档正确的写法吧
|
 |
27
bruce0 2025 年 4 月 28 日
没有运算符重载的语言不都这样吗,又不是只有 go
 |
 |
28
ziyeziye 2025 年 4 月 28 日
可以使用 decimal 包，看起来要好一点，而且 bigint 大精度也没法用，还不如直接用 decimal
baseFee := decimal.NewFromInt(100) priority25 := decimal.NewFromInt(25) low := baseFee.Mul(decimal.NewFromInt(9)).Div(decimal.NewFromInt(10)) low = low.Add(priority25) fmt.Println("low", low) |
 |
29
aloxaf 2025 年 4 月 28 日
自己写正常的数学表达式，然后让 AI 帮你转成 Go 写法
|
 |
30
darklinden 2025 年 4 月 28 日
@5261 #20 rust 有函数重载的，纯写业务倒是比上面的舒坦多了。烦的是你需要算法等倒腾的时候，但是很多东西只要写一遍。写多了 c 艹，搞搞 rust 就觉得心智负担全丢给编译器了，舒爽
|
 |
31
woniu7 2025 年 4 月 28 日
优雅没有任何意义
|
 |
32
james122333 2025 年 4 月 28 日 via Android
这个你封装一下就好了 不想那就没办法
|
|
33
james122333 2025 年 4 月 28 日 via Android
|
 |
34
zzhirong 2025 年 4 月 28 日
|
|
38
zzhirong 2025 年 4 月 28 日 1
// 在 low 上执行链式操作 会好看些吧
low := new(big.Int) low.Mul(baseFee, big.NewInt(9)). Div(low, big.NewInt(10)). Add(low, priority25) |
 |
39
InkStone 2025 年 4 月 28 日
@woniu7 编程语言的优雅，追求的就是一件事：写出来的代码一眼能读出想实现的逻辑，并且它也确实是这个功能。
这种优雅就是需要语言层面支持的。OP 提的这个点就是个很好的例子。把代码设计成主楼这样有什么好处吗？又不好读又不好写。这个问题还真就一定得语言层支持操作符重载才能解决，且操作符重载就是这一类运算代码的最佳实现方法。 |
|
40
woniu7 2025 年 4 月 28 日
@InkStone 就以这个为例，你确定一眼看不出很难看出这是在干什么？？运算符重载用好可以很优雅，用不好可以很不优雅，go 就一刀切。比起用它做不优雅的事，这个稍微读一下就能懂，用它写不优雅的，你看死你
|
|
41
InkStone 2025 年 4 月 28 日
@woniu7 当然不能。是怎么样的倔强，让你腆着脸说这个式子能一眼看出要干嘛？
运算符重载可以很不优雅，但现实中 99.9%出现的地方都很优雅。非得鸡蛋里挑骨头找 corner case 当然能找得到，但有什么意义呢？ 相比之下 if err != nil 95%的时候都很不优雅，go 里不是照样用着么。 |
|
42
woniu7 2025 年 4 月 28 日
@InkStone 嘻嘻😁就算不是一眼，但是两眼。你说的对，golang 傻逼，我也不喜欢一刀切。反正个人觉得影响不大，没有一开始那么抵触，只能说是不那么优雅。
|
 |
43
Belmode 2025 年 4 月 28 日
如果是 kotlin 这类后现代语言，甚至可以优化成这样：
var low = baseFee mul 9 low = low div 10 low = log add priority25 这就更清晰易懂便于理解和阅读了！ |
 |
44
KMpAn8Obw1QhPoEP 2025 年 4 月 28 日 via Android
@arielherself 说白了就是 PL 门外汉 连语言设计者自己都不知道自己在做什么 但反过来 不乏设计优雅的语言曲高和寡 没人用
|
|
45
KMpAn8Obw1QhPoEP 2025 年 4 月 28 日 via Android
想知道楼主拿 go 在做什么
|
 |
46
wyntalgeer 2025 年 4 月 28 日
@enchilada2020 #45 eth
|
|
47
ziyeziye 2025 年 4 月 28 日
@wyntalgeer 你处理区块链的数据 bigint 更没用了，参考我在#29 的回复。
|
 |
48
mengzhuo 2025 年 4 月 28 日
|
|
49
mengzhuo 2025 年 4 月 28 日
再回 OP ，算 64 位以下的值，请用 int ，float ，不要没苦硬吃……
|
 |
50
kuanat 2025 年 4 月 28 日 1
1. 通过链式调用来写，比如
z.Add(&x, &y) .Mul(&z, &p) .Div(&z, &q) 这样可以减少中间值的使用，还是比较直观的 2. 使用 dot import ，如果你能将代码作用域规划得非常清晰，可以做到 var i Int // big.Int j := NewInt() 不推荐但是确实有用 3. 直接使用 ai 的 tab 补全，用注释写数学表达式，配合人工或者测试用例做 review 即可 |
 |
51
BeautifulSoap 2025 年 4 月 28 日
虽然 go 写这种的确不太好写，但主要还是因为不支持运算符重载啊。你随便找个不支持运算符重载的语言来写都是写成这一坨
作为一个写业务的，我是真的讨厌运算符重载。一旦有了这玩意，在对第三方包的对象或者自己很久前写的对方做运算符操作的时候，我都经常会疑神疑鬼的。因为我不知道我用的这玩意是不是什么时候被重载了 |
 |
52
fivee 2025 年 4 月 29 日 via Android
，go 时客观存在的，它本身没有强迫你用。你的问题是你自己和让你用 go 的人之间得冲突
|
 |
53
Newb1e 2025 年 4 月 29 日
@BeautifulSoap 确实，有好处，但搁不住有人玩花活
|
 |
54
fds 2025 年 4 月 29 日 1
后两句可以优化
low := new(big.Int).Mul(baseFee, big.NewInt(9)) low.Div(low, big.NewInt(10)) low.Add(low, priority25) 这样设计主要还是为了节省资源，用户可以选择中间是否使用临时变量，或者哪些变量可以重用等等。 |
|
55
vkZudze5p1h4py5H 2025 年 4 月 29 日
php 的安全运算方法也这个德行啊。
|
 |
56
lisxour 2025 年 4 月 29 日
这跟 go 无关吧，bigint 用起来就是这样的，js 那边也一样，虽然有的可以传 number ，内部自动包装，但本质也是将各个数转 bigint 再运算
|
 |
57
realpg PRO 虽然我看着也很恶心, 但是我还是希望 OP 能说明 你自己觉得恶心在哪里
你觉得你理想的语言应该怎么写... 我感觉很多人喷你或者支持你, 都没到你的点上 还是说明白的好 |
 |
58
iminto 2025 年 4 月 30 日 via Android
big 类型这么写我觉得能接受
|
 |
59
lysShub 2025 年 5 月 9 日
一般业务用不到这个吧，干啥的？
|
Select Language