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

381–390 of 428 posts

Re: Moving from TypeScript to Rust / WebAssembly

#381

Post by Shorel »

nicolodavis wrote: post #99
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.

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!

Re: Moving from TypeScript to Rust / WebAssembly

#382

Post by zrail »

square_usual wrote: post #258
zrail wrote: post #220

Earlier quoted context omitted.

Sorbet is the only way I can function in anything larger than a 10 line script these days. I’ve started adding it to personal projects because it makes revisiting them later so much easier.

Without the LSP implementation out in the open, though, sorbet is just a type checker. It's not made much for sense for me to start integrating it into my personal projects just yet, since I only get the benefits when I run tc manually. Once Stripe opens up the LSP, however, I can see it gaining widespread adoption.

I haven’t tried the open source release lately but it looks like master has the lsp option.

Re: Moving from TypeScript to Rust / WebAssembly

#383

Post by nicolodavis »

steveklabnik wrote: post #367
RyanGoosling wrote: post #363

If you push Rust to client-side WASM, can it still perform DOM manipulations?

Yes. It has to call out to JS to do so. It's implemented in a way that's forwards-compatible so once wasm can do so natively, your code will just magically get faster.

That's right. For my use-case I decided to just stick with JS for UI stuff (using Svelte). I call into Rust code like a black box to update some state.

Re: Moving from TypeScript to Rust / WebAssembly

#384

Post by cs702 »

ChrisRackauckas wrote: post #373
cs702 wrote: post #345

Earlier quoted context omitted.

For ML/scientific computing, it can fulfill both roles, I'd say. Julia looks about as flexible and easy to use as Python, R, and matlab for experimenting and iterating quickly with throwaway code, and superior to those languages in every other important dimension except one: it lacks Python's gigantic ecosystem.

Julia has a much larger ecosystem in terms of things like numerical linear algebra, scientific computing, and differentiable programming. How do you use block banded Jacobians inside of ODE solvers? Python's ML ecosystems just barely got non-stiff methods, so advanced accelerations are fairly far away, whereas these are things that have worked with Julia's ML solvers for a long time now.

Before responding, first let me say thank you for all the work you have done and continue to do. Also as I wrote above, I view Julia as superior to Python in every other way. :-)

By "ecosystem" I mean much more. PyPi currently offers around a quarter million Python packages, versus thousands for Julia. Github code and activity using Python is also currently around three orders of magnitude greater than for Julia. Python is currently the fourth most popular language on Stack Overflow (after JS, HTML, and SQL). It's a gigantic ecosystem that has evolved over three decades.

Re: Moving from TypeScript to Rust / WebAssembly

#385

Post by ChrisRackauckas »

cs702 wrote: post #384
ChrisRackauckas wrote: post #373

Earlier quoted context omitted.

Julia has a much larger ecosystem in terms of things like numerical linear algebra, scientific computing, and differentiable programming. How do you use block banded Jacobians inside of ODE solvers? Python's ML ecosystems just barely got non-stiff methods, so advanced accelerations are fairly far away, whereas these are things that have worked with Julia's ML solvers for a long time now.

Before responding, first let me say thank you for all the work you have done and continue to do. Also as I wrote above, I view Julia as superior to Python in every other way. :-) By "ecosystem" I mean much more. PyPi currently offers around a quarter million Python packages, versus thousands for Julia. Github code and activity using Python is also currently around three orders of magnitude greater than for Julia. Pyt…

Yes true. I think it's a lot like the old Android vs iOS stuff though: counting the number of packages doesn't mean all that much because so many have been abandoned that Python probably has a much higher percentage of junk out there. That said, Python's ecosystem is still larger, but that doesn't mean it covers all domains well. I can name a bunch of holes that it has off of the top of my head, and same with Julia too, so it's not like either supersets each other. So I just think the "but Python has a bunch of packages" is a lot more nuanced than that: in many areas of ML or webdev it is much more developed, but when you get out of that realm it can get sparse in some ways.

Re: Moving from TypeScript to Rust / WebAssembly

#386

Post by cs702 »

