电源感觉不够，另外不是富哥们显卡可以用丐点，机箱没仔细看，4070ti 真的很大，仔细确认机箱空间规格
这价格确实比我 618 时买的贵好多，当然我是 pdd

前半句同意一半，后半句完全同意

本地通讯录不就是这个功能吗，不过是不能共享罢了，真要是全民共享，那么号码记忆也不会简单，到时候会产生现在类似的“导航网站”，完全是脱裤子放屁啊

不玩游戏，建议换迷你主机，然后剩下的钱组 all in one 服务器

突然想到那个把大象装进冰箱要几步
1. 打开冰箱门(把现在的架构师挤走)
2. 把大象塞进去(任职架构师)
3. 关上冰箱门(把晋升通道堵死)
哈哈

在工作中你只能通过参与项目，特别是从 0 开始的项目来体现你的架构能力，而且要同事认可你。技术什么的没有那么重要

没有测试吗，不懂为啥会直接往生产分支上 push ，不应该先 push 到开发或测试分支上，生产分支从 dev/test 上拉吗，不清楚你们的流程，不过多评价

b 站上有个宁南左候，是视频，但是内容完全可以只听，讲的城市的故事 https://www.bilibili.com/video/BV1k24y1K7sc

k8s 和 spring cloud 的本质上并不是一个东西，所以并不能直接比较优劣。
k8s 是容器编排工具，现在也不单是编排了，更是一个大的平台。
spring cloud 是微服务的一个实现。

《凤凰架构》文中将这两放在一起是为了体现系统架构的演进，即 spring cloud 原本使用的组件如配置中心、注册中心、网关等现在正在往云原生方向发展。文中做对比的更多是一般的 spring cloud 和 spring-cloud-kubernetes ( https://spring.io/projects/spring-cloud-kubernetes )。

要理解为什么是这样的发展趋势得结合整个架构演进来看，也就是看书中的下一章“演进中的架构”，微服务对比单体服务而且带来了极为便捷的横向扩展能力，但随之而来的是复杂度，以及为了应对这些复杂度引入的新的组件，例如：因为有了多个实例，导致需要负载均衡，导致要有 ribbon 等。随着发展，目前主流趋势是希望把这部分不属于业务的内容下沉到更底层中去，而不需要业务代码层面上关心。所以有了 service mesh ，再往下 serverless 。

spring cloud kubernetes 就是将配置中心等交给 k8s 来负责。

所以如果从整体角度来看，他们也并没有本质区别，甚至对于大部分中小企业来说复杂度在不断上升，但是对于大型企业来说，让专门的人员负责专门的事是有效率提升的，业务 coder 就写业务就行了。

建议直接把链接贴出来

正好做过低代码项目

生成代码是通过模板引擎，只要你模板写的够全，能生成的代码就够细致

那个不需要部署代码就生效的倒是没做过，估计是传递表名等参数实现的动态查询，不推荐这种方式（但他们也不一定是这种方式实现的）。

低代码核心主要是两块，一个是代码生成，主要是写模板，另一个是对基础包的封装，也就是一个项目的基本配置，比如登录认证，用户管理，接口的标准化等等每个项目都需要的内容。将生成的 crud 代码放进这个基础包以完成功能开发。做的复杂点可以把基础包也做成可生成可定制的。

代码生成器可以看看这个
http:www.ballcat.cn/codegen/
https://github.com/ballcat-projects/ballcat-codegen

基础包配置的做法可以参考 jhipster https://github.com/jhipster/jhipster-bom ，他有个 CLI 可以命令行里初始化项目，但是我个人并不觉得这个好用，我自己现在是用模板引擎去配置

ps：jeecg 这个项目的代码质量前两年一直为人所诟病，有些功能的实现方式也有点问题。口碑毁誉参半，不知道现在有没有好点，当然这样的项目能开源出来还是好的

针对“难点就是理解其变量所有权、引用、借用的思想”，很明显对于更多我这种人而言，这只是第一部分的难点，后面还有生命周期，宏，智能指针，unsafe 等在其他流行语言（不代表全部）中不太涉及的概念。
然后回到主题，我感觉 rust 的火火在讨论层面，这主要在于应用场景上，Go 在云原生领域应用广泛，rust 则更适合底层，例如驱动。显然前者大家参与的更多。
再谈谈未来发展吧，我感觉 rust 目前的困境在于找不到合适的发力点和关键项目。官方推荐的不管是 wasm 还是嵌入式，rust 都有优势，但是不够让人抛弃现有的。大多数公司在技术选择上都是保守的，他们没有能力和资金去做科研。我个人比较看好 rust 在游戏引擎上发力，这个领域有需求，从业人数众多，但目前没看到什么领头的项目。

不限制国内开源可以用 metabase 或者 superset ，国内开源的大多进不了生产或者不活跃

初衷是好的，设计的不行，这个情况使用充血模型会好很多

用的 parsec ，也是 v 友推荐的，挺好的

https://i.imgur.com/r6gnkPl.png
windows 今早也遇到了这个问题，好在有提示哪里改，坑爹

代码解耦，通过引入依赖的方式选择需要的内容，但是项目杂了维护成本爆炸，工作量并不少，而且有时候你会发现同样是 F 功能到最后也会变得不一样，所以不如摆烂

可以用 gist ，不想用托管服务就自己部署个配置中心，appolo 、nacos 啥的，不想这么重量级就 nginx 设置下不就可以访问了

顺便提醒下，150 元的机箱大概率是装不下 40 系那些大卡的，如果预算有限建议从主板和电源上降低点，比如 B760 是否够用，海韵换长城是否能接受

看楼上部分内容，我想说 13600k 不是带核显的吗