Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Moving from TypeScript to Rust / WebAssembly

nicolodavis.com

Post reply on HN
Print view View original

131–140 of 428 posts

Re: Moving from TypeScript to Rust / WebAssembly

#131

Post by mastrsushi »

Migrating a web app to a static typed system programming language is asinine. I swear these fanatics will do anything to say they rewrote it in Rust. This site is full of language-specific indulgent blog posts that are no more sophisticated than arguing over Pokemon cards.

I want to see more posts about exciting new concepts like WebAssembly. So sick of hearing that the world would be a better place if the sky and trees were written in Rust instead of C++.

Incoming Rust wankers to downvote my post to oblivion.

Re: Moving from TypeScript to Rust / WebAssembly

#132

Post by maxgraey »

v_pragma wrote: post #103

Keep in mind that WebAssembly is not a silver bullet for performance, and carefully crafted JS application (written in engine-friendly way) will perform roughly the same or even better than its WA equivalent. I've rewritten chunk of my math-intensive app in AssemblyScript half a year ago - it took me about a month to fight through all the compiler bugs, I used every optimization possible (used floats everywhere, disa…

That's pretty interesting. Could you share you project?

There are benchmark which compare JavaScript and AssemblyScript: https://github.com/nischayv/as-benchmarks https://github.com/nischayv/as-benchmarks/issues/3#issuecomm...

Re: Moving from TypeScript to Rust / WebAssembly

#133

Post by amitport »

skybrian wrote: post #112
amitport wrote: post #106

Earlier quoted context omitted.

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…

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.

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.

Re: Moving from TypeScript to Rust / WebAssembly

#134

Post by jfkebwjsbx »

echelon wrote: post #16
melling wrote: post #2

I don’t know Rust and haven’t done JavaScript for years but isn’t JavaScript a bit more of a higher level language, which would make a developer more productive? Rust being closer to the hardware should require more code, and effort, to accomplish the same task.

> isn’t JavaScript a bit more of a higher level language Rust has zero-cost abstractions that feel like using Ruby and a rich type system that makes it incredibly expressive. Working in other languages feels like going back to assembly. I wouldn't want to design state machines in any other language. Rust's enums make it feel smooth as butter. They're a killer app. (The whole ecosystem is. Cargo. Package naming. Trait…

You are probably being downvoted because of this sentence:

> Working in other languages feels like going back to assembly

This is not a preference, it is an exaggeration and an attack on all other languages.

It is also quite ironic given Rust is intended for low level programming.

Re: Moving from TypeScript to Rust / WebAssembly

#135

Post by friendzis »

aphextron wrote: post #67
hardwaregeek wrote: post #29

Whenever I write Rust, I have a lot of fun, but I'm still not sold on it for most web dev. The analogy that comes to mind is that Rust is a really nice sports car with a great engine. It handles like a dream and you can feel the powerful engine humming while driving it. With the right open road, it's a great time. You can really optimize code, make great abstractions and work with data easily. Unfortunately, web dev…

This really nails why languages like PHP and Ruby have won out over static typed, compiled ones for application level web development. The web is a massive collection of disjointed, loosely coupled APIs that all (just barely) interoperate to provide a massive array of functionality. Languages that tend to work well with it are those that are highly flexible around the corner cases of these technologies, and allow you…

I think you get it backwards. Things are disjointed, loosely coupled because highly dynamic languages have won. The flexibility of dynamic languages, which can be great when working around dynamic corner cases, does not force developers into fixed, well-defined contracts keeping everything loose and disjoint.

PHP is highly to blame. PHP, being a scripting language, is easy to deploy and keeps chugging along at all costs. It may do something nonsensical, but it will try to chug along to completion without aborting. It creates a system where it is easy to write and deploy something that usually works.

Re: Moving from TypeScript to Rust / WebAssembly

#136

Post by kd5bjo »

laurencerowe wrote: post #85
drewm1980 wrote: post #76

Earlier quoted context omitted.

Rust never has to run a garbage collector, because it already figured out the lifetimes of all the values in your program statically, with relatively minor help from the programmer. This may make your code faster or more likely to be correct than code written in some of those languages.

