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

161–170 of 428 posts

Re: Moving from TypeScript to Rust / WebAssembly

#161

Post by davedx »

friendzis wrote: post #135
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…

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 co…

I completely disagree with this.

I work on a large C# platform that interops with a ton of vendor API's, the majority of which are also written in typed languages. The disjointed, loosely coupled nature of web systems is what causes problems. In particular, knowing what a "correct input" is to web systems is very difficult, where correct means:

1) Passes the API's immediate validation

2) Passes validation inside API's longer running processes

3) Passes business rules (it might be correct types, lengths etc, but fails anyway because of an incorrect combination of API calls)

Some of our vendors use Elixir, some use PHP, many use C# or Java. I really don't notice any significant difference between them on that account. The issues are all down to the complexity of the software and business requirements and that the whole thing is a giant distributed system.

Re: Moving from TypeScript to Rust / WebAssembly

#162

Post by v_pragma »

brabel wrote: post #158
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…

You can't judge the performance of WASM solely based on experiments you made using AssemblyScript (a TypeScript subset that compiles directly to WASM). As WASM is meant to be a low level compiler target, a proper comparison would be with binaries produced by the Rust or C compilers that don't rely on a specific GC implementation.

GC aside, I've inspected assembly code (.wast files) for top 10 hottest methods in my code, and it was pretty much perfect, Rust and C will probably end up with something similar. However, there was no performance improvements whatsoever, those methods performed similarly to their JS equivalents.

UPD: modern JS engines are extremely capable of optimizing stuff and they can probably come up with machine code similar to what Rust or C will produce given that you keep your code predictable and optimization-friendly.

Re: Moving from TypeScript to Rust / WebAssembly

#163

Post by ThePhysicist »

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…

They are also evolving though. I don't know about Ruby and PHP but in Python gradual typing via type annotations really makes projects much easier to maintain and develop these days. While "mypy" (the semi-official type checker tool) still has a long way to go in terms of library support it works really well and helped me to find many issues by analyzing the code, as opposed to running it and finding the issues via tests (or in production).

So I think typing has its merits and languages like Typescript really make development safer and code easier to understand, while still making it possible to write and interface with untyped code if necessary.

Re: Moving from TypeScript to Rust / WebAssembly

#164

Post by maxgraey »

v_pragma wrote: post #159
maxgraey wrote: post #132

Earlier quoted context omitted.

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

Unfortunately, no, it's a commercial closed-source project. I profiled both JS and WA versions, the hottest methods took basically the same amount of time in both versions, except that WA build additionally spend ~25% of all time in __retain or something like that.

Do you intensive use small objects like Vec3, Quaternion and etc? AS hasn't scalar replacement optimization pass yet which JavaScript definitely has. Also it will be much better after implementing tuple / records which depends on multi-value proposal for now. All this significantly reduce ARC / memory pressure. But my assumption it could be also wrong measurement. Most of people uses benchmark.js which also measure js wasm interop overhead which usually main bottleneck.

Re: Moving from TypeScript to Rust / WebAssembly

#165

Post by tluyben2 »

jes5199 wrote: post #143
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…

I’ve worked on several large Ruby codebases, and the thing is, the same qualities that make it easy to get a Ruby project up and working quickly make it a complete nightmare to maintain later. Its expressiveness and malleability mean that you can never really be sure that you understand how code is being used, and the complexity that emerges from a few years of that is incredibly overwhelming. Nowadays I would much r…

