Moving from TypeScript to Rust / WebAssembly • Hacker News Board

Re: Moving from TypeScript to Rust / WebAssembly

#191

Post by zozbot234 » Thu, Jul 09, 2020, 9:27 AM UTC

codemac wrote: post #78

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

As a complete noob to rust, I found attempting to manage a memory pool that is handed out per request to cause all kinds of borrow checking headaches. My bet is people choose to allocate heavily rather than figure out how to share memory correctly with Rust. I need to learn more rust to get a hang of it so I don't allocate so much. Are there any rust folks who have a great "list of memory management models for rust"?

Rust does not yet have local custom allocators ala C++. (You can change the global allocator, but this doesn't help the "memory arena" use case.) The feature is very much on the roadmap, though.

Re: Moving from TypeScript to Rust / WebAssembly

#192

Post by wdb » Thu, Jul 09, 2020, 9:29 AM UTC

I am actually converting a work project from TypeScript to Swift as it makes the writing of code more fun and then just leverage either for the backend application or as part of web application via WebAssembly. Main reason it's easy to share the code with different targets (win32, arm, WebAssembly, osx) so its highly reusable. And I like Swift more as a language compared to Rust

Really enjoying it so far.

Re: Moving from TypeScript to Rust / WebAssembly

#193

Post by MaxBarraclough » Thu, Jul 09, 2020, 9:30 AM UTC

csomar wrote: post #188

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…

It's still a significant upgrade over JavaScript. I'm developing a web app with the Backend in Rust and Front-end in Vuejs/JavaScript. Sure Rust was slower to develop, but it doesn't throw errors like 'val in undefined' and then I have to go debugging where I check for the value of val. You do that beforehand on Rust and that avoid a whole class of problems. JavaScript is cheaper to get started but becomes way more e…

You're referring to Rust's static type system. What do you make of TypeScript?

Re: Moving from TypeScript to Rust / WebAssembly

#194

Post by benjamin-lee » Thu, Jul 09, 2020, 9:31 AM UTC

maxgraey wrote: post #132

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

I'm not the OP but I can confirm in my own project, we found about a 10x performance gap between AssemblyScript and TypeScript. In essence, we're working on a rewrite of DNAVisualization.org[1][2], a serverless web tool for the interactive inspection of raw DNA sequences. We hoped that WASM would give us a performance boost but have been generally disappointed with both the performance and the amount of complexity involved in getting the tooling to work.

We did do a benchmark[3] and, unless we made an error (likely, given that all of us are new to WASM), found that JS was much faster for our simple algorithms. WASM had the approximate performance of our original pure Python implementation[4], so not great.

[1]: https://dnavisualization.org [2]: https://academic.oup.com/nar/article/47/W1/W20/5512090 [3]: https://github.com/Lab41/dnaviz/tree/benchmarks/benchmarks/a.... [4]: https://github.com/Lab41/squiggle

Re: Moving from TypeScript to Rust / WebAssembly

#195

Post by afarrell » Thu, Jul 09, 2020, 9:32 AM UTC

entha_saava wrote: post #181

afarrell wrote: post #172

Earlier quoted context omitted.

A lot of it is affordances. Every function signature is a user interface for your fellow programmer. And if you are used to poorly-designed UI, you will expect poorly-designed UI from yourself.

Less testing, Documentation, Guarding against typos, better IDE support, better performance; But there is a whole new generation of web developers who don't bother to learn algorithms or low level programming, and just churn out code with that hot new framework. That kind of programmers are also the ones that choose a technology because "it looks easier". The world would be nice if management people understood not al…

> Less testing

Why?

Re: Moving from TypeScript to Rust / WebAssembly

#196

Post by zozbot234 » Thu, Jul 09, 2020, 9:32 AM UTC

adrianN wrote: post #155

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.

I doubt that you'll write a large Rust program without relying on refcounting at least for some of your objects. Refcounting is not fundamentally different than a GC.

Reference counting is a kind of garbage collection (taken broadly), but it's quite different from tracing GC.

Re: Moving from TypeScript to Rust / WebAssembly

#197

Post by imtringued » Thu, Jul 09, 2020, 9:38 AM UTC

blub wrote: post #92

zenhack wrote: post #88

Earlier quoted context omitted.

I think a lot of the best the best things in Rust don't really have anything to do with low level programming per-se. And I find that for most applications, even with all of the extra goodness, the lack of a GC totally craters productivity. Its not because I'm fighting the borrow checker -- I got the hang of it pretty quick. But it means that every API is complicated by the need to think about lifetimes and ownership…

What's puzzling is why a language designed for memory safety and low-level control and performance is even being considered for web development where they had the former all along and they generally don't care about the latter. Or if they do they use Java, Go or throw a couple dozen more servers at the problem.

With Java you only need to throw more RAM at the server. The performance is perfectly acceptable compared to something like Python or Ruby. You can always squeeze out more performance with Rust but the primary benefit is the lack of a GC.

Re: Moving from TypeScript to Rust / WebAssembly

#198

Post by lmm » Thu, Jul 09, 2020, 9:38 AM UTC

tigershark wrote: post #142

lmm wrote: post #95

Earlier quoted context omitted.

By what definition? Haskell and Scala both have the complete ML featureset (in particular they have sum types and full pattern matching; they're also part of the small group of languages that has typeclasses, which were originally invented for Standard ML) and are on record as being heavily influenced by ML languages (via Miranda in the case of Haskell).

https://en.m.wikipedia.org/wiki/ML_(programming_language) “Today there are several languages in the ML family; the three most prominent are Standard ML (SML), OCaml and F#. Ideas from ML have influenced numerous other languages, like Haskell, Cyclone, Nemerle, ATS,[citation needed] and Elm.[3]” If you know F#, OCAML, Haskell and scala you can see that the first two have an extremely similar syntax to ML while for the…

If you actually click down to [3] in your own link it says '"these languages" is referring to Haskell, OCaml, SML, and F#'.

Re: Moving from TypeScript to Rust / WebAssembly

#199

Post by nailer » Thu, Jul 09, 2020, 9:39 AM UTC

> For example, the data might contain additional fields or even incorrect values for declared types.

I understand 'incorrect values' (this is true, see https://github.com/Microsoft/TypeScript/issues/15480) .

But TypeScript definitely doesn't like adding additional fields. Right now I'm working on TypeScript, added the new Fastify raw body plugin, and forgot to extend our custom Request type. The error is:

  Property 'rawBody' does not exist on type 'CustomRequest'.ts(2339)

Ie, we can't just add a field.

Appreciate I may be wrong, or we have different definitions here, but I'd like to discuss.

Re: Moving from TypeScript to Rust / WebAssembly

#200

Post by zozbot234 » Thu, Jul 09, 2020, 9:44 AM UTC

zenhack wrote: post #88

echelon wrote: post #16

Earlier quoted context omitted.

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

I think a lot of the best the best things in Rust don't really have anything to do with low level programming per-se. And I find that for most applications, even with all of the extra goodness, the lack of a GC totally craters productivity. Its not because I'm fighting the borrow checker -- I got the hang of it pretty quick. But it means that every API is complicated by the need to think about lifetimes and ownership…

> But it means that every API is complicated by the need to think about lifetimes and ownership, having to think about different types of smart pointer, etc. It means you have to manage all of these silly little details which for most applications are pretty irrelevant.

Rust gives you the features to auto-manage these "silly little details", you simply have to opt-in to them with a bit of boilerplate. Stuff like Rc> and the like is there for a reason.