Moving from TypeScript to Rust / WebAssembly

PHP has long been a meme and is mostly legacy stuff or bottom tier work.

Dynamic languages are adding static optional static typing because the value provided by tooling as the projects scales is undeniable.

It took ES6/TypeScript to drag JS out of the dump that it was with every library adding its own take on a class system - the maintainability jump from ES5 to TS is incomparable for anything larger than 1k LOC

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 around the bush, but what they're getting at is that Rust + webdev = mismatch.

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 useful pieces (type-safe enums to say nothing of full-blown sum types), nulls galore, …

As a result, the gain in expressiveness and terseness (even without trying to code-golf) of dynamically typed languages was huge, the loss in type-safety was very limited given the choice was "avoid leveraging the type system" or "write reams of code because the language is shit", and the fast increase in compute performances more than compensated for the language's loss in efficiency.

And that's before talking about the horror show that Java's web frameworks ecosystem was circa 2006.

> Languages that tend to work well with it are those that are highly flexible around the corner cases of these technologies, and allow you to quickly iterate through the process of gluing them together.

That's really complete hogwash outside of the client, which isn't what we're talking about here since neither php nor ruby run there. On the server you have clear interfaces between "inside" and "outside", and there's no inflexibility to properly taking care of cleaning up your crap at the edges. Quite the opposite, really.

PHP is highly to blame. PHP, being a scripting language, is easy to deploy and keeps chugging along at all costs. It may do something nonsensical, but it will try to chug along to completion without aborting. It creates a system where it is easy to write and deploy something that usually works.

So I think typing has its merits and languages like Typescript really make development safer and code easier to understand, while still making it possible to write and interface with untyped code if necessary.

Real reason is lowering the bar of entry, and that explains why web is horribly broken.

The "bootcamp webshit" meme exists for a reason. That's not gatekeeping - lowering the bar to entry below a certain level leads to drastic decrease in quality.

Every time you write logic in your code, your brain is aware that the logic is dealing with a specific type. Writing a type signature on top of that is just additional instructions to the compiler about the type you have already specified in your logic. It is a minor inconvenience.

There are many reasons why Ruby and PHP won out. One of the reasons is many people misunderstand the power and flexibility of types. Once they understand this, they will know there is really no trade off between statically typed and dynamically typed. Statically typed languages are infinitely better and the only downside is a minor inconvenience.

First off, note that there is only one function in the universe that can really take every single type in existence and that function is shown below:

  -- haskell
  identity :: x -> x
  identity x = x

  # python
  def identity(x: Any) -> Any:
      return x

The above example have no logic to specify a type... The minute you start to add any logic to your function immediately your function becomes bounded by a type. Let's say I simply want to add one in my identity function.

  -- haskell
  identity :: Int -> Int
  identity x + 1 = x + 1

  # python
  def identity(x: Int) -> Int:
      return x + 1

Let's say I want to do garbage code like write a function that handles an Int or a String? That can be typed as well....

  --haskell
  type IntOrString = Number Int | Characters String
  func :: IntOrString -> IntOrString
  func Number n = n + 1
  func Characters n = n ++ "1"

  #python
  IntOrString = Union[str, int]
  def func(n: IntOrString) -> IntOrString:
      if isinstance(n, int):
         return n + 1
      if isinstance(n, str):
         return n + "1"

   -- haskell
   type JSON = Number Float | Characters String | Array [JSON] | Map String JSON
   func :: JSON -> JSON
   func Array x = x ++ [1.0]
   func x = x

   -- python
   JSON = Union[float, str, List["JSON"], Dict[str, "JSON"]]
   def func(x: JSON) -> JSON:
     if isinstance(x, list):
        return x + [1.0]
     else:
        return x 

  

One caveat to note here (and this is specific to haskell) is lack of interfaces specific to record types. I cannot specify a type that represents every single record that contains at least a property named x with a type of int.

And we need more of our software to be like that. Now if we could just do something about the constant pressure to compromise.

Python & Deno/Node fit the bill for the latter category. Would you consider Julia in the former or latter category for ML use-cases?

I think this is assumption is a bit too broad. There is another side of this:

In JS you write less code than in Rust and there is less explicit coupling in a dynamic codebase. So changes tend to be smaller and faster as well.

For example if you pass a top-level data-structure X through A, B... and C but only C cares about some part Z. Then you change how Z is produced in A and consumed in C.

If you are dynamic you just do exactly that, which is actually just fine. In a static language you have to change all the B's. Or you take the time and write a sensible abstraction over Z or X so in the future you don't have to change the B's anymore, which is better, but ultimately less readable and more complex.

Stuff that is well understood and specified in advance suits a language like Rust better. You get all these runtime guarantees and performance. You get all this expressive (but explicit!) power to fine-tune abstractions and performance. It's great.

