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

71–80 of 428 posts

Re: Moving from TypeScript to Rust / WebAssembly

#71

Post by lmm »

hombre_fatal wrote: post #53
anyfoo wrote: post #20

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

> But don't use This is just cargo-culting static typing: "If I avoid dynamic typing at all cost, the cargo crates will surely rain on down!" You'll find that picking a language is more of a business decision than the sort of technical static-vs-dynamic checkbox test you might use to pick the language of your next weekendware. This kind of absolutist rule of thumb is more flame bait than morsel of wisdom.

This is the fallacy of the grey. Yes, there are nuances and special circumstances, but the overwhelming majority of the time, static typing is simply better. That's one of a small handful of clear consensuses from the last 20-30 years of programming language evolution.

Re: Moving from TypeScript to Rust / WebAssembly

#72

Post by toastal »

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.

Why would you be disappointed? The author wanted more from the type system and didn't care if they were going to switch syntax. Seems like AssemblyScripts biggest 'selling point' is that it looks like TypeScript.

Re: Moving from TypeScript to Rust / WebAssembly

#73

Post by lmm »

yingw787 wrote: post #25
anyfoo wrote: post #20

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

Python has things that it calls "types" but they're not types according to the standard definition of the word (true types are associated with terms in a language, not with runtime values). And while a runtime error is far better than silent data corruption, it's a poor substitute for a build-time error.

Re: Moving from TypeScript to Rust / WebAssembly

#74

Post by zenhack »

apatheticonion wrote: post #51
harikb wrote: post #31

Alon Zakai[1] gave a good talk[2] on the current state of WebAssembly, particularly on the current state of performance 1. https://twitter.com/kripken 2. https://youtu.be/4ZMY3QE5t9o

I'm not certain exactly how LLVM works so I am not sure this is the right question to ask but - How does Web Assembly relate/compare to LLVM? Does LLVM solve the problem of a single binary that can be run portably?

They're trying to solve different problems. LLVM is trying to take care of most of the language-independent bits of writing a compiler, while wasm is a format for delivering code to browsers, with an eye towards being a good target for languages like C and making use of the existing JIT compilers in modern browsers.

LLVM as a toolchain provides backends for many target machines, so as a compiler author you can just emit LLVM IR and (mostly)automatically be able to compile for x86, arm, mips, etc... And they have a wasm backend too, so the technologies are complementary -- you can use LLVM to compile to wasm. LLVM will do a fair bit of optimization too. The intent with LLVM is not to provide a portable binary distribution format, but to allow different compiler frontends to all share the same compiler backend logic.

By contrast, with WASM the assumption is that by the time it gets to the browser the ahead-of-time compiler has already done a fair bit of optimization, so what a wasm compiler has to do is much simpler.

WASM is also designed for space efficiency, since the code will be shipped over the network, and safety -- LLVM has a C-like notion of undefined behavior (which the optimizer makes use of), but this would be wildly inappropriate for WASM due to security (and portability) concerns.

Re: Moving from TypeScript to Rust / WebAssembly

#75

Post by lmm »

melling wrote: post #2

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

ML family languages are so much more productive that that probably outweighs the costs of manual memory management. Rust will always be less productive than Haskell or Scala, but a language with a decent type system is going to have a huge advantage over JavaScript.

Re: Moving from TypeScript to Rust / WebAssembly

#76

Post by drewm1980 »

laurencerowe wrote: post #50
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…

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.

Re: Moving from TypeScript to Rust / WebAssembly

#78

Post by codemac »

laurencerowe wrote: post #50
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…

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"?

Re: Moving from TypeScript to Rust / WebAssembly

#80

Post by tigershark »

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

No, nominal types are extremely useful to ensure the correctness of your software. You can define a function to receive a FirstName and LastName instead of passing strings so you cannot accidentally mix up the parameters for example. There are several techniques to approximate nominal typing in typescript (https://medium.com/better-programming/nominal-typescript-eee... for example) and there is an open issue https://github.com/Microsoft/Typescript/issues/202 but it’s still not being considered for implementation as far as I remember.
Post reply on HN