@a33291 哈哈说的是实话. 其它语言的语法糖都它弱了. C#的核心问题还是在生态上. python 的性能实在太差, 除非用来做胶水, 它的性能属于放弃治疗的. 我天天写 python/ts, 越写越爽.

@leexy 另外 V2EX 这个平台我感觉并不适合文这个问题. 因为这个问题网上已经有了无数的答案, 知乎上这个问题我都看过好多次了,善用搜索引擎. 我怀疑你在水铜币😄😄😄. 我也是闲的无聊...

@kklk 工资和任何语言都没有太大的直接关系, 任何一门语言中都有高收入的, 只是有一个大致分布.
工资高的大部分职位要求的不是语言. 而是解决问题的综合能力.
作为职业程序员, 你至少需要会 2-4 门编程语言,
工业界广泛使用的这些语言: c/c++/rust, golang/c#/java, javascript/typescript, python/R, 你都可以学一学.
他们都有自己的生态位, 在自己的生态位上, 这些语言相比于其它语言有自己优势, 如果一定说哪一门必须学, 我推荐 JavaScript, 所以你首先要知道, 你未来主要想要从事什么样的工作, 它需要的技能树中那个语言是必须的, 就先去学它.
软件从来都不直接受到编程语言的限制. 但各个编程语言都有自己的习俗和看待并解决问题的思维.
多换几个语言, 可以看看从不同角度解决同一个问题时候的思维差异.
想要踏实将软件工程师作为职业, 最需要是牢固掌握考研的哪几门计算机核心课程, 然后选择自己喜欢的而且认为有钱途的方向深耕. 另外工作久了, 你会发现技术并不值钱, 值钱的是业务逻辑和商业模式.

@kklk 另外你需要找个事情来做, 例如使用 Span 写个性能不错的 JSON 解析器. 这种纯粹不需要依赖第三方的 API 的库, 可用考验你对语言的理解, 还有抽象问题的能力. 编程的核心是使用某个语言去抽象某种需求, 然后平衡各种矛盾. 如果你遇到学习问题, 我可以给你提供免费咨询.

@aw2350 人家学什么, 关你毛事! @kklk 它就是说 @aw2350 , C# in Depth(深入理解 C#), Essential C#(C#本质论), 另外微软提供的文档非常完善. 作为一门语言的 C#, 发展到 11 版本, 已经非常完善, .NET 6.X 的性能也绝对不差. 如果你不认为微软有原罪, 完全可用认证学. 另外 C#和 TypeScript 是同一个人建立的. 有很多相似性. 另外如果你需要找工作, 的确需要仔细思考, 国内.NET 的工资偏低, Java 系的很多人掌握了互联网的话语权, 微软自己又作死, 开源太晚!

@aglsv 你审查过 HTML 的实时元素吗? 我刚刚写了测试了一下, 完全没问题啊. 这个原理上来说, 和后端都应该没啥关系.

@aglsv 正常情况, 这 2 种写法, 浏览器应该发起的都是同一个路径, 也就是:protocol://host:port/$index_html_path/static/js/app.e6cc3797.js, 服务器收到的请求地址应该是同一个才对

@aglsv 没有抓不到一说, 你在浏览器的调试控制台看下, 它实际的请求路径是什么, 服务器不知道有相对路径这回事. 你看下浏览器实际发起请求的完整 URL 地址. 服务器发起的地址都是绝对地址, 找不到应该返回 404 或者其它重定向.

@aglsv 你的服务器是怎么配置的, 正常情况下: static/main.js 和./static/main.js 应该是一样的, 而使用域名+statc, 应该是必须写成 /static/main.js

@novolunt 你和我们说的不是一个东西, 而且根本不是解决问题的办法

@churchill 你这个说法, 我严重不同意, 针对互联网项目, 这样搞的确不大合适. 但政企很多项目, 在客户端直接好维护的多. 完全不需要搭建一套后端找人长期维护.

浏览器是没法解析 rtsp 的, 我目前用的是 hls 的流, 延迟 1-3s, 用的 H265, 在浏览器上使用 ffmpeg 的 wasm 解码 H265, 大部分浏览器都不支持直接播放 H265.

不明白你究竟想要做什么? 使用 ffmpeg 在客户端直接解码 rtsp 协议的流, 还是准备干嘛?

方式一: 有很多种办法可以保持事务一致性, 这个是数据库并发写入时保证一致性的基本操作了.
方式二: 并不会, 因为你这个结构就不可能有太多数据, 只要索引设计的正确, 不会有啥性能问题
书籍嘛: 我想到的有: 数据库概论(本科的教材), 高性能 MySQL, 数据库索引设计与优化, MongoDB 相关的设计原则, 对照一下关系数据库和 NoSQL 数据库的差异, 然后思考在 2 种模式下如何平衡性能 /一致性, 每一种选择都有自己的缺陷, 要根据你的业务场景寻求最佳 Schema. 有时候并不要求最佳, 甚至只需要有效就行. 等性能出了问题再去有针对的优化, 看的稍微远一点, 但不要太远.

@makelove 2 倍的 long, 16 字节, 打错了, mysql 用了 char32, 它应该是没提供原生的 uuid 支持

@makelove uuid 并不浪费内存, UUID 在很多数据库的实现中使用了 8 个字节, 也就是 2 倍 long 的长度, uuid 完全可以做到高效, 除非性能特别重要, 而且单个表数据极大, 否则选择 uuid 是一个很不错的选择, 性能是一个需要基准测试问题. 绝大部分系统的性能问题都不会因为你使用了 UUID 而导致. 反而我非常推荐使用 UUID 作为 id.

@erquiasz0825 因为按照分页查询时候, 数据会分散到不同的页, GUID 这种如果要作为主索引, 一定要支持自增, 否则插入 /查询都会有不小的性能损失. GUID 有自增的算法版本

非常麻烦, 我们的很多项目也是这个性质, 一个 core 分支, 每个人一个 dev 分支, 一个 main 分支(合并每个人的开发), X 个定制分支, 非常烦, 每次为 core 做 fix 或者 feat 都要重新 rebase, 然后重新测试. 一直没找到好办法. 但项目性质决定了, 赚的就是给客户定制软件的费用, 维护麻烦也是要做的.

@wdc63 没有这种数据结构, 不用找了