Live data from Hacker News

Moving from TypeScript to Rust / WebAssembly

nicolodavis.com

321–330 of 428 posts

Re: Moving from TypeScript to Rust / WebAssembly

#321

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.

I've got a large codebase i've been maintaining since 1999 that i've continued to evolve and is still in use today . I've been able to steadily improve it without breaking much. IDK maybe its being > 50 but I can appreciate less "dynamic" environments. I do we dev in vue with a go back end but I know the vue part is going to be a rewrite in 5 years. Who wants to keep doing that shit? not this 52 year old guy.

Modern refactoring and static analysis tools really make it far easier to keep old code bases up to date.

As a hobby thing I'm taking an almost 30 year code base written in C and reworking it into C++17. I've become somehow somewhat adept at this transformation over the years :-)

Re: Moving from TypeScript to Rust / WebAssembly

#322

Earlier quoted context omitted.

While this is true, this doesn't inherently mean you can't do this pattern. https://crates.io/crates/typed_arena for example. It depends on exactly how allocations and your data structure are tied together.

It would be amazingly handy if someday it was possible to direct Rust to make all heap allocations under a certain block within an arena. At the moment it looks like you have to rewrite any third party code that makes heap allocations to use the arena explicitly at each allocation.

Yep, it would. There’s certainly a bunch of work to do here still.

Re: Moving from TypeScript to Rust / WebAssembly

#323
As someone who has (mostly) enjoyed working with Python and JS (CoffeeScript in the past, and ES6+ and TypeScript more recently), and also dabbled in Ruby/Rails, I've been intrigued by Rust for a while. Its promise of being close in speed to C/C++, but safer and more ergonomic, sounds great. I have not attempted to build anything with it yet, but I've looked at what (I think) is enough examples to be familiar with its constructs, and have seen some benchmarks.

