用过 php 或者 python 的 json 都非常开心

到 go 这边 真的头痛... 简单的 json 结构还好, 就怕碰到那种层级特别复杂的 json, 各种数组嵌套, 数组套数组的时候 , 简直想哭... 昨天就碰到一个 json 例子 斗了半天才搞出来, 愿意练手的朋友 可以试试怎么在 go 里面 实例化一个 struct 对应到下面这个 json, 烦点就在 那个 inline_keyboard 里面的数据结构
{"chat_id":"123","reply_markup":{"inline_keyboard":[[{"text":"text","callback_data":"callback:success"},{"text":"text","callback_data":"callback:fail"}]]},"reply_to_message_id":"112","text":"hello"}

用 go 去替换到你正常的工作语言, 写一两个月, 估计就熟练 go 了, 说不定还能忘掉老语言怎么写的了

感觉做反了.... 因为适配会越来越多, 所以个人感觉做成: 还不支持的 app 清单更好

只能说还好只有 70km, 如果是 120, 或者 140 的时候 , 真的不敢想

最骚的就是 上传油管的时候 用的英文.... 完美的一波 seo

不要 这么认真, 真的干这一行, 都会懂好几门语言的... 所以不要做得像生死抉择一样

这个打印操作是店家自己根据订单刷新, 手动打印的么

不是 go 的问题, 而是并发本身的模型 老哥要理解 ..
不然你随便看那个预言的线程, 或者协程都吃力...

@tangzui 就算正常寿命是 3 年的话, 你这 14 天也敲不出 3 年的量

质量再查 也不至于 14 天就敲松了

再便宜 也抵不过一堆 arm 吧

@Mitt 我也赞成, php 的优势就是写起来直白, 顺手.... 需要协程的时候 转 go 就行了, go 和 php 互动一下就行了...

不过从 php 官方的角度来说, 开发者可以不用, 但是不能没有, 不然老是在这几个[没有的功能点上] 被 go python 反复摩擦, 显得很弟弟

假设 百家姓里面就 100 个姓,
1 每个姓准备一个数据库, 把 13 亿个名字都存进去
2 数据库的 server 提供一个接口 ( http 的都行), 随时输出 当前记录的行数
3 写一个 100 线程或者 进程或者 协程的程序, 同时抓 100 个库里面的数字
4 轻轻松松一个排序...
以上应该 1 之内 就完成了, 且没有什么性能瓶颈, 还是 实时数据

轻轻的做一个定时器 curl 到国内服务器吧 ...然后还是前端一次请求..
应该是一个 10 分钟能搞定的最简单的办法