[nicolodavis]

Hey Amit, good to hear from you!

> Javascript is fast enough for your use case. No one will notice the difference in a board game website.

No, actually. Have you seen how long boardgame.io's MCTS bot takes to make a Tic-Tac-Toe move? Not the end of the world, but certainly in need of improvement.

[amitport]

Yes, but AI search algorithms like MCTS are slow in general. Even with C, it will be very slow when you want the AI to be smart and consider many actions. IMO, you should train using python libs like [1] and move it to the browser with something like [2] OR run AI in the server. YES definitely writing an AI lib for the browser is a great goal, and as a programmer, it is super interesting. Still, it is tough, and time-to-market is much more crucial, as the entire codebase will change once it will interact with actual people.

[1] https://github.com/datamllab/rlcard

[2] https://onnx.ai/

[skybrian]

Other than solved games like tic-tac-toe, game-playing bots can always use more performance because if you can search more efficiently, your bot gets smarter. Sometimes supposedly more sophisticated algorithms end up making things worse because they slow down the search.

It's an unusual area where functionality (what answer you get) and performance can't be separated. This is still true on the server.

[amitport]

To be clear, I'm not talking about the server implementation only about implementation on the browser.

And of course, Rust and C are faster than javascript, and it will be noticeable on search algorithms, but IMO, it will not cause user loss. It is smarter to get to the stage you have those users as fast as you can to validate this need.

So I would not go into implementing new AI libs in rust as part of a turn-based game engine just for the performance gain--mainly because it is a tougher project than building a turn-based game engine!

I would search for existing, viable solutions. As I said before, this includes server AI and server trained models running on something like tensorflow.js. Additionally, I will also try to research browser libs that may use compiled webassembly and webGL. In any case, I think it's not wise to build your own for this purpose.

[Shorel]

Please ignore him whole hearty.

Some people want to write profitable apps in the shortest amount of time possible, while others want to advance the state of the art in technology.

IMO we always need more people in the second group. And sometimes, you can hit the jackpot and do both things at the same time!

[amitport]

"Please ignore him whole hearty."

My advice is not about profit.

My "time-to-market is most important" advice (not mine, it is a very sound and well researched strategy) is about making a sustainable project:

A) most passion-only projects are abandoned at some point in order to pay for food and rent. (Yes there are few exceptions among an ocean of failed projects)

B) The other point is that even if you can run this for years before showing traction. Having users mean getting feedback, which will render some of your efforts needless.

Moreover, it was only a small part of what I said. I do think that rust doesn't make sense for other reasons, and doing a rewrite in a real project needs better reasoning otherwise you would keep rewriting forever.

Moreover2, I think you're misinterpreting the original author's intent. I'm not sure if there is interest in building AI in rust as a goal for itself. Seems to me more oriented towards the result than about the love for rust.

[spion]

For a lot of code, if you write JS like you write C (avoid allocations by avoiding the creation of objects, arrays or closures) you should get very comparable performance i.e. within 30% to 50% of C performance

[littlestymaar]

You can indeed avoid most of the js overhead if you use a particular subset of the language. In fact, that's how asmjs started, but:

- it's not JavaScript anymore, you'll lose most idioms you're used to work with, and it's a nightmare to maintain because it's pretty low level.

- it won't be as fast as it could unless the runtime is aware of the fact that you are using that subset (that's why asmjs used some annotation to run on a special engine on Firefox, and part of the reason why browsers moved to wasm).

[XCSme]

I don't know about JS being slow, while working on https://curvefever.pro it was not too hard to make the game run at 4k, 60FPS for a 6 player multi-player game that renders dynamic geometry with collisions which changes multiple times per tick.

JS is pretty fast if you use TypedArrays, are careful with WebGL calls and pool objects (reduce memory allocations).