For systems software or libraries that are meant to be hooked into from, say, a JS/TypeScript environment (see https://deno.land, a promising alternative to Node), it seems like Rust has a lot of potential.

But for building applications (which is what I'm focused on currently) it seems Rust has a "No OOP for you!" attitude that gets in the way of modeling your application domain quickly. Yes, you can use impl and trait as an alternative to classes. But it seems like you have to jump through a lot of hoops; define your structs, define a trait for default behavior and remember that &self is provided as an implicit first argument to the methods (this is similarly cumbersome in Python), then define an impl for each corresponding struct (don't forget about &self!). As opposed to just declaring a base class and overriding when you need to in the subclasses. I am definitely not saying classes are the only way to do OOP, but at least give developers the option of using them.

I have found Swift attractive for application development because it gives you structs for one-off (value-based) data types, classes when you need an easy way to do inheritance and polymorphism (and/or need reference-based data types), and extensions as a more abstract way to enhance structs and/or classes (and/or enums). It doesn't force you to use classes (and the community appears to think protocols are a better construct), but the language remains approachable, and you can always start with classes then refactor to protocols when the need arises.

Re: Moving from TypeScript to Rust / WebAssembly

#324

Earlier quoted context omitted.

> - In your average Rust project, all dependencies are already built from source That is only the case for open source code like crates.io, there is nothing that guarantees you will get the source code of a third-party, though. I mention this because in the native world it is common to give customers precompiled libraries. > - Already using LLVM as the compiler backend Some people don't seem to know this, but all lan…

> all languages that target LLVM (including C, C++, Fortran, Ada, Julia, Swift and others) can be used in WebAssembly. Having LLVM doesn't mean that webassembly Just Works, in the same way that having LLVM doesn't mean that all of its architectures Just Work. And even after getting past the "hello world" stage, there's a lot of other work to do to make it more than just a toy. Let's take Ada, for example. https://blo…

No, that is if you want runtime support, etc.

If you just want to run some computational code (which is the case for most of the Wasm use today), it will Just Work, as you say.

In fact, that is how I sped up a webpage: I just wrote myself the minimal support needed to run the code that computed X, and that's it. I don't want the entire world or standard library for computational bits to work.

Re: Moving from TypeScript to Rust / WebAssembly

#325
post #42

Earlier quoted context omitted.

This is silly. There are systems which have had nine nines of uptime written in dynamically typed languages.

That it can be done doesn't mean is the optimal approach. I was a diehard fan of dynamic languages for a decade, but eventually I saw the light. I still use dynamic languages daily, but the bigger the project the more I want proper static typing. None of that mypy stuff, the real deal.

You're just using the wrong dynamic programming language. Don't get me wrong type checking, static or otherwise, is useful, but eventually you're going to have to throw in the towel and deal with truly hard problems like distributed systems, which in the end must be dynamic (you cannot safely assume that a node separated by time and space respects the same type system your node does).

I have a 20k LOC distributed system, 40k if you include all the libraries I've written for it, running in prod, written in a (typechecked) dynamic language, and it's fine. I had very few typing errors in dev, and one typing error that I pushed to prod. Even this had no discernible customer effect. I discovered it months later when I was checking over my logs understand logical errors. Currently all of the reported errors are race conditions on startup (and sporadic network errors). But it's fine. The system tolerates it, and restarts the failing modules, instead of being pedantic, and so instead of spending weeks debugging concurrent startup, I get a no-hassle fast booting system (which also means nonblocking bootup and thus higher customer availability during failure and restart). The other nice thing about dynamic systems, is that if they're not otherwise terrible, (logical) debugging is a breeze, because all types are inspectable and I don't have to worry about implementing observerability hooks for every single datatype. I can just look at the data as it moves through my system. And that also means that telemetry and logging with structured metadata just "happens", and is highly composable with no hassle.

I guess my biggest problem with static typing absolutism is that it leads to this attitude that code can be correct. It can't. Even if it's provably correct (in the mathematical sense), if your axioms are violated by your system then your system can wind up in an undefined state. You must plan for failure. And sometimes the most efficent/effective plan is "do nothing".

Re: Moving from TypeScript to Rust / WebAssembly

#326

Earlier quoted context omitted.

I'm not the OP but I can confirm in my own project, we found about a 10x performance gap between AssemblyScript and TypeScript. In essence, we're working on a rewrite of DNAVisualization.org[1][2], a serverless web tool for the interactive inspection of raw DNA sequences. We hoped that WASM would give us a performance boost but have been generally disappointed with both the performance and the amount of complexity in…

I made PR which suggest some changes and fixes: https://github.com/Lab41/dnaviz/pull/21

As you can see AssemblyScript approx 4x-4.5x times faster now

Re: Moving from TypeScript to Rust / WebAssembly

#327
post #188

Earlier quoted context omitted.

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're referring to Rust's static type system. What do you make of TypeScript?

I've tried TypeScript and I didn't really like it. Plus you can ignore the strict type if you'd like to which is a slippery-slope if you are in a hurry to get something to market.

Re: Moving from TypeScript to Rust / WebAssembly

#328

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…

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…

I've discovered in large, long-lived Java codebases that it's common to Greenspun expressiveness and malleability back into the language through heavy reliance on things like Spring, stringly typed mechanisms, and dynamic code generation.

The impact on maintainability is about what you'd expect. Maybe, on an abstract level, the software isn't as complex as what you can do in Ruby, but the verbosity of the language brings its own maintenance challenges. I can't speak to Ruby specifically, but, in practice, I haven't found that I'm all that much more afraid to change things in a large Python codebase than a large Java one.

I'm now coming to think that the real challenge is dynamicism in general, regardless of whether it's built into the language or implemented as a library solution. So, if Java has an advantage here, it's simply that it tends to discourage people from overdoing it by making it awkward to do.

Re: Moving from TypeScript to Rust / WebAssembly

#329

Earlier quoted context omitted.

> all languages that target LLVM (including C, C++, Fortran, Ada, Julia, Swift and others) can be used in WebAssembly. Having LLVM doesn't mean that webassembly Just Works, in the same way that having LLVM doesn't mean that all of its architectures Just Work. And even after getting past the "hello world" stage, there's a lot of other work to do to make it more than just a toy. Let's take Ada, for example. https://blo…

No, that is if you want runtime support, etc. If you just want to run some computational code (which is the case for most of the Wasm use today), it will Just Work, as you say. In fact, that is how I sped up a webpage: I just wrote myself the minimal support needed to run the code that computed X, and that's it. I don't want the entire world or standard library for computational bits to work.

The example I pointed out was for extra stuff, sure, but even just to get a compiler to spit things out, work needs to be done. I don't know Ada's compiler well enough to point to where that work is, but here's the initial implementation of the asmjs and wasm targets in rustc, for example https://github.com/rust-lang/rust/pull/36339

This is just true of any architecture. LLVM is a toolkit, it isn't magic.

Re: Moving from TypeScript to Rust / WebAssembly

#330
post #315

Earlier quoted context omitted.

> This really nails why languages like PHP and Ruby have won out over static typed It really doesn't. Languages like PHP and Ruby "have won out" over statically typed languages because the representatives of statically typed languages at the time were Java and C++, both of which were bad (they still are, but they were): verbose, difficult (and verbose) to leverage for type-safety, missing a bunch of tremendously usef…

I think this is spot on. IMHO, everyone that uses Rails knows it's flawed. The problem is that there's not a better option out there that: (1) Is "batteries included" (2) Has the gem/engine ecosystem where basically every problem is already solved. (3) Expressive code like has_many :things If we could get those things + static typing + performance everyone would switch. But that doesn't exist.

That alternative in 2020 is Python 3.7+ with typing annotations.

Python is very "batteries included," and there is a large set of exisitng packages for most things. One can monkey-patch things and invent cute syntax, but most python is rarely hard to reason about what's actually going on.

It's easy to bag on parts of python (eg some syntax and terrible distribution story), but I feel much less crazy (and suspicious of every punctuation mark) when working on a modern python app than when working on a modern ruby app, especially in the presence of rails.

Post reply on HN