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

91–100 of 428 posts

Re: Moving from TypeScript to Rust / WebAssembly

#91

Post by nightowl_games »

Scarbutt wrote: post #69
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 have seen this being asked many times in /r/rust and 90% of the answers disagree with you. A common theme is to explore in Python then rewrite in Rust.

gamedev here and I basically do exactly this. explore in GDScript, rewrite in cpp.

(GDScript is pretty much python)

Re: Moving from TypeScript to Rust / WebAssembly

#92

Post by blub »

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…

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.

Re: Moving from TypeScript to Rust / WebAssembly

#94

Post by staticassertion »

blub wrote: post #84
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've "won" so far because static types languages were cumbersome and unpleasant to use, but this is changing and dynamic languages are learning some type tricks too. The issue here is with Rust: its strengths are mostly irrelevant for the web and its weaknesses (particularly slow development compared to the competition because of having to pacify the type checker) are really important. Op is painstakingly beating…

I don't totally agree about its strengths not being relevant. Memory safety is an extremely low bar that the web has generally managed to meet, but Rust has a lot of value elsewhere. The author talks about significant performance improvements, which would be very welcome on many sites, as well as improved error handling and data validation patterns.

Re: Moving from TypeScript to Rust / WebAssembly

#95

Post by lmm »

tigershark wrote: post #83
lmm wrote: post #75

Earlier quoted context omitted.

ML family languages are so much more productive that that probably outweighs the costs of manual memory management. Rust will always be less productive than Haskell or Scala, but a language with a decent type system is going to have a huge advantage over JavaScript.

...Haskell and scala are not part of the ML family. OCAML and F# are languages belonging to the ML family.

By what definition? Haskell and Scala both have the complete ML featureset (in particular they have sum types and full pattern matching; they're also part of the small group of languages that has typeclasses, which were originally invented for Standard ML) and are on record as being heavily influenced by ML languages (via Miranda in the case of Haskell).

Re: Moving from TypeScript to Rust / WebAssembly

#96

Post by blub »

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…

There's the hype and there's the reality. Some people don't appreciate the former much and reach for the down arrow...

Rust is nowhere near the productivity of Ruby or Python. If that's the case for you maybe your projects have some peculiarities or it's a personal thing.

Re: Moving from TypeScript to Rust / WebAssembly

#97

Post by pmontra »

hombre_fatal wrote: post #53
anyfoo wrote: post #20

As long as you use a language with a good, static type system, I don't care so much what you use. TypeScript or Rust, for all I care you can transpile Haskell into JavaScript if you feel adventurous. But don't use a dynamically typed language as the source language for anything that is supposed to be more than a simple script.

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

My experience is similar (Milan, Italy.)

If a company is small and/or has to rely on freelancers it goes with dynamically typed languages (PHP, Node, Ruby, Python and Elixir) because that's what the bulk of freelancers use.

If they have many internal developers or use big consultancy firms they go with Java or C#.

Of course there are exceptions (I know a few of them) and my point of view can be biased because I use to see projects and developers of dynamically typed languages.

But I know a few small companies with a code base in Java that had a hard time at finding Java freelancers. Almost all of them are employees, unreachable for them.

Re: Moving from TypeScript to Rust / WebAssembly

#98

Post by amitport »

Hi Nicolo,

Here are my two (or more) cents:

1 - Javascript is fast enough for your use case. No one will notice the difference in a board game website.

2 - AI should probably be implemented in python anyway. As ugly as python can be, you shouldn't fight the world; there are too many free advanced AI algo implementations in python out there.

3 - Regarding "Limitations of TypeScript" (strict typing / data validation / error handling): first of all arguable claims, but moreover, even if you think rust is better in these concerns, they are not important enough to justify reimplementation, disregarding away typescript's advantages and taking the risk involved in a new language and toolset. Yes, I can see the appeal as a programmer to learn new stuff, but seriously you should have much better reasons to rewrite existing code.

BTW, also, if I would think of a rewrite, I would have gone with scala or python, both are slower on the web, but seriously, it will not amount to anything meaningful in your use-case. Scala has better typing, and contextual abstraction is a killer feature for DSLs like game mechanics specification. Python is the lingua franca of AI, and pypy has greenlets [1]! Which is much cooler than people seem to realize. Specifically, it should allow writing immutable redux-like command pattern operations, as regular code, without the weird switches everywhere.

BTW2, I've contributed to boardgame.io, please consider staying with open source. We can build something like boardgame-lab together.

[1] https://greenlet.readthedocs.io/en/latest/

Re: Moving from TypeScript to Rust / WebAssembly

#99

Post by nicolodavis »

amitport wrote: post #98

Hi Nicolo, Here are my two (or more) cents: 1 - Javascript is fast enough for your use case. No one will notice the difference in a board game website. 2 - AI should probably be implemented in python anyway. As ugly as python can be, you shouldn't fight the world; there are too many free advanced AI algo implementations in python out there. 3 - Regarding "Limitations of TypeScript" (strict typing / data validation /…

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.

Re: Moving from TypeScript to Rust / WebAssembly

#100

Post by blub »

staticassertion wrote: post #94
blub wrote: post #84

Earlier quoted context omitted.

They've "won" so far because static types languages were cumbersome and unpleasant to use, but this is changing and dynamic languages are learning some type tricks too. The issue here is with Rust: its strengths are mostly irrelevant for the web and its weaknesses (particularly slow development compared to the competition because of having to pacify the type checker) are really important. Op is painstakingly beating…

I don't totally agree about its strengths not being relevant. Memory safety is an extremely low bar that the web has generally managed to meet, but Rust has a lot of value elsewhere. The author talks about significant performance improvements, which would be very welcome on many sites, as well as improved error handling and data validation patterns.

Most things thank goodness are not SPAs, nor do they have to be.

The problem here is the concept of SPA itself - it's a complete hack which is plastered over with various tricks to make it halfway usable. This has been going on for years now.

Websites on the other hand are slow because of the tracking and the ads which load tons of JS. Remove that and the web will be blazing fast.

Post reply on HN