Moving from TypeScript to Rust / WebAssembly • Hacker News Board

Re: Moving from TypeScript to Rust / WebAssembly

#201

Post by Dowwie » Thu, Jul 09, 2020, 9:46 AM UTC

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…

The first exposure is the hardest part. It's not the kind of language that one can just pick up and use effectively without first understanding the fundamentals, especially if using an async runtime. The investment is worthwhile, though.

Re: Moving from TypeScript to Rust / WebAssembly

#202

Post by zozbot234 » Thu, Jul 09, 2020, 9:47 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.

A bit offtopic for HN, but that's a really nice username. (Just looking at that, I can definitely see how you'd find those things puzzling!)

Re: Moving from TypeScript to Rust / WebAssembly

#203

Post by entha_saava » Thu, Jul 09, 2020, 9:49 AM UTC

afarrell wrote: post #195

entha_saava wrote: post #181

Earlier quoted context omitted.

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?

For example functions only take objects of supported types. Many invariants are verifiable at compile time. Especially when you have generics, structural typing and ADTs, the expressiveness is pretty good.

Re: Moving from TypeScript to Rust / WebAssembly

#204

Post by masklinn » Thu, Jul 09, 2020, 9:49 AM UTC

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 really nails why languages like PHP and Ruby have won out over static typed

It really doesn't.

Languages like PHP and Ruby "have won out" over statically typed languages because the representatives of statically typed languages at the time were Java and C++, both of which were bad (they still are, but they were): verbose, difficult (and verbose) to leverage for type-safety, missing a bunch of tremendously useful pieces (type-safe enums to say nothing of full-blown sum types), nulls galore, …

As a result, the gain in expressiveness and terseness (even without trying to code-golf) of dynamically typed languages was huge, the loss in type-safety was very limited given the choice was "avoid leveraging the type system" or "write reams of code because the language is shit", and the fast increase in compute performances more than compensated for the language's loss in efficiency.

And that's before talking about the horror show that Java's web frameworks ecosystem was circa 2006.

> Languages that tend to work well with it are those that are highly flexible around the corner cases of these technologies, and allow you to quickly iterate through the process of gluing them together.

That's really complete hogwash outside of the client, which isn't what we're talking about here since neither php nor ruby run there. On the server you have clear interfaces between "inside" and "outside", and there's no inflexibility to properly taking care of cleaning up your crap at the edges. Quite the opposite, really.

Re: Moving from TypeScript to Rust / WebAssembly

#205

Post by entha_saava » Thu, Jul 09, 2020, 9:52 AM UTC

afarrell wrote: post #190

entha_saava wrote: post #181

Earlier quoted context omitted.

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…

> the 10x programmer is not a myth You are right that quality of programmer skill and productivity has high variance, but the way people talked about the "10x programmer" was a vague vision that people pasted their ideas and personal bugaboos onto. So people got into increasingly-heated arguments and talked past each other. When we create social concepts, we need to strive for something like falsifiability -- somethi…

True. That was a vague notion. I think Joel Spolsky's "Hitting the high notes" summarized it better.

Re: Moving from TypeScript to Rust / WebAssembly

#206

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

hombre_fatal wrote: post #32

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…

When you're writing synchronous, single-threaded code like, say, a binary file parser or even an HTML scraper with blocking APIs, Rust is 1:1 with high level languages, and usually better. Where Rust diverges is when you're doing async or multithreaded things with complicate lifetimes. Getting things right from the start instead of solving them JIT as runtime issues pop up in production over the course of the year is…

> But even after using Rust for three years, I sometimes feel like I'm one requirement-change away from a problem I can't solve myself in Rust where I could solve it in a couple hours in another language.

Rust does have these sorts of issues wrt. managing highly generic graph-like data, possibly with cycles. That's where tracing GC actually shines, and where writing that whole portion separately in something like Go might be the right answer.

Re: Moving from TypeScript to Rust / WebAssembly

#207

Post by giantDinosaur » Thu, Jul 09, 2020, 10:04 AM UTC

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…

I'm not sure this is really true - the subtleties of HTTP are not best handled with dynamic languages, and the actual HTTP API is fairly simple for most web app development. The areas with the most complexity related to the web, itself, are usually do with servers, concurrency, etc - precisely where these languages tend to fall apart.

Re: Moving from TypeScript to Rust / WebAssembly

#208

Post by cygx » Thu, Jul 09, 2020, 10:10 AM UTC

masklinn wrote: post #204

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…

> This really nails why languages like PHP and Ruby have won out over static typed It really doesn't. Languages like PHP and Ruby "have won out" over statically typed languages because the representatives of statically typed languages at the time were Java and C++, both of which were bad (they still are, but they were): verbose, difficult (and verbose) to leverage for type-safety, missing a bunch of tremendously usef…

because the representatives of statically typed languages at the time were Java and C++

And Pascal, Ada, Haskell, Eiffel, Standard ML, ...

Re: Moving from TypeScript to Rust / WebAssembly

#209

Post by pas » Thu, Jul 09, 2020, 10:10 AM UTC

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

The short answer is that because async is not done yet in Rust.

The long answer probably includes GATs (generic associated types), and the even longer answer starts with the amazing work that Nico et al. does to reinvent the internals of the Rust type checker. (Basically - if I remember correctly - the compiler team is currently refactoring big parts of rustc, to librarify the type checker, and replace it with a PROLOG-ish library called "chalk", which is able to prove more things, so it allows better handling of GATs, so it allows better handling of async, where you get "impl Future"-s everywhere.

But also somewhere there is that the ergonomics of async/.await are still not very much in progress too. With better error messages people will be able to forego Box-ing and figure out what to use instead, and only heap allocate where they must.

It's possible to write low-level async code with hand rolled-polled Futures, and push/manage as much stuff on the stack as possible. But ... that takes time, and performance is already "good enough". (And/or probably there are bigger gains in performance in other areas, such as scheduling.)

And, finally, boxing helps with compile times. (Because it's basically trivial for the compile to prove that a heap allocated simple trait object behaves well compared to a stack allocated concrete, but usually highly complex (plus unnameable) type.)

Re: Moving from TypeScript to Rust / WebAssembly

#210

Post by jashmatthews » Thu, Jul 09, 2020, 10:14 AM UTC

uryga wrote: post #185

CraigJPerry wrote: post #150

Earlier quoted context omitted.

Applying a schema doesn’t fix an architecture problem. Describing those fixed well defined contracts on top of the architurally absurd stack that is TCP/DNS/TLS/HTTP/Ajax/Dom/JS engine/Server side graphql/rpc/rest / database... doesnt by you anything but slower iteration speed and an unwieldy schema. These components don’t have the same impedance, the same flavour to their design. Necessarily their schema would be a…

> Also, what stops something like [defining add as subtraction] cmon... "it doesn't guard you against every logic error under the sun" isn't a great argument

There's no strong evidence that static typing helps reduce application logic bugs https://danluu.com/empirical-pl/

Under the same pressures it's pretty likely that the same teams that deploy dynamic language code to production and get an unexpected nil deploy statically typed code to production which unwraps an unexpected None and throws exceptions or panics.