Exactly; I guess a lot of people just work on projects/jobs and then move on. Once you need to go back to systems you forgot about (things you wrote 5-10-15-20+ years ago), Ruby (in your example and indeed my experience) is a nightmare on speed. The (strange to me) idea that people have that their code won't be around that long, hits me in the face every time a client asks me to 'connect to something made by someone some time ago'; I go check it and it's almost always something php/RoR/(and lately node) built by someone that left years ago and no-one touched it since because it works. When you actually do touch it, ofcourse, it is completely out of date, nothing current works and because of the flexibility of these languages and systems things change way too fast (really unneeded API breaks in packages is something crazy to me; coming from Java, I expect people to keep things backward compatible, but nope; just toss it out!) (especially node npm and least of all PHP which is actually a joy to work with in this kind of spelonking as it is remarkably stable including it's (older) libraries) (and no, not everyone uses a framework with php 'nowadays'; I run into many PHP projects a few years old that are just plain php, more so than frameworks used and that actually does make it easier to jump as plain php still works from a decade ago after update). And then when you have it running on your laptop, it usually is full of these 'corner cases' (lazy programmer input/output handling I would call it) which don't age well (and often hides bugs).

On the other hand, running into Java or C# projects is hardly ever an issue; it's a lot of boiler plate (many (request/response/dto etc) models/entities and layers), but it's readable immediately and if it still runs, it means that all data is validated and I can trust it.

Re: Moving from TypeScript to Rust / WebAssembly

#166

Post by Longwelwind »

I spent the last 2 years making an online adaptation of a board game. I chose Typescript mainly because I was comfortable enough in this language and I don't regret this choice.

Typescript is, for me, the right balance between the strictness required to manage a mid-size codebase, and the looseness necessary to be productive (I definitely don't want to manage low-level things like memory when coding the gameplay of the board game).

On top of that, if your project is open-source, using JS/TS makes it more likely that someone can contribute to the project, compared to Rust, which has a higher learning curve.

Being able to easily share code between the client and the server is a big bonus too. The article points that with WebAssembly, it's possible to do it with any language, but I'm not sure it's stable enough to be used yet.

I'm thinking of making a library similar to boardgame.io (because I think there are some parts that could be done better), and I'll most probably keep Typescript for it.

Curious to see how using Rust for this will play out!

Re: Moving from TypeScript to Rust / WebAssembly

#167

Post by flohofwoe »

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…

If you allocate and free small memory chunks at high frequency in a non-GC language, then it's quite likely that similar code in a GC'ed language will come out faster. The point of manual memory management isn't that it is "automatically" faster than a GC, but that it gives you a lot of control to reduce the allocation frequency (e.g. by grouping many small items into few large allocations, or moving allocations out of the hot code path).

Also, async itself doesn't magically make code run faster (on the contrary), it just lets you (ideally) do something else instead of waiting for a blocking operation to complete, or at least give you the illusion of sequential control flow (unlike nested callbacks).

Re: Moving from TypeScript to Rust / WebAssembly

#168

Post by v_pragma »

maxgraey wrote: post #164
v_pragma wrote: post #159

Earlier quoted context omitted.

Unfortunately, no, it's a commercial closed-source project. I profiled both JS and WA versions, the hottest methods took basically the same amount of time in both versions, except that WA build additionally spend ~25% of all time in __retain or something like that.

Do you intensive use small objects like Vec3, Quaternion and etc? AS hasn't scalar replacement optimization pass yet which JavaScript definitely has. Also it will be much better after implementing tuple / records which depends on multi-value proposal for now. All this significantly reduce ARC / memory pressure. But my assumption it could be also wrong measurement. Most of people uses benchmark.js which also measure j…

> AS hasn't scalar replacement optimization pass yet which JavaScript definitely has. Also it will be much better after implementing tuple / records which depends on multi-value proposal for now.

Yes, I do use a lot of small objects. That's an interesting information, I'll keep an eye on multi-value proposal, thank you!

> Most of people uses benchmark.js which also measure js wasm interop overhead which usually main bottleneck.

Nope, I loaded all the data into WA module upon initialization and don't perform any additional synchronization between WA and JS afterwards (which is also kind of unfair advantage for WA).

Re: Moving from TypeScript to Rust / WebAssembly

#169

Post by Lorkki »

blub wrote: post #86
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.

It didn't figure them out at all, the programmer had to figure them out the hard way and then code them in so that the compiler understands them. GC is figuring out things mostly correctly and the programmer can focus on other things, at least until they hit a performance problem :)

For the most part, lifetime is inferred from scope, so there isn't anything special to figure out; objects live exactly for as long as you can see and use them. This also includes such things as lock handles, or references to refcounted objects.

Re: Moving from TypeScript to Rust / WebAssembly

#170

Post by DevoidSimo »

jes5199 wrote: post #143
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…

I’ve worked on several large Ruby codebases, and the thing is, the same qualities that make it easy to get a Ruby project up and working quickly make it a complete nightmare to maintain later. Its expressiveness and malleability mean that you can never really be sure that you understand how code is being used, and the complexity that emerges from a few years of that is incredibly overwhelming. Nowadays I would much r…

Agree here, admittedly I have no prior Ruby experience, but I've inherited a code base in Rails. There is so much magic that goes on implicitly. I end up jumping around everywhere to see why something unexpected is happening.
Post reply on HN