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

101–110 of 428 posts

Re: Moving from TypeScript to Rust / WebAssembly

#101

Post by zelphirkalt »

chjj wrote: post #63
ben-schaaf wrote: post #55

Earlier quoted context omitted.

Have you tried with firefox? Last I heard they've got far and away the fastest wasm implementation.

No. I've just been building with the WASI SDK and running the resulting binary with a small node.js wrapper script. So, I've only tested v8's WASM implementation so far. Does firefox have a headless mode, a standalone implementation, or some CLI tool I can use to run a WASM binary? Running stuff in the browser is cumbersome.

I think there should be a headless mode. For exampl e you can run unit tests using the gecko driver (?) without firefox showing up, running it as some process to perform the testing steps and give results.

Re: Moving from TypeScript to Rust / WebAssembly

#102

Post by filleduchaos »

lacker wrote: post #30

[TypeScript] does not actually ensure that the data you are manipulating corresponds to the type that you have declared to represent it. For example, the data might contain additional fields or even incorrect values for declared types. This is only a problem if you are mixing untyped code with typed code, isn't it? Like when you are parsing JSON, you need to do typechecking right then, rather than just using an "any"…

> This is only a problem if you are mixing untyped code with typed code, isn't it?

I find it a bit strange that people talk about this as "only a problem", as though it was some weird niche edge case and not an ever-present issue. The written-in-plain-JS ecosystem completely dwarfs the written-in-TypeScript one; unless you're doing something rather trivial you're quite likely to end up depending on a library that barely had the shape of its objects in mind during development, with typings (if they're even present) that were contributed by someone that's almost definitely not the actual library author.

Of course, if you're competent enough you can correct typings and always remember to run runtime checks on data that doesn't come from you and so on. But it's too easy for a beginner to fall into traps like mishandling data that comes from a dependency (especially when it's buggy/ostensibly has typings) - in my opinion, there should be a first-party compiler/linter option to enforce checks on any `any`.

Re: Moving from TypeScript to Rust / WebAssembly

#103

Post by v_pragma »

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, disabled array boundary checks, disabled GC for 70% of classes) and still end up with a binary that is 30% slower than the original JS code. It was mostly AssemblyScript's GC, which was extremely slow (and probably still is), and with GC completely disabled (which is an unfair advantage for WA) performance was almost the same.

Re: Moving from TypeScript to Rust / WebAssembly

#104

Post by truth_seeker »

In general, I think the significant improvement in Speed in case of WebAssembly binaries will be largely due to SIMD support. But performance gap between JS and WebAssembly is not at all deciding factor unless you are creating a high quality Games. There are lot of online games with low to medium graphics quality created using 2D canvas or 2D/3D WebGL libraries which run just fine on modern web browsers.

Most developers, at least in my experience see just plain Array and JSON. If they get themselves familiar with API like WeakRef (WeakSet/WeakMap), ArrayBuffer along with DataView and Various Typed Arrays (Int8, Int16, Int32, Uint8,Uint16,Uint32, Uint8Clamped and likewise for Float and BigInt) they can write Garbage heap friendly and more computation focused code.

Besides that, strictly speaking for standard web application development, JS ecosystem of libraries and frameworks are miles ahead for handling various kinds of UX/UI journey scenarios. Developer tools in the browser to do various kinds of performance inspection and profiling of the JS code.

I wonder why JS engines (like V8 for example) rely highly on Scalar instructions ? There is lot of scope to apply auto-vectorization and generate SSE, AVX, NEON (for ARM) instructions. If they implement this or at least provide some API like SIMD.js (one they abandoned in the past), it will make WebAssembly close to redundant unless you hate JS or other PLs which transpiles to JS.

Re: Moving from TypeScript to Rust / WebAssembly

#105

Post by loxs »

I will only nitpick on the part about TypeScript not being type-safe enough, where extra fields are possible or wrong types can be sent over the wire.

io-ts [0] completely solves this issue, to the point where I don't think it's less type-safe than Rust in any practical manner. I've been writing apps in TS this way for the past year and I have quite a large codebase in production. The errors you mention do not happen.

[0] - https://github.com/gcanti/io-ts

Re: Moving from TypeScript to Rust / WebAssembly

#106

Post by amitport »

nicolodavis wrote: post #99
amitport wrote: post #98

Hi Nicolo, Here are my two (or more) cents: 1 - Javascript is fast enough for your use case. No one will notice the difference in a board game website. 2 - AI should probably be implemented in python anyway. As ugly as python can be, you shouldn't fight the world; there are too many free advanced AI algo implementations in python out there. 3 - Regarding "Limitations of TypeScript" (strict typing / data validation /…

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-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/

Re: Moving from TypeScript to Rust / WebAssembly

#107

Post by kbenson »

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…

> Yes, it is faster than javascript, but not by all that much. ... My crypto library, when compiled to web assembly, is maybe 2-3x the speed of the equivalent javascript code.

2-3x may not be the 15-16x you see in native code, but it's still a massive speedup in already optimized code, and is likely enough to make a bunch of applications that weren't quite feasible to do in on the web now feasible.

Re: Moving from TypeScript to Rust / WebAssembly

#108

Post by nicolodavis »

loxs wrote: post #105

I will only nitpick on the part about TypeScript not being type-safe enough, where extra fields are possible or wrong types can be sent over the wire. io-ts [0] completely solves this issue, to the point where I don't think it's less type-safe than Rust in any practical manner. I've been writing apps in TS this way for the past year and I have quite a large codebase in production. The errors you mention do not happen…

Thanks for the link! I'll look into this for my other TypeScript codebases.

Re: Moving from TypeScript to Rust / WebAssembly

#109

Post by daninet »

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/

Re: Moving from TypeScript to Rust / WebAssembly

#110

Post by quickthrower2 »

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…

This is probably true .... but watch out for Node with Typescript. You get that quite iteration, but with a decent amount of type safety most of the time, but with a drop down to the 'any' type for libraries that haven't written type definitions. I also use the existence of type definitions as a guide to how mature the library is :-), so that's a win win.
Post reply on HN