看来鸦哥坚持使用C语言啊,哈哈哈 
我认为最主要的是你说的这个语言,选择了就只能一路走到死承担更大的风险,而 haxe 的可选择机会很多。也可以编译为 C++ 再编译为 WASM,所以容错率更大。而且由于支持编译为 JS 的原因,可以用很少的代价过渡
你说的是 WASM 还是仓颉,在引擎内完善 WASM 支持不至于是一路走到死吧。
引擎只需要逐步支持,而且大部分工作都由 JS 引擎做了,比如先支持我们能放置 WASM 代码到项目,这样就已经可以用 Haxe 或任何你喜欢的语言了,虽然不是极致性能,但也比编译到 JS 要好,而且之后可以逐步开放 WASM API 来继续提升性能。
仓颉的话,现在我暂时相信 Cocos 倒闭也不相信华为会倒闭。
我说的是仓颉
仓颉 被停用,很正常,如果没有市场,迟早的事
苹果本来有个OC 语言,为什么要推个简单的,性能不如原来的swift
js/ts 用户群体这么庞大,不好好利用,去强推冷门语言,完全是开倒车
你真要性能,那就是C/C++
仓颉还是个饼,不是说立马接入,我只是感觉 Cocos 即使要再选一种语言也更可能选仓颉,毕竟和华为有挺多合作,我看之前仓库也有在对 eTS 做兼容优化。
当然,不聊爹,聊仓颉本身,我觉得也挺优秀的。
Haxe有很多公司资金支持,你可以在官网看到,而且已经运行很多年了,并且死亡细胞就是用Haxe语言写的
wasm 还是保持观望比较好, 君不见微软/谷歌/苹果没对wasm有多上心, 试想想现都没有wasm内直调i/o 的方法, 都是需要胶水代码。相反再看看像v8这种在jit下, 跑起来性能更虐wasm.
是C++阿,Haxe直接编译为C++,这就是我说的方向,直接引用引擎代码。至于为什么不直接用C++我上面已经说过了
WASI 在做了在做了。
v8 运行 WASM 也是会 JIT 的,本来就是同一个编译管道:WebAssembly compilation pipeline · V8
这类兼容、性能问题都能通过迭代解决,不用担心,主要是看技术原理上是否有阻碍。
还好啦,当然比不上对他们自己的系统上心,他们应该恨不得直接废除浏览器,但现在不也还好吗。
Make Web3 great again!
而且还有一点,C++比WASM快,引用panda的话
WASI 就那社区体量以及那佚代速度, 我想webgpu全面普及ta都未成熟。
至于V8, 怎麽想都是只会把资源投放在提升JS方面,因为js的社群实在太大.
这是肯定的,现在基本上都是预估 WASM 技术迭代到最后,性能大概会比原生慢 1.5 倍左右。
但我们说的不是业务代码吗,Cocos 引擎还是应该用原生性能的语言编写,只在 Web 平台上转至 WASM 运行,业务代码达到比原生慢 1.5x 已经够够的了吧,多少大型游戏还在 Lua 和蓝图。
我说的一直是先支持 WASM,这样就可以先解放用什么编程语言,你觉得 Haxe、Rust、C# 好,无所谓都可以,虽然性能不如直接编译成 C++,但你至少在使用方面没问题,这样看看人们自然而然会选择什么编程语言,针对更多人使用的语言做内置支持(像 JS)不就可以了吗?
我觉得以语言转语言这种风险实在太大, 比如转C++, 如果是转出来的C++有问题, 你还是从C++层处理。最致命性的问题是, 你在开发模式上用Haxe上跑得好好的, 打包成C++后不成, 那在项目进度上就多了一层延期风险。现在cc原生就有这様的情况, 开发模式下你在浏览器上跑, 一切没问题, 去到原生出问题了又要废劲排查。
这里真不得不佩服godot, 一个游戏引擎有多种语言版本, 这老外社区真玩得贼6
那只是轻中度的业务层,一深入涉及到网格,寻路,光照这些是不够用的。这就把上限锁死了
你的提议是所有平台用 WASM,而我的提议是原生用C++或者C#或Lua,而Web端可以用WASM及JS,而唯一支持我提议的只有Haxe能实现
并且使用我的提议能获得更大的性能提升,更小的过渡代价
所以这就是引擎应该做的事,而不是开发者,这就是我的提议,我虽然想尝试但是我认为赚钱比这个更重要
多语言支持我感觉短期是优势长期是劣势,看起来很美好满足所有人的喜好最终只会造成生态的分裂,Cocos2dx就是教训曾经也是支持c++ lua js Python等作为开发语言最后结果就是各自为战社区分裂了
问题是 WASM 是 JS 引擎的特性之一呀,支持它很简单而且是理所当然的,对于 Cocos 引擎来说,支持 WASM 就像支持 JS 的语法一样,其实不需要做太多的事情。
这 Web 规范都是他们制定的,如果谷歌不想做,那么就连规范都不会给通过,就像现在 JS 语言的提案受到浏览器厂商牵制很大,但是只要制定下来了就是会实现的。
所以需要一种万金油语言,Haxe满足了所有条件,一种语言可编译为多个语言