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

391–400 of 428 posts

Re: Moving from TypeScript to Rust / WebAssembly

#391

Post by ronanyeah »

csomar wrote: post #188
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…

It's still a significant upgrade over JavaScript. I'm developing a web app with the Backend in Rust and Front-end in Vuejs/JavaScript. Sure Rust was slower to develop, but it doesn't throw errors like 'val in undefined' and then I have to go debugging where I check for the value of val. You do that beforehand on Rust and that avoid a whole class of problems. JavaScript is cheaper to get started but becomes way more e…

You can get that kind of reliability on the front end with Elm, Purescript etc but investing in such niche languages is obviously a nuanced decision.

Re: Moving from TypeScript to Rust / WebAssembly

#392

Post by amitport »

Shorel wrote: post #381
nicolodavis wrote: post #99

Earlier quoted context omitted.

Hey Amit, good to hear from you! > Javascript is fast enough for your use case. No one will notice the difference in a board game website. No, actually. Have you seen how long boardgame.io's MCTS bot takes to make a Tic-Tac-Toe move? Not the end of the world, but certainly in need of improvement.

Please ignore him whole hearty. Some people want to write profitable apps in the shortest amount of time possible, while others want to advance the state of the art in technology. IMO we always need more people in the second group. And sometimes, you can hit the jackpot and do both things at the same time!

"Please ignore him whole hearty."

My advice is not about profit.

My "time-to-market is most important" advice (not mine, it is a very sound and well researched strategy) is about making a sustainable project:

A) most passion-only projects are abandoned at some point in order to pay for food and rent. (Yes there are few exceptions among an ocean of failed projects)

B) The other point is that even if you can run this for years before showing traction. Having users mean getting feedback, which will render some of your efforts needless.

Moreover, it was only a small part of what I said. I do think that rust doesn't make sense for other reasons, and doing a rewrite in a real project needs better reasoning otherwise you would keep rewriting forever.

Moreover2, I think you're misinterpreting the original author's intent. I'm not sure if there is interest in building AI in rust as a goal for itself. Seems to me more oriented towards the result than about the love for rust.

Re: Moving from TypeScript to Rust / WebAssembly

#393

Post by loxs »

Matthias247 wrote: post #361
loxs wrote: post #115

Earlier quoted context omitted.

I am writing an app that needs worker threads both on the backend and also on the frontend (because of some heavy processing of large amounts of "objects") and my experience with TS so far is very poor. JS runtimes are just not suitable for heavy concurrent/parallel processing. Serialization/deserialization overhead between threads is probably (much) worse than it would be if the worker threads were in Rust. It's not…

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.

Re: Moving from TypeScript to Rust / WebAssembly

#394

Post by pjmlp »

mwcampbell wrote: post #360
cs702 wrote: post #302

Earlier quoted context omitted.

> 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. I prefer a different analogy: Rust is high-end automated industrial equipment for machining high-precision metal…

> with high confidence that it will work and last a long time And we need more of our software to be like that. Now if we could just do something about the constant pressure to compromise.

Certifications and more flexible laws for returning it when it doesn't fit the purpose, will do it.

Re: Moving from TypeScript to Rust / WebAssembly

#395

Post by pjmlp »

The_rationalist wrote: post #212
tluyben2 wrote: post #165

Earlier quoted context omitted.

Exactly; I guess a lot of people just work on projects/jobs and then move on. Once you need to go back to systems you forgot about (things you wrote 5-10-15-20+ years ago), Ruby (in your example and indeed my experience) is a nightmare on speed. The (strange to me) idea that people have that their code won't be around that long, hits me in the face every time a client asks me to 'connect to something made by someone…

The dilemma: boilerplate vs dynamic languages is a thing of the past. Kotlin make code even clearer than in java while being the sexiest syntax out there. It's 100% compatible with your Java code so you can incrementally migrate starting now!

Kotlin has sealed its fate turning into Android's main language.

On the JVM its novelty will fade out while Java adopts whatever features might be relevant to the millions of Java developers out there, just like it happened with all other that came before.

And I remember the days back when Groovy was supposed to be the scripting language for JEE, and Spring was going full speed with it as Java alternative, and we even got strongly typed variant.

Re: Moving from TypeScript to Rust / WebAssembly

#396

Post by pjmlp »

mumblemumble wrote: post #354
zaphar wrote: post #269

Earlier quoted context omitted.

The dilemma was always a false choice. You don't need kotlin to get rid of your boilerplate. Java is just a capable of being concise as any other language. Java's verbosity is a cultural artifact not a technical one.

So, technically, you can get rid of a lot of the more egregious clutter with things like Project Lombok. But I'd argue that, if you need to lean on compiler plugins to do it, it's sort of a rhetorical Pyrrhic victory.

And I would argue that adopting guest languages, alongside the extra complexity that they bring on board regarding extra IDE plugins, more layers to debug (has to pretend to be Java to the JVM), FFI issues (calling coroutines from Java), and creating their own library eco-system is not worth the trouble, beyond some short term feel good.

As long as the platform exists, its main language is the one holding the keys.

Re: Moving from TypeScript to Rust / WebAssembly

#397

Post by eitland »

ed25519FUUU wrote: post #307
zaphar wrote: post #269

Earlier quoted context omitted.

The dilemma was always a false choice. You don't need kotlin to get rid of your boilerplate. Java is just a capable of being concise as any other language. Java's verbosity is a cultural artifact not a technical one.

Don’t get me wrong. I use java every day and quite enjoy it, but when I compare it to writing in Go or Kotlin, java does sometimes feel a little like meta programming. Especially if it’s a spring app, which is quite common.

This is obviously a matter of taste but I enjoy Java more when I stay away from Spring.

Re: Moving from TypeScript to Rust / WebAssembly

#398

Post by masklinn »

cygx wrote: post #364
masklinn wrote: post #295

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

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

Re: Moving from TypeScript to Rust / WebAssembly

#399

Post by MaxBarraclough »

CryZe wrote: post #129
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…

On algorithmic code, idiomatic Rust + WASM is often about 10 to 40 times faster than idiomatic JS. The problem however is that each call between WASM and JS has a hefty cost of about 750ns. So your algorithm needs to be doing a significant amount of independent calculations before you will see these performance differences.

> each call between WASM and JS has a hefty cost of about 750ns

Why is this the case? Can we expect it to go away as browsers mature?

Re: Moving from TypeScript to Rust / WebAssembly

#400

Post by lifeisstillgood »

gen220 wrote: post #275
cmrdporcupine wrote: post #265

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.

This is, IMO, one of the most underrated aspects of the monorepo, that has such a valuable impact over time. It only takes a handful of extremely passionate engineers (and I really mean a handful, like less that 2% of engineers in an org) to raise the quality-floor of the entire codebase.

For sanity, sustainability and fairness I would rather that read

It only takes a handful of extremely passionate engineers > It only takes a handful of paid engineers, full time assigned to the task

Post reply on HN