看来应该是没了 改天自己造一个轮子

@Buges

vi/vim/nvim/emacs/nano/kate/gedit/vscode/kakoune/scite 不认
认的我都不讲了没人会想用的...

@Buges

需要权限 而且几乎所有编辑器都不认 block device...
fuse 好处就是普通 user 权限就可以运行了

@Buges

可惜这个项目分割大小有固定容量限制 写多该分割块会有问题 再找找有没有其他现成的 不然 fuse 其实很不错

@pagxir
vim 可以 16 进制编辑

回一下楼主的 基本上楼上很多人讲的都很耗能
以下这个才是最好的解法
https://sourceforge.net/projects/joinsplitfs
user 权限秒挂载 编辑后卸载(fusermount -u)就可以

大而全才会要求 vim 本身来解决 然而 vim 本身就可以调用外部工具

然而 java 做久了还是在给人打工 那些好职缺你想进别人还不给进呢 不是说你有 java 项目经验就可以的 只能说当那么久的 phper 楼主都没玩出什么花样 php 比 java 吸收知识容易多了... 看过很多 java 缺 也没见过人玩出什么花样... 你觉得 zoom 是好缺 怎么没看到 zoom 有一票竞争者呢

@Macolor21

因为类型所以全代码都很清晰？... 类型清晰了但代码乱在其他也没用... 而且 go 也是类型
go 主要是比较容易强迫你写出比较工整的代码 外加语法简单 这样来讲就是更清晰
我都写 java 但很多 javaer 其实就习惯了 满足于现状 不能意识到这堆山堆的有多高 如果没有网路资源 又要花多少时间除错...

@Joker123456789

"字数上相差多少，我是懒得数了，但是你们真的不觉得 java 的结构更清晰吗？ 其他的继承，多态 我就不拿出来说了，go 基本上是 用的 c 的编程思想，oop 只是个兼容， 所以用 java 来跟他比 oop 没什么可比性。因为是两个方向。"
=> 没觉得比较清晰 java 是 field 与 method 混在一起 东西多了会很乱 go 的反而清晰多了

"但是 go 需要用 defer ，而且一旦抛出异常就意味着这个函数结束了，你如果想在出异常后，处理一下 然后继续往下走，go 会非常的麻烦。"
=> 你封装一个函数以后都用那个函数 以结果来讲一模一样 封装也不麻烦 而且还不用注意哪些要抛出哪些不用

"// 不管装箱前是什么，只要他的值是一个整数 // 无论是 1 ， 还是 "1", 都可以这么转"
=> 你用了 Integer.parseInt 然而你 go 自己写个函数里面 switch type 判断是更佳的 如果你确定就是 int 那直接转就可以

@james122333

看东西多不多 越多越有感 赶工的话更是
然而我自己弄的是秒开

@gjquoiai

不支持 同名的只能有一个 剩下冲突名称的要使用全名

@Chinsung

spring 的性能是它的缺点之一 运行状况是会慢些 启动的话是慢到怀疑人生
spring 有线程池 连接池用其他的没错 spring 本来不该拿来跟 nio 比没错
那是 tomcat 的锅 用 spring 也没必要一定得使用 tomcat...
graalvm 反射不是要写设定... 反正目前懒得研究

@Chinsung

语言本身与框架本来就要分开来看 不是流行就是真理
spring 与没有动态反射的确实会有性能差异 感觉还是自己写爽多了

@TWorldIsNButThis

会有重复类名 真正的问题在于 java 并没有 import as 导致你要写完整包路径

@mekingname

java 本身、jvm 就不讲了 重点 spring 那一套 基本上都可以更简单的实现 灵活性可维护性都可以很好 一堆人还把 spring 当成宝 甚至熟悉一些稍微封装就能达成一样功能的特色就觉得高人一等然后面试用来洗脸...

这就属于看人吹哪个或生态哪个好就用它
shell 也可以自动化运维 需要一些功底就是

@jeesk

楼主还在纠结同样线程并且是大量线程

不知道什么纷争也不好讲了

@Vitta

可以这样实现 但我想应该不会有人这样干

@Vitta

1 的话觉得还好 毕竟层层 return 是很麻烦的事情 一个接口也可能很多需求 纯编排基本逻辑并传递下去其实还可以 也很灵活 service 层可以拆的很细
2 3 不说了

@jeesk

如果它真的这样搞那么你应该丢掉它 很多专案本来就很糟糕 甚至你改用其它语言