Live data from Hacker News

Moving from TypeScript to Rust / WebAssembly

nicolodavis.com

401–410 of 428 posts

Re: Moving from TypeScript to Rust / WebAssembly

#401
post #125

Earlier quoted context omitted.

I'd be hard pressed if a backend in Rust gives the same perf as Kotlin/F#. Especially if you write the Rust with an async stack you will likely come out significantly faster than the other options: small binaries, short startup time, less memory usage, more throughput, slightly shorter request cycles, ... The only place that the langs you mention probably win is: learning curve (F# maybe not so much) a.k.a. getting l…

You forgot development times.

I broke it down into:

> a.k.a. getting language illiterate people up to speed, and compile times.

With equally skilled people I dont think these languages yield different dev speed, apart from the damage done by compile times.

Re: Moving from TypeScript to Rust / WebAssembly

#402
post #364

Earlier quoted context omitted.

As far as I'm aware, Pascal and Ada were still significant in the early 90s (ie when Python arrived). You're right that they where far less so when PHP entered the picture, but it's not as if they were dead (Borland Delphi and PHP 1.0 were realeased the same year).

> Pascal and Ada were still significant in the early 90s (ie when Python arrived). That is not the timeline we're talking about here. Dynamically typed languages started taking off at the turn of the millenium and really exploded in the second half of the aughts. Java didn't even exist in the early 90s.

But it's not as if the programming community collectively just forgot about these languages (and, as mentioned, Delphi and PHP are in fact contemporaries). The question remains, why did new dynamic languages rise, but already existing static languages decline? That requires an explanation.

Re: Moving from TypeScript to Rust / WebAssembly

#403
post #147

Earlier quoted context omitted.

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.

Spotted the rust wanker

Re: Moving from TypeScript to Rust / WebAssembly

#404

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?

[deleted]

Re: Moving from TypeScript to Rust / WebAssembly

#405

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?

Because it's redundant to have low level functionalities for building a web app.

Re: Moving from TypeScript to Rust / WebAssembly

#406
post #364

Earlier quoted context omitted.

Operative concept: representative . None of the language you mention had any sort of wide-spread visibility at that time, meaning they were not representative of the (overwhelming) majority experience with statically typed languages.

As far as I'm aware, Pascal and Ada were still significant in the early 90s (ie when Python arrived). You're right that they where far less so when PHP entered the picture, but it's not as if they were dead (Borland Delphi and PHP 1.0 were realeased the same year).

Yep Delphi 1.0 was launched in the mid-90s and had a good run for some time after that.

Re: Moving from TypeScript to Rust / WebAssembly

#407
post #371

Earlier quoted context omitted.

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…

> Nowadays I would much rather slog through ten times as much Java boilerplate, because later I’d expect that I could still refactor code without fearing that the whole thing would collapse around me Sure, but if you don't reach market fast enough you'll have no reason to slog through anything, period. Can you imagine writing something like Facebook using Rust? It's an almost ludicrous proposition. Static typing requ…

I think if you were starting today, you would build the app as a set of backend APIs connected to an array of front ends (apps, mobile web, desktop web, 3rd party, etc).

Building some or all of those backend APIs in Rust from day 1 would not be crazy, or less productive than any other language.

I think differences in proficiency drive bigger differences in productivity than inherent language differences.

So if you were starting today to build Facebook, using a language you are already effective with would matter more than which language you use (there are plenty of people out there for whom that could be Rust, or Haskell, or Ruby, or PHP, etc).

Re: Moving from TypeScript to Rust / WebAssembly

#408
post #393

Earlier quoted context omitted.

Javascript runtimes do fine with concurrent operations, but obviously are not intended for parallelism. On the WASM side: Does WASM support real threads yet? Otherwise moving to Rust wouldn't really help you? If it's just "WebWorker" like multiple runtimes, you might still pay serialization costs to move objects between workers.

No, JS runtimes don't do "fine" with concurrent operations, unless you are "waiting". If you are doing heavy processing, the whole service freezes. That's indeed the primary reason I need worker threads. Erlang's runtime does "fine" with its preemptive concurrency model, JS runtimes are a joke in this regard.

Have you tried async generator functions?

Re: Moving from TypeScript to Rust / WebAssembly

#409
post #350

Earlier quoted context omitted.

This is one nice thing about working at Google. We have C++ codebases that are 20 years old, but you'd never be able to tell because they are still continuously worked on and even if not there's a team of people at Google who constantly run company-wide refactorings and the like to modernize things.

Yeah, the problem is that the large majority of the world isn't Google, software isn't their main business, and their codebases are maintained by a continuous rotation of external contractors that are paid by the tickets that they get to implement.

Yep, and don't get me wrong. Stray out of the monorepo and into the wilds of various git hosted code bases at Google and you'll find code rotting in the fields, maintained to a far lower standard (IMHO).

Re: Moving from TypeScript to Rust / WebAssembly

#410

Earlier quoted context omitted.

I say this a lot, but if you are this irritated by Rails, then you ought to see the 20+ year old legacy C/C++ some of us get to work with ;)

I started on C++ back in VS6 days and I wrote tons of it when I was in to game dev and graphics programming - but I would not want to work on those systems and kinds of problems when I can get paid the same to work on higher level stuff - the tooling quality and slow iteration cycle when I'm really stuck on something leads to a lot of stress - I just want low stress dev environment where I focus on solving problems I…

Funny, after 10 years of Java and other high level languages I was very happy to go work on C++ at a lower level and have been pushing myself lower down the stack as I go.

C++ these days is a far more pleasant beast than the VS6 days, the tooling is pretty good and the language can be tamed into a pretty elegant beast with the right coding standards and discipline.

Post reply on HN