@DOLLOR 他想让编译器给他检查流程, 就是这个函数的返回必须必须即有 string 也有 number, 我目前是没想到有什么方法, 因为这个需求本质也是一种类型运算, 需要编译器检测函数返回类型, 然后组合. 但是目前 TS 似乎没有那个类型本身可用进行这种特殊的类型约束, 因为这个约束类型 never 这种, 需要超越类型本身的信息, 做分支流程检测.

@Building C#的 Task 比较复杂, 并不是简单的协程, 既可以多线程, 也可以单线程

使用一个主线程去发送请求(和 MySQL 打交道, 发送异步请求), 关闭同步上下文, 然后在主线程上发送 HTTP 请求, 然后主线程就等待(用 Task.Delay()), 时间到了再次轮询数据库. 在 HTTP 的 IO 的 Task 上附加成功的后续操作, 这个操着会在线程池中获取一个空闲线程, 然后执行. 一开始配置好线程池的物理线程数量和 I/O 线程数量. 你给出来的信息太有限了, 很难给你分析. 另外真个场景我估计瓶颈不在 CPU, 如果后续操作费事很少, 则 CPU 应该一直空闲, 如果你开启了上下文同步, 则可能导致主线程假死!

@waiaan 没啥绝对的好处. 很多时候需要在一个目录树打开多个项目, 而这些项目已经存在磁盘的不同位置上, 如果没有工作区就会非常麻烦, 需要移动文件夹,一些项目甚至对绝对目录有依赖, 一旦移动位置, 就直接无法运行了. 工作区加入的原因和讨论在 VSCode 社区有讨论, VSCode 大部分功能的加入都是有公开讨论的. 工作区还可以跨项目配置 VSCode

@waiaan 工作区是一个逻辑分组, 可以将不同位置的不同目录组织在一个工作树中, 而文件夹是做不到这点的, 文件夹必须和物理磁盘的文件树解构保持一致

@shm7 我给朋友找了一个成熟的供应商, 我自己不折腾, 没有那个精力. 我感觉要做到商用精度也不是一个人短时间可以搞出来的.

如果可以, 这将被视为一个安全漏洞, 很快被浏览器厂商修复!

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/dns/resolve, 你需要的是这个, 但是这个 API 已经被删除了

@lankunblue 没有, 不用折腾了, 不使用网络工具或者自己封装浏览器就不要指望了. IP 这个层次的信息在传输层, HTTP 这种应用层不要指望了, MDN 上的关于网络有关的 API 就没有这种层面的公开 API. 同意 @rekulas 的观点, 这是个伪需求, 对于 WEB 层面的应用.

Java: userName
Python: user_name
CSharp: UserName

输出: JSON: userName
输出: XML: user-name

允许用户通过 HTTP Header 头控制格式化风格, 在 Web Service 中找个中间件做格式化反序列化和序列化

Python 当然应该使用 Python 自己的变量命名风格, 使用_做单词分割, 至于发送到前端的 json, 当然是找一个支持定义属性转换器的 json 解析库啥. 另外你一定要使用驼峰也不会有啥问题, python 核心库的命名规范本来就不统一, 各种乱七八糟的命名风格, 奇怪的缩写都有, 主要看你们项目的规范要求. 并不会造成什么问题.
我之前写过 Python/C#/Java, 命名规则都是按照语言标准库的形式来, 然后输出格式也按照目标数据格式的消费者的习俗来. 尽量减少阻力和不一致性. 但这样会对性能造成轻微损失.

@zoharSoul ZF 部门, 公共资源交易中心, 还有一些是涉密的, 不方便说.

@seakingii 和你所在的行业有关系, 我们这个行业使用 Linux 才是非主流, 基本清一色 Windows Server 2016, 没有专业运维, 使用 Linux 纯粹是给自己找麻烦!

你这个需求非常简单, 甚至只需要几个小时就能搞定. 但是如果你需要熟练掌握 Linux/Windows 运维, 要学的东西可多了,这个只能日积月累, 因为经验才是运维的核心竞争力. Linux 基础运维使用: 鸟哥的 Linux 私房菜, 过一遍就好了, 然后根据你需要部署的软件去 Google 搜索教程, 也可以先使用百度, 遇到搞不定的再去外网找权威资料.

我只是一个小透明, 主要是 FP16(也比较少),FP32(密集), uint8 很少(transforms 最初需要), 然后就需要大量的累乘和加法了, 因为不同类型的运算耗时也是不同的, 所有只能综合考虑.一般 TOPS 应该是只能做 8 位的定点数运算, 浮点运算需要模拟, 一般 GPU 我感觉都是使用 FLOPS, TOPS 用在于 FPGA, 很少看到混合使用. 另外芯片中不同位长, 不同类型的运算所需要的时间都不相同, 不在同一个标准, 有时候很难定量的去比较实际差异, 你可以 google 搜索一下相关的研究论文.

没有直接的换算关系, 否则就不会出现这么多单位了. 主要看你干什么, 因为不同场景下评估一个芯片的算力使用同一个单位是无法准确对比其真实性能的. 不同类型的任务有时候用的操作类型有时候相差很多, 甚至完全不相干. 在做卷积神经网络训练的时候, 我们做报告都使用 GMACs, 因为主要的就是乘积累加运算.

另外不要在携程中试图依赖确定性的调用顺序, 除非你手动同步, 或者使用链式等待

因为规范并不保证 333, 444, 555 的执行顺序, 它唯一保证的就是 444 总应该在 333 后面, 而 333, 444, 555 的确定性顺序是未定义行为, 我猜想是编译器优化了无返回值的情况, 这样 555 就更快的得到了执行(还没有执行到 444, 当你手动编写了 Promise.resolve()后, 这个执行需要消耗时间, 这个期间, 444 的任务链条可能已经结束了执行, 因此就是你看到的 333, 444, 555, 不过正如楼上所说, 这些对实际开发影响很小. 你如果除了对 what, 还对 why 感兴趣, 也可以自己深入去研究一下