That's a fair point, I should distinguish heap allocation from reference counting. It still seems somewhat tricky to replicate the well proven arena allocation approach of Apache and Nginx which avoids memory fragmentation in current stable Rust though.

For general areana allocation, you can use something like the Bumpalo crate: https://docs.rs/bumpalo/3.4.0/bumpalo/

Re: Moving from TypeScript to Rust / WebAssembly

#137

Post by laurencerowe »

cies wrote: post #125
laurencerowe wrote: post #50

Earlier quoted context omitted.

For backend web development I was somewhat disappointed to see that many of the new web frameworks (all async) allocate extensively on the heap (for example lots of Strings in their http request types.) I mean it works but I don't understand why I would go to the bother of thinking about lifetimes when it seems performance would be similar to Kotlin / Swift / F#.

I'd be hard pressed if a backend in Rust gives the same perf as Kotlin/F#. Especially if you write the Rust with an async stack you will likely come out significantly faster than the other options: small binaries, short startup time, less memory usage, more throughput, slightly shorter request cycles, ... The only place that the langs you mention probably win is: learning curve (F# maybe not so much) a.k.a. getting l…

Whether to use an async stack or not is very application dependent. For something closer to an application server than a proxy server I’m unconvinced async would be superior to threads.

I feel that Rust should be competing with C/C++ here though. I want a modern language with the same speed and control of memory usage. What’s A little frustrating (and don’t get me wrong, I’m rooting for Rust to get there) is that it feels like it should be possible to offer this, at least for threaded web servers.

Re: Moving from TypeScript to Rust / WebAssembly

#138

Post by Karrot_Kream »

cies wrote: post #125
laurencerowe wrote: post #50

Earlier quoted context omitted.

For backend web development I was somewhat disappointed to see that many of the new web frameworks (all async) allocate extensively on the heap (for example lots of Strings in their http request types.) I mean it works but I don't understand why I would go to the bother of thinking about lifetimes when it seems performance would be similar to Kotlin / Swift / F#.

I'd be hard pressed if a backend in Rust gives the same perf as Kotlin/F#. Especially if you write the Rust with an async stack you will likely come out significantly faster than the other options: small binaries, short startup time, less memory usage, more throughput, slightly shorter request cycles, ... The only place that the langs you mention probably win is: learning curve (F# maybe not so much) a.k.a. getting l…

I'm not sure. These reasons sound reasonable, but in webapps most of the time is spent IO handling anyway. As long as you're using async implementations in any language with performant "threads", I'm not sure of there would be a large difference in response times unless computation was involved in the request path.

Re: Moving from TypeScript to Rust / WebAssembly

#139

Post by Karrot_Kream »

laurencerowe wrote: post #137
cies wrote: post #125

Earlier quoted context omitted.

I'd be hard pressed if a backend in Rust gives the same perf as Kotlin/F#. Especially if you write the Rust with an async stack you will likely come out significantly faster than the other options: small binaries, short startup time, less memory usage, more throughput, slightly shorter request cycles, ... The only place that the langs you mention probably win is: learning curve (F# maybe not so much) a.k.a. getting l…

Whether to use an async stack or not is very application dependent. For something closer to an application server than a proxy server I’m unconvinced async would be superior to threads. I feel that Rust should be competing with C/C++ here though. I want a modern language with the same speed and control of memory usage. What’s A little frustrating (and don’t get me wrong, I’m rooting for Rust to get there) is that it…

There are other interesting languages in this space that I really enjoy playing with. Both Nim and Zig generate native code and are really fun, albeit very different, languages to work with.

Re: Moving from TypeScript to Rust / WebAssembly

#140

Post by EugeneOZ »

hardwaregeek wrote: post #29

Whenever I write Rust, I have a lot of fun, but I'm still not sold on it for most web dev. The analogy that comes to mind is that Rust is a really nice sports car with a great engine. It handles like a dream and you can feel the powerful engine humming while driving it. With the right open road, it's a great time. You can really optimize code, make great abstractions and work with data easily. Unfortunately, web dev…

I use Rust for web not for performance, but for strict typing + smart compiler, safe refactoring, errors handling and many other language features - Rust is an amazing language even when you don't need performance.
Post reply on HN