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

111–120 of 428 posts

Re: Moving from TypeScript to Rust / WebAssembly

#111

Post by quickthrower2 »

pjmlp wrote: post #81
aphextron wrote: post #67

Earlier quoted context omitted.

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…

Having ridden the 90's .com startup wave with an in-house application server written in a mix of Apache plugins and Tcl, I learned the hard way to never again rely on anything that doesn't bring a JIT or AOT compiler to the party.

What's the hard lesson? Performance? You have more power these days. The bottleneck won't be the interpreter.

Re: Moving from TypeScript to Rust / WebAssembly

#112

Post by skybrian »

amitport wrote: post #106
nicolodavis wrote: post #99

Earlier quoted context omitted.

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.

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.

Re: Moving from TypeScript to Rust / WebAssembly

#113

Post by jfkebwjsbx »

blub wrote: post #84
aphextron wrote: post #67

Earlier quoted context omitted.

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…

They've "won" so far because static types languages were cumbersome and unpleasant to use, but this is changing and dynamic languages are learning some type tricks too. The issue here is with Rust: its strengths are mostly irrelevant for the web and its weaknesses (particularly slow development compared to the competition because of having to pacify the type checker) are really important. Op is painstakingly beating…

For a lot of "usual" webdev, any reasonably modern language will do. Even modern JavaScript will be fine. Something like C# would have been way better, though, but we cannot change that now.

However... software development has become a mess of slow technologies and abstractions one on top of the other.

Some people are working routinely in a text editor that is behind three operating systems: the VM/hypervisor, the usual operating system (Windows/macOS/Linux) and then a browser instance (which is like a operating system now). Then add all the drivers, libraries, frameworks etc. that go in-between.

While I don't like that WebAssembly is yet another abstraction, at least it is a chance for a resurgence of system programming languages and to proper software engineering...

Re: Moving from TypeScript to Rust / WebAssembly

#114

Post by iCarrot »

titzer wrote: post #38
chickenpotpie wrote: post #21

A little disappointed not to see https://www.assemblyscript.org/ included in the discussion. Especially since it removes the "JavaScript is slower than WASM" argument.

I'm not quite sure what you mean here, because AssemblyScript compiles to WASM, not JS.

I guess the argument was that you can write in JS (well, something that is close to TypeScript which is close to JS anyway) and compile to WASM, therefore the speed argument becomes invalid.

Re: Moving from TypeScript to Rust / WebAssembly

#115

Post by loxs »

Matthias247 wrote: post #57
chjj wrote: post #46

> webassembly is faster than javascript Everyone says this, but I would dispute it as misleading in a lot of cases. I've been experimenting a lot with wasm lately. Yes, it is faster than javascript, but not by all that much. It's the speed of generic 32 bit C. It leaves a lot to be desired in the way of performance. My crypto library, when compiled to web assembly, is maybe 2-3x the speed of the equivalent javascript…

>> webassembly is faster than javascript > Everyone says this, but I would dispute it as misleading in a lot of cases. I've been experimenting a lot with wasm lately. Yes, it is faster than javascript, but not by all that much. I think even if it is faster in general, you might lose all that advantage as soon as you have to cross the WASM JS boundary and have to create new object instances (and associated garbage) th…

I am writing an app that needs worker threads both on the backend and also on the frontend (because of some heavy processing of large amounts of "objects") and my experience with TS so far is very poor. JS runtimes are just not suitable for heavy concurrent/parallel processing. Serialization/deserialization overhead between threads is probably (much) worse than it would be if the worker threads were in Rust.

It's not a matter of speed here. It's a matter of enabling certain types of programs which are borderline impossible with pure JS runtimes.

So I will probably move most of the logic to Rust

Re: Moving from TypeScript to Rust / WebAssembly

#116

Post by pjmlp »

quickthrower2 wrote: post #111
pjmlp wrote: post #81

Earlier quoted context omitted.

