Moving from TypeScript to Rust / WebAssembly • Hacker News Board

Re: Moving from TypeScript to Rust / WebAssembly

#171

Post by flohofwoe » Thu, Jul 09, 2020, 8:55 AM UTC

chjj wrote: post #46

> webassembly is faster than javascript Everyone says this, but I would dispute it as misleading in a lot of cases. I've been experimenting a lot with wasm lately. Yes, it is faster than javascript, but not by all that much. It's the speed of generic 32 bit C. It leaves a lot to be desired in the way of performance. My crypto library, when compiled to web assembly, is maybe 2-3x the speed of the equivalent javascript…

But 2-3x speedup over a well written Javascript version running in a modern Javascript engine is quite impressive, isn't it?

One thing that's often overlooked is that even though "idiomatic Javascript" using lots of objects and properties is fairly slow, it can be made fast (within 2x of native code compiled from 'generic' C code) by using the same tricks as asm.js (basically, use numbers and typed arrays for everything). But the resulting Javascript code will be much less readable and maintainable than cross-platform C code that's compiled to WASM.

Re: Moving from TypeScript to Rust / WebAssembly

#172

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

entha_saava wrote: post #141

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 ... Real reason is lowering the bar of entry, and that explains why web is horribly broken. The "bootcamp webshit" meme exists for a reason. That's not gatekeeping - lowering the bar to entry below a certain level leads to drastic decrease in quality.

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.

Re: Moving from TypeScript to Rust / WebAssembly

#173

Post by thepratt » Thu, Jul 09, 2020, 9:01 AM UTC

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…

Have you used sorbet on these codebases? I'd be curious if there'd be a benefit here in terms of maintainability.

Re: Moving from TypeScript to Rust / WebAssembly

#174

Post by throwaway8941 » Thu, Jul 09, 2020, 9:05 AM UTC

afiori wrote: post #154

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…

In a sense Rust could have tried to become a "tiered" language with 2 standard libraries: one low level that allows precise control on heap allocations (including custom allocators) and another higher level that relied on a GC. They could both be used at the same time. There would also be a compiler attribute #![no_gc] that make it so that you have to provide your own implementation of the GC runtime to use GC types.…

D tried that one. I don't know it very well, but I believe it turned out not to be a good idea.

Re: Moving from TypeScript to Rust / WebAssembly

#175

Post by rubber_duck » Thu, Jul 09, 2020, 9:08 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…

Won ? Ruby fell off a cliff once it got to a point where people had to maintain that shit in production - I'm currently working on a large mature RoR codebase and I'm switching jobs ASAP because it's incredibly painful to work with and feels like a dead end career wise - and I like the gig otherwise - good product and a decent team - but the technology is draining so much of my life energy on nonsense it's ridiculous. And the language is built for unmaintainability - standard functions being abbreviated to a single letter, 2 or 3 aliases for a single standard function (map/collect and such), Rails overriding the conventions of the language (! postfix). And then there's the architectural retardation of fat models, fat controllers and using mixins ("concerns") completely break encapsulation - all actively killing code reuse-

PHP has long been a meme and is mostly legacy stuff or bottom tier work.

Dynamic languages are adding static optional static typing because the value provided by tooling as the projects scales is undeniable.

It took ES6/TypeScript to drag JS out of the dump that it was with every library adding its own take on a class system - the maintainability jump from ES5 to TS is incomparable for anything larger than 1k LOC

Re: Moving from TypeScript to Rust / WebAssembly

#176

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

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

When getting external data, it always good to do a combination of casting and validating. There are a lot of good libraries to help you with this: https://github.com/moltar/typescript-runtime-type-benchmarks

Re: Moving from TypeScript to Rust / WebAssembly

#177

Post by jevgeni » Thu, Jul 09, 2020, 9:11 AM UTC

collyw wrote: post #147

mastrsushi wrote: post #131

Migrating a web app to a static typed system programming language is asinine. I swear these fanatics will do anything to say they rewrote it in Rust. This site is full of language-specific indulgent blog posts that are no more sophisticated than arguing over Pokemon cards. I want to see more posts about exciting new concepts like WebAssembly. So sick of hearing that the world would be a better place if the sky and tr…

Have an upvote from me, your attitude put a smile on my face, which is unusual for a comment on HN.

If we're are talking about Rust criticism it's pretty average in terms of tone and substance.

Re: Moving from TypeScript to Rust / WebAssembly

#178

Post by jevgeni » Thu, Jul 09, 2020, 9:12 AM UTC

mastrsushi wrote: post #131

Migrating a web app to a static typed system programming language is asinine. I swear these fanatics will do anything to say they rewrote it in Rust. This site is full of language-specific indulgent blog posts that are no more sophisticated than arguing over Pokemon cards. I want to see more posts about exciting new concepts like WebAssembly. So sick of hearing that the world would be a better place if the sky and tr…

> Migrating a web app to a static typed system programming language is asinine.

Why?

Re: Moving from TypeScript to Rust / WebAssembly

#179

Post by chjj » Thu, Jul 09, 2020, 9:13 AM UTC

jfkebwjsbx wrote: post #124

chjj wrote: post #46

> webassembly is faster than javascript Everyone says this, but I would dispute it as misleading in a lot of cases. I've been experimenting a lot with wasm lately. Yes, it is faster than javascript, but not by all that much. It's the speed of generic 32 bit C. It leaves a lot to be desired in the way of performance. My crypto library, when compiled to web assembly, is maybe 2-3x the speed of the equivalent javascript…

> maybe 2-3x the speed of the equivalent javascript code. That is an insane difference even if nowhere close to native code. Some engineering fields would be crazy with a 20% gain... 200% is huge!

I agree it still is signficant, but this is not how wasm is being touted. Look at wikipedia: https://en.wikipedia.org/wiki/WebAssembly#History

They even say asm.js is supposed to be "near-native code execution speeds". In my experience, it is no where close to native speed. People should avoid this kind of deceptive marketing.

Re: Moving from TypeScript to Rust / WebAssembly

#180

Post by Lio » Thu, Jul 09, 2020, 9:13 AM UTC

ThePhysicist wrote: post #163

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…

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

> I don't know about Ruby

Ruby is moving in the direction with the addition of Sorbet[1] for gradual typing. I have heard some discussion that this typing could become a formal part of Ruby 3.0.

1. https://sorbet.org/