But the closer you get to a UI (especially GUI) and non-technical, direct(!) users, the more dynamic you want to be. Because in this context you are more of a human to computer translator: requirements get discovered via iterations, interactions need to be tested and evolve etc.

The long answer probably includes GATs (generic associated types), and the even longer answer starts with the amazing work that Nico et al. does to reinvent the internals of the Rust type checker. (Basically - if I remember correctly - the compiler team is currently refactoring big parts of rustc, to librarify the type checker, and replace it with a PROLOG-ish library called "chalk", which is able to prove more things, so it allows better handling of GATs, so it allows better handling of async, where you get "impl Future<Output = T>"-s everywhere.

But also somewhere there is that the ergonomics of async/.await are still not very much in progress too. With better error messages people will be able to forego Box<>-ing and figure out what to use instead, and only heap allocate where they must.

It's possible to write low-level async code with hand rolled-polled Futures, and push/manage as much stuff on the stack as possible. But ... that takes time, and performance is already "good enough". (And/or probably there are bigger gains in performance in other areas, such as scheduling.)

And, finally, boxing helps with compile times. (Because it's basically trivial for the compile to prove that a heap allocated simple trait object behaves well compared to a stack allocated concrete, but usually highly complex (plus unnameable) type.)

My bet is people choose to allocate heavily rather than figure out how to share memory correctly with Rust. I need to learn more rust to get a hang of it so I don't allocate so much.

Are there any rust folks who have a great "list of memory management models for rust"?

The only place that the langs you mention probably win is: learning curve (F# maybe not so much) a.k.a. getting language illiterate people up to speed, and compile times.

A clean static rendering system with caching, built on top of react / svelte / whatever performs well enough for almost everyone. And every year cpu costs drop, V8 gets faster and JS libraries get a little bit more mature.

I love rust, but I don’t see it displacing nodejs any time soon. Maybe when websites can be 100% wasm and the rust web framework ecosystem matures some more. Fingers crossed, but I’m not holding my breath.

I was in particular benchmarking ECC, which is much harder to optimize in JS (and in general).

Code is here:

JS: https://github.com/bcoin-org/bcrypto/tree/master/lib/js

C: https://github.com/bcoin-org/libtorsion

To benchmark:

    $ git clone https://github.com/bcoin-org/bcrypto
    $ cd bcrypto
    $ npm install
    $ node bench/ec.js -f 'secp256k1 verify' -B js

    $ git clone https://github.com/bcoin-org/libtorsion
    $ cd libtorsion
    $ cmake . && make
    $ ./torsion_bench
    $ make -f Makefile.wasi SDK=/path/to/wasi-sdk
    $ ./scripts/run-wasi.sh torsion_bench.wasm ecdsa

He wants WASM to be closer to C performance. I.e. to move further along this line:

    |JS|========>|WASM|=========>=========>========>|C|

It's not a matter of speed here. It's a matter of enabling certain types of programs which are borderline impossible with pure JS runtimes.

So I will probably move most of the logic to Rust

Plus things like competitive games and what I'll call "pretty" games have to squeeze out as much performance as possible, and no hitching is acceptable to competitive games, which IMO means WASM is still a no-go for those types of games(although games that don't have this requirement undoubtedly benefit)

Does firefox have a headless mode, a standalone implementation, or some CLI tool I can use to run a WASM binary? Running stuff in the browser is cumbersome.

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

They even say asm.js is supposed to be "near-native code execution speeds". In my experience, it is no where close to native speed. People should avoid this kind of deceptive marketing.

[1] https://github.com/datamllab/rlcard

[2] https://onnx.ai/

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!

JS is pretty fast if you use TypedArrays, are careful with WebGL calls and pool objects (reduce memory allocations).

https://codesandbox.io/s/is849

edit: complete code

```typescript

class Person { id: number; name: string; yearOfBirth: number;

    constructor(id: number, name: string, yearOfBirth: number) {
        this.id  = id;
        this.name = name;
        if (yearOfBirth < 1900 || yearOfBirth > 2020) {
            throw new Error("I don't understand you. Go back to your time machine.");
        } else {
            this.yearOfBirth = yearOfBirth;
        }
    }

    getAge(): number {
        const currentDate: number = new Date().getUTCFullYear();
        return currentDate - this.yearOfBirth;
    }

class Dog { id: number; name: string; yearOfBirth: number;

    constructor(id: number, name: string, yearOfBirth: number) {
        this.id  = id;
        this.name = name;
        if (yearOfBirth < 1947 || yearOfBirth > 2020) {
            throw new Error("I don't understand you. Go back to your time machine.");
        } else {
            this.yearOfBirth = yearOfBirth;
        }
    }

    getAge(): number {
        const currentDate: number = new Date().getUTCFullYear();
        return (currentDate - this.yearOfBirth) * 7;
    }

const buzz: Person = new Person(1, `Buzz`, 1987);

const airbud: Dog = buzz;

console.log(`Buzz is ${buzz.getAge()} years old.`);

console.log(`Airbud is ${airbud.getAge()} years old in human years.`);

```

It's funny you mention enums, there was just another thread last week where I brought up how crazy it is that sum types (Rust enums) and pattern matching have been around since the 70s but have largely been limited to the FP languages. After extensively using Rust for ~3 years now, I don't ever want to use a language without sum types - you can write incredibly expressive and concise code with them.

The other major productivity boost for me is the ability to compose and chain Iterators and mix those with collection types.

This isn't a criticism of Rust; it's specifically designed for applications where those things do matter. But for the overwhelming majority of apps they don't, and I'd reach for a different tool.

I've found that once I get into a rhythm and I've been working on something in Rust for a bit, it doesn't feel that hard to deal with all that. And a few times I've thought to myself "hey maybe the GC isn't actually buying you all that much?" But then I go back to a GC'd language and watch just how much faster stuff gets done. It's not even close. I think it's one of these things where your brain doesn't notice the time that goes by when you're doing what is essentially mindless busywork.

Part of this is also having come from doing a fair bit of stuff in Haskell, Elm, and a bit of OCaml; the best "high-level" language features are inspired by that language family (including enums) and so it feels like a better control for the difference a GC makes vs. js and friends. It makes a big difference.

Where Rust diverges is when you're doing async or multithreaded things with complicate lifetimes.

Getting things right from the start instead of solving them JIT as runtime issues pop up in production over the course of the year is Rust's wheelhouse. But even after using Rust for three years, I sometimes feel like I'm one requirement-change away from a problem I can't solve myself in Rust where I could solve it in a couple hours in another language.

> Working in other languages feels like going back to assembly

This is not a preference, it is an exaggeration and an attack on all other languages.

It is also quite ironic given Rust is intended for low level programming.

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.

Languages compiled to wasm have an FFI cost, and we will never fully remove it because it just uses different types than Web APIs do. This isn't a Rust problem or a C problem, it's just how wasm is.

Wasm also can't use the JS standard library, and usually ends up shipping some runtime support, like malloc or string handling, which increases download size.

Both of those limitations are why wasm won't make sense for the great majority of web dev work. But wasm shines for "engine" type code, like in this post - pure computation, without lots of links to the outside JS/DOM world.

Asking out of ignorance!

LLVM as a toolchain provides backends for many target machines, so as a compiler author you can just emit LLVM IR and (mostly)automatically be able to compile for x86, arm, mips, etc... And they have a wasm backend too, so the technologies are complementary -- you can use LLVM to compile to wasm. LLVM will do a fair bit of optimization too. The intent with LLVM is not to provide a portable binary distribution format, but to allow different compiler frontends to all share the same compiler backend logic.

By contrast, with WASM the assumption is that by the time it gets to the browser the ahead-of-time compiler has already done a fair bit of optimization, so what a wasm compiler has to do is much simpler.

WASM is also designed for space efficiency, since the code will be shipped over the network, and safety -- LLVM has a C-like notion of undefined behavior (which the optimizer makes use of), but this would be wildly inappropriate for WASM due to security (and portability) concerns.

When this transition period goes away, LLVM should hopefully compile to WASM binary as a target. The current path described in the video of WASM -> C -> clang -> llvm -> native-binary is a temporary workaround afaik.

UPD: modern JS engines are extremely capable of optimizing stuff and they can probably come up with machine code similar to what Rust or C will produce given that you keep your code predictable and optimization-friendly.

We did do a benchmark[3] and, unless we made an error (likely, given that all of us are new to WASM), found that JS was much faster for our simple algorithms. WASM had the approximate performance of our original pure Python implementation[4], so not great.

[1]: https://dnavisualization.org [2]: https://academic.oup.com/nar/article/47/W1/W20/5512090 [3]: https://github.com/Lab41/dnaviz/tree/benchmarks/benchmarks/a.... [4]: https://github.com/Lab41/squiggle

I'm not sure how to answer your question regarding whether Vapor is viable for indie hackers, because I've only been skimming the docs and looking at small examples. But it seems to draw a lot of inspiration from Express.js and/or Ruby's Sinatra library. It doesn't seem to have the up-front complexity of something like Java's Spring Framework, although I understand you can use services and dependency injection if needed. So my first impression is it's easy to get started, but it enables you to refactor to something more complex if your application demands it.

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.

This is a forum for engineers (not only, I know), who collectively will at least have a large part in steering what languages are considered common in future.

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.