你们前端以为 React/Vue 就是尽头了吗?
Too young! 我们后端扶你们起来继续学!! 哈哈哈

@bthulu 打工的话，最好还是走流程.
如果是自己的项目, 可以. 但也仅仅限于单机 service, 不然改的部分不方便 sync 到其它 service replicas.

@lrh3321 我也做过在 local 跑步起来的项目，可以理解. 不过你们测试都要考虑 MTU 大小, 确实挺特殊的.

在非特殊的, 大多数情况下，如果开发环境在 local 跑不起来，那多半是 CTO/Infra/DevOps 们没好好设计, 最后是干活的工程师生活质量受影响. 用 remote 开发, 一般是补偿这种 infra 设计上的问题... 后端的组呆多了, 有时候就是这样, 遇上了也没办法, 只能适应.

你们要在 remote server/dev 机器上跑 VSCode server, 然后远程开发的, 不会卡么...
如果后端构架是 micro services 的话, dev/stage 的机器比本地开发机器弱太多了吧, 大点的项目不得卡死.

我能想到的最适合 remote 开发的, 是那种很贵很大的科学计算服务器, 因为 remote server 比本地强多了.
不然你留着本地 16G/32G Mac Book Pro 不用，连到 remote micro service server, VSCode LSP server 在 remote 大项目 repo 上一跑，间歇性卡到不行，不是很影响开发体验.

@echoZero 这种本地虚拟机开发，goland 也可以搞定吧

@bthulu 你这个"线上直接改最简单高效. 线下改还要重新发版"
是在 production 上直接裸奔改 bug 么? 那你司风格粗犷, 哈哈哈

@hopingtop #15 各种安全要求确实烦，在有些很别扭的安全要求下，即使 remote 也难以跑起来...
如果你们公司的东西，本地就是跑不起来，那没办法了. 我也在这种公司 or 组工作过, 很痛苦, 可以理解...

@lrh3321 #19 dev/stage/prod 环境要强一致的话，不应该是 docker/LXC 之类实现的么? 另外, 不想在本地搭建整个 dev 环境的话, 可以设置 dev 环境里的各种 proxy, 可以让本地 service 假装在 dev 环境里.
我假设我说的是针对后端开发，构架是 micro services.

作为后端，一直不了解你们成迷于远程开发是为啥.
正确不步骤不该是自己 local 调试好了，脚本 push/deploy 到 cluster 里所有的机器.
这样的话，即使调远程调试，也应该在远程的 *一个* server 机器上调试么? 类似你 local 的开发机.
真的要调试分布式程序，不该是打 log ，然后在 log service 上看么. stage, prod 都改如此搞.
所以你们远程调试的有点到底是啥?

Rust... 我是来抖机灵的...

除了 Unity 的话(他家最近确实整了些烂活), 相对成熟的 2D engine 还是 https://phaser.io
你可以用 JS/TS + C/C++/Rust lib 来写程序.

dead end ...

你这个是 tailwind 的问题，还是 astro 里使用 tailwind 的问题

不能买个 1 手的 M2 Mac Mini 16G 内存吗? 再看看现在有教育折扣没

@xuld

语言要成功，只有两种途径.
1. 找个有钱的爹养着，并且推广.
2. 你的语言能出现杀手级应用, 然后靠这个应用推广.
这个两个其实不是语言本身能解决的.

你想没啥资源就成功的话, 掂量下你能把 2 做成功不?
2 的成功，不是你纸上说啥啥啥就算数的，最终要大量用户说了算数.

用 Unity 就老实用 C#, 最好不要搞第三方的 JS/Lua 那种动态更新, 除非这个 JS/Lua 是你自己写的.
真的要用 JS, 就用 https://phaser.io/

@moxuanyuan 下班干点有意义的事情, 别过度折腾 docker+k8s 这套工业垃圾, 这套东西就是设计出来需要一个"专业 Ops 团队", 天天搞面向 yml 编程的东西. 这样 Developer 和 Ops 就完美分开了. Developer 只懂开发, Ops 只懂配 yaml, 标准化以后, 工程师跟 fastfood 里只懂一个工序的店员一样 ...

@robking 那还不错, 专门做 DevOps, 几年后工具可能又洗牌了...