- 主题:请教一下dotnet的兼容性
我们公司一直用 ruby on rails 开发 web 应用，最近开始考虑技术转型。新的开发栈基本是前后端彻底分离，后端只提供 web api 就好了。我个人是比较倾向 c# 的，主要原因是用了 ts 之后回不去没类型的开发了，再加上跟 java 和 go 比还是更喜欢 c# 的语法，尤其是能重载运算符，这样做计算的时候代码更好读，另外 async/await 的语法也应该更容易上手。
但是在有人提出了反对意见，由于我对 c#、asp.net 的历史和生态也没啥概念，所以特地来请教一下。
首先的问题就是代码兼容性，现在 dotnet/asp.net 也是每年都发新版本。是否会存在不同版本间有大量的代码需要重写，或者由于第三方依赖迟迟升级不上去的情况存在？如果有的话，产生问题的原因更多是因为 c# 的语法 breaking change，还是基础库接口产生了变化，或者是 asp.net 的升级导致的？
其次就是关于 web service，大概看了看 benchmarks，似乎 asp.net core 的效率还挺不错的。我的问题是 asp.net 作为后端开发，如果只是提供 web api，或者 grpc 的话，会不会有点太重了，有没有轻量一些的替代品？它的启动时间、内存占用的情况如何？
另外这个问题可能会有点儿特别，我开发用的系统是 ubuntu。我猜最好用的 ide 应该大概率是自家的 vs for windows，不过还是想问一下，有人在 linux 上用 vscode 吗？用起来感觉如何，会不会是非常难用的一个状态？比如我个人的感觉，哪怕稍微改点儿 java 代码，我也宁可下个 intellij idea，而不会选在 vscode 里面凑合。
--
FROM 222.153.56.*
代码的兼容性：
从 dotnet c0re 3.1 起，dotnet 的代码兼容性已经非常优秀，从 dotnet c0re 3.1 升级到 dotnet 5.0，然后再升级到 dotnet 6.0，都是只修改项目文件里面的版本声明，然后更新下 nuget 包对应版本就足够了。包版本不更新一般也没问题。（还需要更新CI里面 dockerFile的 base image sdk 和 runtime 版本，如果你用到的话）
第三方依赖这几年没见过因为 breaking change 升不上去的情况，api 接口都是经过慎重考虑的。每个版本更新都会有专门的 breaking changes 文档页，都是些很细微的地方，基本没影响。碰到过一些版本不适配的情况是 unit test 的 Nunit framework 用低版本的 package 不认识高版本的 .net 版本的情况，升级 package 到最新就好了。
.NET framework (windows 下的那个)的兼容性已经保持了20年了，不过不属于我们的考虑范围。
轻重问题：
现在我们是在 linux 用 docker 跑基于 asp.net c0re 的微服务，一个服务镜像打包后大概 200MB 左右，启动速度通常 1s 内，对于 server 端没什么好抱怨的了。如果你初始化代码写得多可能会稍慢点，但肯定在秒级别。实在在意启动速度可以启用 NativeAOT，虽然我觉得在 server 端意义不大，而且不少库不支持。
整个框架其实已经很轻量级了。如果用 MinimapApi 会更加轻量级。刚看了下 MinimapApi 的 helloworld 模板程序，跑了 15s 100 并发的 benchmark 之后，占用内存大概 160 MB 左右。不过 dotnet 是带 GC 的，你内存大，一直跑它就会多占用内存到阈值再 GC，可以通过 cgroup 之类的东西来限制。看自己的取舍是用 workstation GC (保持低内存占用但吞吐量差点)还是 server GC (优先吞吐量，内存可能会占用比较高).
开发环境：
我司基本上都是 Window 和 Mac 做开发工具，Windows 下用 Visual Studio 2022，Mac 用 JetBrains Rider 的比较多，有一个 Visual Studio for Mac，但我帮别人解决问题的时候用过几次，个人认为并不好用。vscode 有时候也用，可用性还不错，特别是快速代码浏览的时候，直接打开目录，不用等 vs 加载项目，但开发的爽快感个人感觉还是比不上 Visual Studio。
没见过有人真的在 linux 下面开发。或者你可以试试用 vscode remote，在 windows 下面开发 linux 上面的代码库。
【 在 eGust 的大作中提到: 】
: 我们公司一直用 ruby on rails 开发 web 应用，最近开始考虑技术转型。新的开发栈基本是前后端彻底分离，后端只提供 web api 就好了。我个人是比较倾向 c# 的，主要原因是用了 ts 之后回不去没类型的开发了，再加上跟 java 和 go 比还是更喜欢 c# 的语法，尤其是能重载运算符
: ，这样做计算的时候代码更好读，另外 async/await 的语法也应该更容易上手。
: 但是在有人提出了反对意见，由于我对 c#、asp.net 的历史和生态也没啥概念，所以特地来请教一下。
: ...................
--
FROM 113.65.10.*
太感谢了，刚才回了一堆又没发出来，也许过几天会再出来……
总之我感觉有信心了
【 在 keygen 的大作中提到: 】
: 代码的兼容性：
: ...................
--
FROM 222.153.56.*
你的这几个担心都不是问题。
代码兼容性：只有.net framework之间存在这个问题，net6往后都是做加法了，所以变化不会大。
性能：一个hello world的内存占用在20多m左右，运行时取决于你的gc模式，有激进的，也有保守的，可能会影响局部的benchmark。net6之后的minimal模式就是要给用户一个轻量级的startup模式，你可以用模版新建一个试一下
ide：如果只做后端，vs code没问题，它本身也是甚于electron开发的，所以对跨平台友好。
--
FROM 171.218.87.*
欢迎到时候一起讨论~
【 在 eGust 的大作中提到: 】
: 太感谢了，刚才回了一堆又没发出来，也许过几天会再出来……
: 总之我感觉有信心了
--
FROM 113.65.10.*
大佬♂膜拜
- 来自 水木社区APP v3.5.7
【 在 keygen 的大作中提到: 】
: 欢迎到时候一起讨论~
--
FROM 223.80.48.*
这两天试了一下，发现了几个小问题，不过都解决了
【 在 mingtong 的大作中提到: 】
: 你的这几个担心都不是问题。
: 代码兼容性：只有.net framework之间存在这个问题，net6往后都是做加法了，所以变化不会大。
: 性能：一个hello world的内存占用在20多m左右，运行时取决于你的gc模式，有激进的，也有保守的，可能会影响局部的benchmark。net6之后的minimal模式就是要给用户一个轻量级的startup模式，你可以用模版新建一个试一下
: ...................
--
FROM 203.184.25.*
目前感觉问题不大
唯一有问题的应用场景就是 aws lambda，冷启动时间实在是太感人了。相同的功能，如果用 node18 给 128M 内存，冷启动 950ms 返回结果。dotnet6 + 128M 大概 9s，如果把内存增加到256的话将近4s。
【 在 keygen 的大作中提到: 】
: 欢迎到时候一起讨论~
--
修改:eGust FROM 203.184.25.*
FROM 203.184.25.*
频繁 scale 波动，cold start的话，的确比较麻烦，比不上 aot 的和解析语言
据说 java 在 lambada 上更快点，不知道为什么，都是类似的处境
之前看文章有些人迁移到了 Container App，保留一个 instance 常驻来解决这个问题
aws 应该是 App2Container
不过我对这里面的成本之类的不熟悉
【 在 eGust 的大作中提到: 】
: 目前感觉问题不大
: 唯一有问题的应用场景就是 aws lambda，冷启动时间实在是太感人了。相同的功能，如果用 node18 给 128M 内存，冷启动 950ms 返回结果。dotnet6 + 128M 大概 9s，如果把内存增加到256的话将近4s。
--
FROM 59.41.68.*
我的实现还是基于 web service，对 lambda 的 event 进行转发。本地启动服务的时候，也能感觉到不是马上就起来的，所以 web service 本身的初始化也是占用不少时间的。如果直接处理 lambda event，就能把这部分时间省下来，缺点是直接绑 aws 上了。这个目前来说我觉得不重要，我也就是大概试一下，有个概念而已。
这方面可能 node 还是有优势吧，另外一个用 rust 写的服务，冷启动也要 1s+ 才返回结果。不过做的事情不一样，不好直接比。基于 web service 的实现，本身服务的启动速度非常敏感。而对传统的 web 框架来说，服务启动的时间不敏感。我回头还得再试个 py，这样做对比的时候有数字说话。我们公司其他人都还处于在想象的阶段，真正用过 lambda 的没几个人
另外 java 也是这个月初刚获得了一个免费的技术升级，大幅提高冷启动的速度。个人认为理论上 .net 也大同小异，估计下一个就会得到优化了。
【 在 keygen 的大作中提到: 】
: 频繁 scale 波动，cold start的话，的确比较麻烦，比不上 aot 的和解析语言
: 据说 java 在 lambada 上更快点，不知道为什么，都是类似的处境
: 之前看文章有些人迁移到了 Container App，保留一个 instance 常驻来解决这个问题
: ...................
--
修改:eGust FROM 222.153.59.*
FROM 222.153.59.*