相比于 Go 我觉得合适 Rust 更优雅一点。
语言设计上 Rust 完胜 GoLang 。
而且 Rust 是更底层的语言，经常写 Rust 能帮助你理解硬件的运行逻辑。
相比于 C/C++，Rust 的语法更加现代，有健全的包管理和构建工具。

正好最近在做的项目前后端深度使用 GraphQL 。

优点：
1. 强类型文档。GraphQL 本身首先是一门语言，而且是强类型语言，目前社区已有各种语言与 GraphQL 转换的工具。实践中，前端配合自动生成工具和 TypeScript 能确切知道每个 Query 每个变量每个属性的类型，省去了以往 RESTful API 项目中前端手动声明类型的麻烦。使用如果后端使用 TypeGraphQL 或者 NestJS 这类框架，能直接从 TypeSCript 的 Class 生成文档(schema)。

2. 自动聚合。以往 RESTful API 的每个接口的数据都是预先设计好的，前端展示的数据和后端返回的数据有时匹配不上，复杂的业务往往需要一层 BFF 层来做数据聚合。GraphQL 的返回数据是由前端决定的，能有效降低前后端的数据耦合程度，并且减少接口调用次数。

3. 更细致的鉴权。RESTful API 的鉴权颗粒度只停留在路由上，但是 GraphQL 能控制每个字段的访问权限。（讲道理 RESTful 也能，无非实现起来麻烦点）

缺点：
1. 迁移成本高。
2. 生态不完善。如果后端要用 GraphQL 的话目前几乎只能选 Node.js 了。其他语言生态都不完善，缺少 dataloader 、federation 等关键包库。
其他方面我觉得和 RESTful 相比，GraphQL 简直完胜啊

坑：
1. 著名的 N+1 问题。对于后端来说，需要对每一个列表查询进行优化避免 N + 1 。目前流行的解决方案是 dataloader 。
2. 每个前端项目只能有一张 GraphQL schema 。这使得后端必须部署一个网关来整个各个微服务，目前几乎只能用 Apollo Federation 来解决这个问题。
3. Subscriptions 。Apollo 实现了 Subscriptions 功能来帮助服务器主动发送消息。但是实践下来发现这个功能还是比较简陋的，不合适微服务架构和集群部署。

后端后期换 Go 我不是很理解。
在我看来 TypeScript 比 Go 优秀太多了。
Node.js 的生态与 Go 也是不相伯仲。另外看到前端有用 GraphQL ，那么后端用 Node.js 的 TypeORM/prisma + TypeGraphql/Nest.js 基本上是最优解。Node.js 关于 GraphQL 的生态比 Go 要领先一大截。
Go 比 Node.js 唯一优势就是性能，不过这一点只要多堆点机器就能解决了。
如果是要提升自己的话不如练练 Rust 。

语雀

@Chism #5
个人感觉 Vue 3.0 的数据更新机制比 React 好太多了。
React 因为它函数式编程的思路，每次数据更新都要重构组件。这就要求开发者需要手动权衡组件更新的开销对其进行优化，体现在代码上就是到处 memo 、useMemo 。
而 Vue 3 是通过 Proxy 监听依赖变化，数据更新时不必重构整个组件，通常不需要开发者手动优化，写起来顺畅多了。

如果要深耕前端的话，React 是必学的。
单纯做项目小而美的 demo 项目的话，目前 Vue3.0 就是我最心悦的框架了。

有一说一，Go 语言设计的真不怎么样

感谢楼主，mark 一下

个人推荐 Flutter

目前而言 RN 的生态比 Flutter 其实略逊一筹，阿里云腾讯云的很多服务会提供 Flutter 、iOS 、Android 的 SDK 但没有 RN 的 SDK 。Flutter 的开发的移动端应用目前能直接跑在 Web 端上。
Flutter 坑很多，听说 RN 坑更多。
《哔哩哔哩漫画》所有页面都是用 Flutter 开发的，流畅度非常不错。
另外是个人觉得 React 的函数式数据更新思路很奇怪，后来的 vue3 、solidjs 、Flutter 的 GetX 都没有采用 React 的函数式 + Hook 的思路，代码写起来顺畅多了。

我个人感触比较深的是 ORM 场景。C# 有 Entity Framework 、TypeScript 有 TypeORM 、MikroORM 、PHP 有 Eloquent 、Kotlin 的 Ktorm 。看过了以上 ORM 再看 Go 的 ORM 实践就很一言难尽。

优雅的 ORM(TypeORM)是这样的：
```
const article = await articleRepository.findOne({ title:"Tales of Ten Worlds"，published:true });
```
从 文字表里取一篇文章，取出来的变量直接从 findOne() 函数里传出来，非常顺畅。

Go (gorm) 语言是这样的：
```
var article Article
db.Where(&Article{Title: "Tales of Ten Worlds", Published: true}).First(&article)
```
先声明 article 为 Article ，再传指针到 First() 里，一下子打破了函数式编程的 「没有"副作用"」「不修改状态」的教条，这里将 article 的类型改为其他也不会有编译时错误。

或者这样(ent)的：
```
article :=client.Article.Query().
Where(article.TitleEQ("Tales of Ten Worlds"),article.PublishedEQ(true)).Limit(1)
```
这样确保了编译时类型安全但将查询条件改成了指令式的罗列，损失了简洁性。

GraphQL 大法好 https://graphql.cn/
GraphQL 就没有 get 、put 、delete ，全是 post ，根本不纠结。

有一说一，Go 语言是真的破烂。

拿 ORM 场景举例来说。
正常(TypeORM)是这样的：
```
const article = await articleRepository.findOne({ title:"Tales of Ten Worlds"，published:true });
```
从 文字表里取一篇文章，取出来的变量直接从 findOne() 函数里传出来，非常顺畅。

Go (gorm) 语言是这样的：
```
var article Article
db.Where(&Article{Title: "Tales of Ten Worlds", Published: true}).First(&article)
```

先声明 article 为 Article ，再传指针到 First() 里，一下子打破了函数式编程的 「没有"副作用"」「不修改状态」的教条，这里将 article 的类型改为其他也不会有编译时错误。

或者这样(ent)的：
```
article :=client.Article.Query().
Where(article.TitleEQ("Tales of Ten Worlds"),article.PublishedEQ(true)).Limit(1)
```
这样确保了编译时类型安全但将查询条件改成了指令式的罗列，损失了简洁性。

Go 语言自身的缺陷也是对开发者的限制，比如 Go 语言的 ORM 和 C#、php 、TypeScript 之流比就显得 too simple 。

小孩才做选择，大人 CSS In JS 、Utility CSS 全都要

https://fower.vercel.app/zh-cn/
https://xstyled.dev/

如果要支持 node.js 和 php 的话只有 dtm 了
https://github.com/dtm-labs/dtm

关键词：分布式事务
常用实现：AT 、TCC 、SAGA

https://seata.io/zh-cn/blog/tcc-mode-design-principle.html

php 行为

https://ruanyifeng.com/blog/2017/04/memory-leak.html
阮一峰这篇写的挺清晰的

文档做的很漂亮，对于中文学习者来说确实比 docker 官方的文档友好太多。

关于视频泼一下冷水
在开发运维工具的学习中最重要的是上手实操，这一点上 kubernetes 的官方交互式教程已经做的非常完善了。相比之下通过视频来学习并不能获得深刻的印象，真正实操的时候还得跟着文档敲，那为什么不一开始就跟着官方文档呢？

教程类视频的最大价值实际上是帮助制作者本身通过费曼技巧加深对知识的理解。
对于学习者而言，个人还是推荐尽量接触一手文档。