unicode grapheme cluster

对性能要求特别高的场景不太可能完全用 go 去做. 至少是在 hot path 上用 c/c++/rust 来处理.
所以完全替代 c++ 是不存在的. 这个任务就丢给 rust 这种吧.

对于绝大部分的应用服务来说 go 是可以用来取代 c/c++ 的. 心智负担上小不少.
当然这同样也是 Java 的主场.

我这边存 redis sorted set, score 是访问时间. 只记录最近一段时间的访客数据.

哈哈哈 2 楼憨憨... 明显人家是在表达 [ flutter 好于 rn ] 的意思.

go mod 那里恶心了啦. 通过 url 来定位 module 有什么问题的吗?
就算不符合自己的期望也不至于用上 [恶心] 这种词吧.

github 上有个专门的 repo. 引入里面的 svg 就好了.

之前给我家小朋友做的 iOS app 就是从里面的 svg 抽取出来的 path 数据.

简单明了的方式把事情搞定的能力...

一个产品如果不支持我常用的浏览器, 那我选择不用这个产品.

先看看是否误操作把 app store 的网络权限给关闭了

wow, local cache invalidation 这个功能点非常有升级动力

噢 sorry 没看到下面的更具体的问题

用第三方 client lib 来实现
开启 trace 会打印 query dsl
自己手写太太太麻烦了

@dioxide 实时协作是后面的事情了. 他们能做起来个人觉得他们那个 UI 引擎功不可没.
之前看过他们 CTO Evan 的几个 Shader 作品, 图形方面的技术还是挺厉害的.

Figma 不错的体验主要是来自于自己开发的 基于 WebGL 的 UI 引擎和 Web Assembly 化.
Electron 桌面版看上去就是简单的包装. 和 Web 下的体验没啥差别.

@katoyu 啥情商不情商的. 就是不想惯着这种行为而已.
而且你们这些人哪不但不给予支持还叫别人学做人... 悲哀...

没有工作可以提供, 只想说句加油.

主要是小孩的照片视频, 开个 iCloud 完美解决.. 其他的占不了大多.

这个开发难度。。。 作为一个常年两边都捣鼓的人来说, 都差不多, 这个看需求.

有的需求难度在客户端, 有的需求难度在服务端.

就拿我自己做过的项目来说:
1. 之前做的一个 Apple 平台上的项目, 客户端实现字典, 而且支持模糊查询, 还有大量图文排版还要兼顾性能等等等, 这种项目客户端的难度也不小. 而且这还不算是高难度的.

2. 之前做的一个棋牌服务, 大量的计算都在服务端. 为了让计算更快, 消耗更少的 cpu 和内存在算法和各种地方都要仔细考虑. 而且这也不算是高难度的.


但是最关键的一点区别是, 做服务端的时候很少有人在后面指点说这个左边移一点那个右边移一点, 几乎没有.

k8s 集群应该是逻辑上的集群吧 和微服务无关.