Moving from TypeScript to Rust / WebAssembly
21–30 of 428 posts
Re: Moving from TypeScript to Rust / WebAssembly
#22I 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…
It's funny you mention enums, there was just another thread last week where I brought up how crazy it is that sum types (Rust enums) and pattern matching have been around since the 70s but have largely been limited to the FP languages. After extensively using Rust for ~3 years now, I don't ever want to use a language without sum types - you can write incredibly expressive and concise code with them.
The other major productivity boost for me is the ability to compose and chain Iterators and mix those with collection types.
Re: Moving from TypeScript to Rust / WebAssembly
#23> Webassembly Is Faster Than Javascript Just curious, how's the OP measuring this? Also, would be very interested in the stack - is OP using Yew/Seed/etc or server rendered pages with Rust?
About measurements, I just whipped up a quick benchmark comparing the JavaScript state updates with the WASM version. You do pay a cost crossing the JS / WASM boundary, but the WASM version is faster overall for my application. I'm not particularly concerned with performance at the moment (it was just a nice to have).
Re: Moving from TypeScript to Rust / WebAssembly
#24> Webassembly Is Faster Than Javascript Just curious, how's the OP measuring this? Also, would be very interested in the stack - is OP using Yew/Seed/etc or server rendered pages with Rust?
Re: Moving from TypeScript to Rust / WebAssembly
#25As long as you use a language with a good, static type system, I don't care so much what you use. TypeScript or Rust, for all I care you can transpile Haskell into JavaScript if you feel adventurous. But don't use a dynamically typed language as the source language for anything that is supposed to be more than a simple script.
I will say from exp. that @anyfoo has a point. In the end, even webapp backends are clients, worker nodes within a much larger system infra. Anything that has to do with data that isn't a pass-through entity ideally should be both strongly and statically typed.
Re: Moving from TypeScript to Rust / WebAssembly
#26Earlier quoted context omitted.
Depends on what you're optimizing for. If you want memory efficiency and near-native speeds, then you need WebAssembly. And Rust is a fantastic source language to compile to WebAssembly because of its memory safety.
Mind explaining a bit more here why Rust is a particularly good language to compile to wasm? Why does memory safety help here? Asking out of ignorance!
- It's low level like C and C++ so it maps cleanly onto WASM
- In your average Rust project, all dependencies are already built from source, greatly increasing the likelihood all your dependencies can be built for WASM
- Already using LLVM as the compiler backend made WASM targeting a lot less work than for languages that need to do that work from scratch
- Probably most importantly, a lot of developers involved in core rustc development were motivated to get Rust working on WASM
At least that's my perception for how Rust became such a prominent language for WASM development early on
Re: Moving from TypeScript to Rust / WebAssembly
#27As long as you use a language with a good, static type system, I don't care so much what you use. TypeScript or Rust, for all I care you can transpile Haskell into JavaScript if you feel adventurous. But don't use a dynamically typed language as the source language for anything that is supposed to be more than a simple script.
Re: Moving from TypeScript to Rust / WebAssembly
#28As long as you use a language with a good, static type system, I don't care so much what you use. TypeScript or Rust, for all I care you can transpile Haskell into JavaScript if you feel adventurous. But don't use a dynamically typed language as the source language for anything that is supposed to be more than a simple script.
Python folks with their strong + dynamic typing: (O.O') I will say from exp. that @anyfoo has a point. In the end, even webapp backends are clients, worker nodes within a much larger system infra. Anything that has to do with data that isn't a pass-through entity ideally should be both strongly and statically typed.
Re: Moving from TypeScript to Rust / WebAssembly
#29The 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 generally isn't a wide open road. It's a lot of little turns and alleys and special cases. Driving Rust in web dev is a lot of accelerating only to screech to a halt. I wrote a backend API for a side project in Rust. And true to what I said, Rust handled like a dream. But I didn't need the power. I spent most of my time screeching to a halt worrying about the plumbing between the various immature Rust libraries. And that's on the backend, which is way more mature compared to the frontend Rust libraries.
Judging by this post, OP managed to find a great open road in web dev to use Rust. I only wish I could find one as worthwhile.
Re: Moving from TypeScript to Rust / WebAssembly
#30This 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" type. The only other situation I have run into this in practice with TypeScript is when I'm using a library that has slightly misdefined types.