Having ridden the 90's .com startup wave with an in-house application server written in a mix of Apache plugins and Tcl, I learned the hard way to never again rely on anything that doesn't bring a JIT or AOT compiler to the party.

What's the hard lesson? Performance? You have more power these days. The bottleneck won't be the interpreter.

Performance yes, there is always more power as long as the bank account is full, and even then it isn't enough when working at scale.

The amount of histories of porting code prove otherwise.

Note I am not pushing away dynamic languages, only those that don't have a JIT/AOT as part of their canonical implementation.

Common Lisp, Julia, JavaScript, PHP (7 and later) are all invited to the party.

Meanwhile maybe JRuby or PyPy will eventually get more community love, instead of being the black swans.

Re: Moving from TypeScript to Rust / WebAssembly

#117

Post by chjj »

daninet wrote: post #109
chjj wrote: post #46

> webassembly is faster than javascript Everyone says this, but I would dispute it as misleading in a lot of cases. I've been experimenting a lot with wasm lately. Yes, it is faster than javascript, but not by all that much. It's the speed of generic 32 bit C. It leaves a lot to be desired in the way of performance. My crypto library, when compiled to web assembly, is maybe 2-3x the speed of the equivalent javascript…

I also have a WASM crypto library, focused on hashing algorithms: https://www.npmjs.com/package/hash-wasm#benchmark I was able to archive 10x-60x speedups compared to the performance of most popular JS-only implementations. You can make your own measurements here: https://csb-9b6mf.daninet.now.sh/

Yeah, hashing in WASM seems to be fine in terms of speed, though 60x faster does still sound surprising to me. Hashes with 32 bit words (e.g. sha256) can be optimized fairly well in javascript due to the SMI optimization in engines like v8. I should play around with hashing more.

I was in particular benchmarking ECC, which is much harder to optimize in JS (and in general).

Code is here:

JS: https://github.com/bcoin-org/bcrypto/tree/master/lib/js

C: https://github.com/bcoin-org/libtorsion

To benchmark:

    $ git clone https://github.com/bcoin-org/bcrypto
    $ cd bcrypto
    $ npm install
    $ node bench/ec.js -f 'secp256k1 verify' -B js

    $ git clone https://github.com/bcoin-org/libtorsion
    $ cd libtorsion
    $ cmake . && make
    $ ./torsion_bench
    $ make -f Makefile.wasi SDK=/path/to/wasi-sdk
    $ ./scripts/run-wasi.sh torsion_bench.wasm ecdsa

Re: Moving from TypeScript to Rust / WebAssembly

#118

Post by cies »

cageface wrote: post #89
blub wrote: post #84

Earlier quoted context omitted.

They've "won" so far because static types languages were cumbersome and unpleasant to use, but this is changing and dynamic languages are learning some type tricks too. The issue here is with Rust: its strengths are mostly irrelevant for the web and its weaknesses (particularly slow development compared to the competition because of having to pacify the type checker) are really important. Op is painstakingly beating…

Exactly. The frameworks aren't there yet but I think Typescript is pretty much ideal for web dev. We're still using dynamic languages for web dev for mostly legacy reasons now.

Not sure if "ideal" is a good choice of word here. We dont know what's still coming. It surely has some flaws (many inherited from JS). There is stuff like ReasonML/Elm/PureScript that seems more ideal to me from a pure language (not eco sys, job/talent market, etc) perspective.

Re: Moving from TypeScript to Rust / WebAssembly

#119

Post by Karrot_Kream »

drewm1980 wrote: post #76
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#.

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 doesn't change the reality of allocation though. Programmers in languages like C++ and Rust choose when and where to allocate memory, and if there's one thing we know about performant code, it's that we shouldn't be allocating and deallocating repeatedly. Nothing about lifetimes helps or hurts about this programming model. Lifetimes (Rust) and RAII (C++) are just semantic models to help reign in the cognitive load of memory allocation.
Post reply on HN