Moving from TypeScript to Rust / WebAssembly • Hacker News Board

Re: Moving from TypeScript to Rust / WebAssembly

#151

Post by pjmlp » Thu, Jul 09, 2020, 8:02 AM UTC

AbuAssar wrote: post #130

pjmlp wrote: post #81

Earlier quoted context omitted.

Having ridden the 90's .com startup wave with an in-house application server written in a mix of Apache plugins and Tcl, I learned the hard way to never again rely on anything that doesn't bring a JIT or AOT compiler to the party.

I’m interested in knowing more about your story. Would you please take the time to tell us more about it?

Not much to publicly tell.

Portuguese startup based on our own version of AOLserver, based on the same principles of Apache plugins + Tcl + C, basically Rails before it was even an idea.

We got acquired, by another bigger Portuguese company (Easyphone), which alongside another acquisitions became Altitude Software.

Our stack was used to some of their products serving multiple top tier companies in Portugal, we created an IDE for our tools, written in VB.

Supported all major UNIX flavours and Windows NT/2000.

Eventually scale problems happened and we were looking how to tackle them while avoiding rewriting everything in C, as MSFT partner we got invited to try out .NET pre-public announcement, so we decided it was a good opportunity to rewrite our product in this new .NET thing.

Some of the team members eventually took all these lessons and founded OutSystems.

Re: Moving from TypeScript to Rust / WebAssembly

#152

Post by entha_saava » Thu, Jul 09, 2020, 8:03 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 all the "Rust is as productive as X" and "If your data structure/logic won't work in rust, it was bad design" bullshit the silent majority of us are accustomed to see on HN..

Re: Moving from TypeScript to Rust / WebAssembly

#153

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

echelon wrote: post #16

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.

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

> and it's silly to dismiss because you think people are being hipsters or something.

Ah yes. If you think rust is bad, you are bad and you should feel bad. If your business logic requires little interlinked data structures or something else that rust doesn't allow, your business logic itself is at fault, your business is at fault, YOU are at fault, and you should verify your life integrity with algebraic data type in rust. Rust is more productive than Go or Python or Java or anything because if crab god yells at you you must have wrong design and you don't have any taste and you are std::real::life::programmer::stupid and you should #[feel(stupid)].

Re: Moving from TypeScript to Rust / WebAssembly

#154

Post by afiori » Thu, Jul 09, 2020, 8:10 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…

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. (similar to how executors work for futures)

Re: Moving from TypeScript to Rust / WebAssembly

#155

Post by adrianN » Thu, Jul 09, 2020, 8:15 AM UTC

drewm1980 wrote: post #76

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

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.

Re: Moving from TypeScript to Rust / WebAssembly

#156

Post by [deleted] » Thu, Jul 09, 2020, 8:16 AM UTC

irjustin wrote: post #144

friendzis wrote: post #135

Earlier quoted context omitted.

I think you get it backwards. Things are disjointed, loosely coupled because highly dynamic languages have won. The flexibility of dynamic languages, which can be great when working around dynamic corner cases, does not force developers into fixed, well-defined contracts keeping everything loose and disjoint. PHP is highly to blame. PHP, being a scripting language, is easy to deploy and keeps chugging along at all co…

I agree with both of you in that I don't think the direction of the origin really matters. The problem is when dealing with other teams/products/api's it's a mess. Varying standards, varying strictness, corner cases everywhere. There are plenty of JAVA, ASP.Net APIs that are absolute nightmares to integrate with despite being strictly typed beginnings. If you have a highly federated space, you control everything and…

[deleted]

Re: Moving from TypeScript to Rust / WebAssembly

#157

Post by raxxorrax » Thu, Jul 09, 2020, 8:20 AM UTC

friendzis wrote: post #135

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 think you get it backwards. Things are disjointed, loosely coupled because highly dynamic languages have won. The flexibility of dynamic languages, which can be great when working around dynamic corner cases, does not force developers into fixed, well-defined contracts keeping everything loose and disjoint. PHP is highly to blame. PHP, being a scripting language, is easy to deploy and keeps chugging along at all co…

If have seen horrible javascript, but I have also seen horrible type-safe examples. It is always a compromise between errors, readability and productivity.

Attaching text in form of a script anywhere in the DOM can be abused, but it is also insanely practical. I don't think Javascript is too horrible. I think the whole toolchain to get minimized and bundled JS is. That is why I am wary of TypeScript. Yes, I see its benefits, but I don't like cross-compiling if I can just not do it.

Given, I am no web developer and my "projects" on the web are tiny. I completely understand someone who likes to take the increased effort to use TypeScript, especially if your project isn't just making a text blink. If it reaches a certain size, I would probaly look into it too.

Webassembly looks interesting, but will take some time to establish itself. There are also disadvantages to that, since it could reduce the openness of the web. All the tracking we are subjected to could only be inspected by network traffic instead of looking into the source.

Re: Moving from TypeScript to Rust / WebAssembly

#158

Post by brabel » Thu, Jul 09, 2020, 8:21 AM UTC

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…

You can't judge the performance of WASM solely based on experiments you made using AssemblyScript (a TypeScript subset that compiles directly to WASM). As WASM is meant to be a low level compiler target, a proper comparison would be with binaries produced by the Rust or C compilers that don't rely on a specific GC implementation.

Re: Moving from TypeScript to Rust / WebAssembly

#159

Post by v_pragma » Thu, Jul 09, 2020, 8:25 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...

Unfortunately, no, it's a commercial closed-source project. I profiled both JS and WA versions, the hottest methods took basically the same amount of time in both versions, except that WA build additionally spend ~25% of all time in __retain or something like that.

Re: Moving from TypeScript to Rust / WebAssembly

#160

Post by hombre_fatal » Thu, Jul 09, 2020, 8:28 AM UTC

lmm wrote: post #71

hombre_fatal wrote: post #53

Earlier quoted context omitted.

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

It's not any better if business trade-offs make another decision better. You don't have "all things equal" trade-offs in the real world.

Want an easy concrete example? You and your cofounder have 10 years of Ruby experience and investors/customers who want a product yesterday. Or the deliverable that makes most sense is a PHP script that users can drag into CPanel because that's your customer base.

The tinkerer inside you always wants to try new things and convince you that some greener tech on the other side of the fence are going to make the difference. It's usually just procrastination from the actual hard stuff: building things people want, today.