maven 不算好用，但是推 gradle 这个，你们没发现对于一个严谨的依赖配置来说，gradle 这种用动态脚本建立的 DSL 自身就是个大问题吗？
还有 2019 年了，成熟一点，别动不动就“新技术应该推”，新技术不代表都 tm 好好吗，有些新技术其实是翔，背后有其它目的才推出来的，你也赶着去吃屎？

楼主
“但它也是个文档数据库，key-value 数据库，时序数据库，流式计算引擎，搜索引擎,空间位置数据库;它几乎可以直接访问任意其他类型数据库，例如 Oracle，Mysql，Mongodb，Redis，ElasticSearch 等；它还可以直接变身为分布式数据库”

这些能详细说说吧，我很感兴趣

@X2031 开源太晚，国内晚了至少 Java 10 年。谁叫当年微软如日中天的时候太自大呢

@Narcissu5 C#的 await/async 的机制确实非常成熟，比 java 这边的好用，但是 await/async 必须成对出现的限制已经开始有人提到这是另外一种形式的“代码污染”

有个调查是这么说的，所谓响应式大约只能提高 15%——20%左右的性能，但是要付出 30%的复杂度。
人类的思维是线性的，阻塞式调用最符合直觉。
综上所述我对这玩意并不看好，响应式想要真普及必须在编码上无痛才行

现在卖服务器的都玩套路，优惠只给新用户一次，老用户完全没优惠，续费贵的要死。而且现在莫名其妙，个人用户的服务器卖的比企业还贵

要找借口都是理由，搞个虚拟机难度很大吗，现在电脑性能强的很，跑个虚拟机上全功能 linux，ssh 连上去啥干不了？懒就是懒，什么叫没有机会？

* 具备海量数据处理能力(所以要分布式)
* 在分布式的基础上仍然具备事务能力
* 依旧可以使用 SQL 作为语言进行查询

* jwt 只适合短期认证
* jwt 是把状态保持从服务器移动到了客户端
* 只要你不得不在服务端保存状态（比如你说的服务器可控强制踢出），那么 jwt 就不在合适，jwt 付出了传输内容膨胀的代价，就为了让服务器不保存状态，所以一切需要在服务器保存状态的需求，都不适合 jwt
* session 你也可以不用，你完全可以自定义一种比 jwt 简单的多的 token，然后把 token 的保存后移到缓存层，这样你的 http 接入层仍然是无状态的

最简单的文件服务器，Nginx 后面挂个目录

我提醒各位，国家对之前一段时间各种隐私，保密数据被泄露，滥用现象是非常不满的，我们这边有专人来讲课提到：会展开集中整治，且整治期间是从严从重的。从严从重的啥意思，也就是只要涉及到的，不管你有没有从中牟利，东西经了你的手，都会抓你。之前对各类毒博、菠菜游戏的整治也是同样的策略，所以连网上开源的棋牌代码都消失了。所以各位，这段时间建议别碰爬虫类的东西，等风头过了再说

别换，web 这块，初期你构建的快不快仅取决于你对语言本身熟悉不熟悉，我可以明确的说换个语言并不能让你快起来，你还得付出额外的学习成本

你这不就是配置化 UI 吗？不是什么稀奇玩意，别说 web，上个时代的 PC UI 都有，问题是这类 UI 都倒在了层次不穷的需求上了。UI 这个东西的复杂性在于需求多样化，特别的多，以至于你没有办法在贴近业务的领域抽象出通用化的 DSL 来，要知道 UI 开发搞了这么多年也就积累出了一个 MVC(MVP,MVVM)模式，不是没理由的，太靠近业务的地方变化太多了，没法抽象

现在开发机 32G 才是主流好吧，拜 Java 所赐，所有要跑 java 的或者要要跑 java 写的 IDE 的都是吃内存大户

没有“后端语言”这种说法，只有“后端应用”这种说法，理论上图灵完备的语言彼此之间可以互相替代到任何位置

Blazor 和那一批能直接编译成 WebAssembly 的语言一样，是冲着想把 JavaScript 干掉的目的去的，现在前后端出现互相渗透的趋势，NodeJS 想抢后端的地盘，后端也有诸多语言希望用 WebAssembly 把 JavaScript 干掉

@Mogugugugu 刚搞完，前几天发公告说所有核心系统去 Oracle 完成

@hkitdog 甲骨文要是不继续发布 MySQL，那 IBM，红帽支持的那个 MariaDB 立马就会出头你信不信。说难听点这个时代，开源代表业界领导力，甲骨文要是手上没有 MySQL，现在会更落魄

关系数据库 mysql，postgresql，下一代 newsql 大部分都是自研的，oracle 在传统领域仍然有稳定性和性能上的优势，但是：
1.太贵
2.不可控，出问题只能找甲骨文
3.传统关系数据面对海量数据时代的无力早已经是共识，甲骨文意识到了这一点，但是转身太晚，哪怕是像 mysql 这样看上去很简陋的关系数据库实现都早早的搞出了各种分布式方案，还是免费的。甲骨文有没有呢？有，但是贵。
4.甲骨文云化失败，本来如果甲骨文能云化成功的话，还有一线生机，可惜起步时间和微软差不多，现在微软的云化已经非常成功，稳坐美利坚第二把交易，甲骨文的云？啊？那是什么，好像没听说过。
5.最后，甲骨文的 oracle 数据库能有今天，其实也是靠海量的数据喂出来的，当年甲骨文进入中国电力系统，在海量数据的考验下爆出了诸多 bug，解决这些问题的经历造就了甲骨文的辉煌。而今天，各大互联网公司哪个手上没有海量的数据，喂都喂出来了，那甲骨文靠边站就是必然了。

感想：当年微软为了对抗甲骨文费尽心机，搞什么“破甲行动”。结果没啥效果。结果云时代一来，SqlServer 现在在云上可是舒服的很，而甲骨文，我看这怕是药丸啊