ChrisRackauckas wrote: post #385
cs702 wrote: post #384

Earlier quoted context omitted.

Before responding, first let me say thank you for all the work you have done and continue to do. Also as I wrote above, I view Julia as superior to Python in every other way. :-) By "ecosystem" I mean much more. PyPi currently offers around a quarter million Python packages, versus thousands for Julia. Github code and activity using Python is also currently around three orders of magnitude greater than for Julia. Pyt…

Yes true. I think it's a lot like the old Android vs iOS stuff though: counting the number of packages doesn't mean all that much because so many have been abandoned that Python probably has a much higher percentage of junk out there. That said, Python's ecosystem is still larger, but that doesn't mean it covers all domains well. I can name a bunch of holes that it has off of the top of my head, and same with Julia t…

It's not just packages and repos, but also installed base, developers, forums, discussions, corporate backers, etc.

Otherwise, I agree that not all domains are well covered by any language :-)

Re: Moving from TypeScript to Rust / WebAssembly

#387

Post by [deleted] »

anyfoo wrote: post #374
dnautics wrote: post #372

Earlier quoted context omitted.

You're arguing with a strawman. I'm just saying static typechecking is usually sufficient this day in age. Your language itself doesn't have to be static. Actually I'll go even further: It wasn't enough three years ago when language server protocol wasn't a thing.

Can you explain that distinction, possibly with an example?

[deleted]

Re: Moving from TypeScript to Rust / WebAssembly

#389

Post by eigenspace »

cs702 wrote: post #386
ChrisRackauckas wrote: post #385

Earlier quoted context omitted.

Yes true. I think it's a lot like the old Android vs iOS stuff though: counting the number of packages doesn't mean all that much because so many have been abandoned that Python probably has a much higher percentage of junk out there. That said, Python's ecosystem is still larger, but that doesn't mean it covers all domains well. I can name a bunch of holes that it has off of the top of my head, and same with Julia t…

It's not just packages and repos, but also installed base, developers, forums, discussions, corporate backers, etc. Otherwise, I agree that not all domains are well covered by any language :-)

Something that I think is worth discussing is that julia has far more package developers per user than Python. That may seem like a weird thing to prop up, it seems to just suggest that Julia users more often find themselves needing to implement something themselves rather than use a pre-existing library, and that's definitely true.

However, Julia also makes the experience of growing from a package user to a package developer basically seamless. A big part of what makes this seamless is that almost all julia packages are written in pure julia and thus relatively easy to read and understand for a julia programmer. This coupled with the strong introspection capabilities makes it so that users who would never be writing their own packages in Python end up contributing to the Julia ecosystem.

Coupled to this is the fact that julia is a highly composable language meaning that it's very easy to combine functionality together from two separate packages that weren't designed to work together. This composability makes julia's fewer packages have far greater leverage and applicability than Python packages and also makes it so that when you do need to make your own package, you're less likely to be reinventing the wheel every time.

Consider the fact that all the big machine learning libraries in Python all have basically implemented their own entire language with their own special compiler, all the requisite datastructures, etc. In Julia, that's rarely necessary. Flux.jl is just built using native julia datastructures and julia's own (very hackable) compiler.

Re: Moving from TypeScript to Rust / WebAssembly

#390

Post by indolering »

lacker wrote: post #352
filleduchaos wrote: post #102

Earlier quoted context omitted.

> This is only a problem if you are mixing untyped code with typed code, isn't it? I find it a bit strange that people talk about this as "only a problem", as though it was some weird niche edge case and not an ever-present issue. The written-in-plain-JS ecosystem completely dwarfs the written-in-TypeScript one; unless you're doing something rather trivial you're quite likely to end up depending on a library that bar…

You don't have to depend on badly-written untyped third-party libraries, just because there are a lot of them out there. Many projects and companies will avoid doing so. This is especially reasonable if your comparison is switching to a language like Rust; there are probably fewer third-party libraries available in Rust overall than there are libraries with accurate TypeScript definitions available.

You still have to validate input whenever you interact with servers, the operating system, or the user.
Post reply on HN