low := new(big.Int).Mul(baseFee, big.NewInt(9))

low = new(big.Int).Div(low, big.NewInt(10))

low = low.Add(low, priority25)

你换个语言不就得了

他们把这当作优点，你以为

要不前辈咋说别写业务，比 java 还啰嗦

先用 js bigint 语法写，然后让 AI 转成 go 。不直接写 go

java 写大数一样啰嗦，甚至更啰嗦。

Java 不也这样吗

不允许重载运算符的语言都是这样的，然而重载运算符也有别的问题。

我觉得比较好的处理方法是中缀函数（ Infix Operators ），比如 Kotlin 、Scala 、Swift 和 Haskell 都有这样的功能：

infix fun Int.foo(x: Int) = this + x * x

print(2 foo 3) // 输出 11

这种不支持运算符重载的写数学计算都别扭

换 cpp c＃ kotlin 吧

所以为什么说 golang 不适合写业务呢. 不是开玩笑的. 这种表达能力极其羸弱的编程语言, 就很适合写 infr, 比如写消息队列组件, 写个 Redis 替代品, 或者写编译器. 说白了就是适合写各种重算法轻逻辑的程序. 但是如果去写业务逻辑, 尤其是那种极其复杂, 不正交的业务逻辑那就是灾难.

我咋没感觉到恶心... 可能我写 go 的时间 比 写 rust 多很多的原因?

你不懂，大道至简

语言都是工具，没什么恶心不恶心的，如果你是重度计算业务就不该考虑 go
选择语言肯定是奔着它的适用范围和生态去的
go 写业务的好处是没人能写太骚的代码，你拿过来绝对容易看懂，但没法优雅

回复给我看懵了 ，用 go 肯定是现在的场景就要用 go 呀。 我不是想知道能不能优化么。而且他一个东西不好还不能说了

😂 另辟蹊径了

＃13 也给我看蒙了，又不是独立开发者，用啥语言肯定是跟着项目走啊，这还能换的呢？

性能，资源开销，语言特性，开发效率，标准库，三方库，社区资源。。。

没有一个语言能满足所有方面。
作为公司，在各方面相对平衡的情况下，性能、资源开销是更需要追求的，因为这意味着用户体验、企业成本。
curd boy 热衷于脚本语言或者 java 全家桶之类的写起来爽的层面的同时，可能也把自己能达到的高度限制了，这不是错事，因为绝大部分人都是普通 curd boy 。但这也改变不了好公司的技术栈好工程朝着 go rust 这些语言上倾斜的大趋势。

调 julia

我不理解为什么设计成
sum = sum.add(a, b)
而不是
sum = big.add(a, b)
为什么这个 add 是结构体的方法而不是 big 包的函数？这样设计为了性能吗，避免多余的内存分配开销么？感觉这样写有点不太符合直觉

可以这么写

low.Div(low, big.NewInt(10))

以前我觉得 go 的语法恶心，自从开始 Rust 后，我觉得 go 和 java 是世界上最美妙的语言（狗头） 哈哈

java 可以使用静态类方法，稍微好看点

go 的内存， 谁创建，谁管理，所以用之前，必须分配内存啊，不像 java 还可以使用静态类方法