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

241–250 of 428 posts

Re: Moving from TypeScript to Rust / WebAssembly

#241

Post by MaxBarraclough »

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…

I'd be interested to see how current-day WASM stacks up against current-day Java. Don't suppose you've ported your crypto code to Java? Other than the maturity of the JIT compilers, are there reasons we should expect WASM to be any slower?

Re: Moving from TypeScript to Rust / WebAssembly

#242

Post by lewisjoe »

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…

Nice analogy. Here's somethine new. Rust is not just a sports car, but an eco-friendly electric one at that.

One topic OP hasn't touched upon is the disadvantage of "pushing client side to the server". JS is terrible at handling concurrent processes. The browsers have been able to make do because they typically care about just one user.

In the server though, it's terribly important to handle thousands of users concurrently. JS engines suck at it.

To put it in plain words, if you are into SPAs and want server side rendering, among all the other issues the one sure wall you'd be hitting is scaling issues.

JS will never be able to construct and send HTML over as efficiently as Rust could. This is going to be the reason why Rust(or a similar tech) will eventually win the web.

Re: Moving from TypeScript to Rust / WebAssembly

#243

Post by kevinyew »

rubber_duck wrote: post #175
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…

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…

PHP is definitely not a meme, it's got a ton of actively developed frameworks, PHP 7 was a huge step forward for the language and PHP 8 is shaping up to be as well.

It's been used at every workplace I've been at, sometimes well, sometimes not so well, just like any language. No idea what the point of blanket statements like this is.

Re: Moving from TypeScript to Rust / WebAssembly

#244

Post by jmuguy »

rubber_duck wrote: post #175
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…

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…

Which standard function in Ruby is a single letter?

Re: Moving from TypeScript to Rust / WebAssembly

#245

Post by ragnese »

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.

It's because it also has expressiveness features that Java and Go don't.

* Better handling of "null"-ness

* Sum types

* Stricter/different error-handling

* Move semantics, which can actually be nice for some APIs outside of any performance considerations

Kotlin checks a couple of these boxes, but then is also GC'd, so also gets rid of a lot of "noise" that would be in the equivalent Rust code.

For typical backend junk, I'd be Kotlin first, but I'd definitely consider Rust if performance (non-IO) was a concern.

Re: Moving from TypeScript to Rust / WebAssembly

#246

Post by knubie »

CraigJPerry wrote: post #150
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…

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…

> What would be nice is typing like typescript - optional typing. Where i can provide a typings binding separate from the code (in the way that i can bring my own tests without changing anything of production code if you’ve made an unholy mess of testing).

A contract system like clojure's spec sounds close to what you're describing.

Re: Moving from TypeScript to Rust / WebAssembly

#247

Post by ImprobableTruth »

CraigJPerry wrote: post #150
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…

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…

I don't understand this reasoning at all. You have some form of contracts, whether you specify them or not. If it's too messy to formalize, that's still going to be an issue when you're working on it in an untyped language. At best you're just sweeping all those ugly edge cases under the rug.

>Also, what stops something like

having a more precise specification. E.g. adding a commutativity requirement would eliminate your example.

Re: Moving from TypeScript to Rust / WebAssembly

#248

Post by rubber_duck »

jmuguy wrote: post #244
rubber_duck wrote: post #175

Earlier quoted context omitted.

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…

Which standard function in Ruby is a single letter?

b, to_s, to_i, to_a, to_c, to_h, to_r, etc.

Should have said methods but you get what I mean. And I've encountered ambiguous and pointless abbreviations all over the place.

Re: Moving from TypeScript to Rust / WebAssembly

#249

Post by danbruder »

Rust's type safety and error handling are helpful tools to have in your belt when gluing together the pieces needed for a web api. I have been working on a new product at my day job that has needed to change a lot as we learn and grow and I am happy with how Rust has been reliable in the face of that change.

Re: Moving from TypeScript to Rust / WebAssembly

#250

Post by littlestymaar »

spion wrote: post #229
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.

For a lot of code, if you write JS like you write C (avoid allocations by avoiding the creation of objects, arrays or closures) you should get very comparable performance i.e. within 30% to 50% of C performance

You can indeed avoid most of the js overhead if you use a particular subset of the language. In fact, that's how asmjs started, but:

- it's not JavaScript anymore, you'll lose most idioms you're used to work with, and it's a nightmare to maintain because it's pretty low level.

- it won't be as fast as it could unless the runtime is aware of the fact that you are using that subset (that's why asmjs used some annotation to run on a special engine on Firefox, and part of the reason why browsers moved to wasm).

Post reply on HN