[jakelazaroff]

Is there any surprise here? Anecdotally Node seems fast for interpreters, but of course a compiled systems language like Rust blows it away. That’s a known trade off you make when picking a technology like Node; there are plenty of other reasons to use it.

[jankassens]

Even if you think a compiled language will be faster, it might still be interesting by roughly how much (5%, 10x or 100x?). This can help make the trade off decision.

[jasondclinton]

I can only think of ecosystem size and language familiarity. Authors addressed development speed and found that Rust's static typing and compiler checks reduced development time vs JS. What other reasons did you have in mind?

[throwaway894345]

I’m skeptical of this finding out at least it’s generalizability. I know (and like) Rust a fair bit better than JS, but I would be surprised if I could build a nontrivial web app in Rust faster than Node. And that’s without using TypeScript. YMMV, but I’d be curious to hear from others with experience with both languages.

[hombre_fatal]

I've used Rust for two years and still regularly get stumped.

Recently, I wanted to maintain a map of routes to futures so that multiple in-flight requests could await the same future while it fetches from disk.

The Javascript version took about one minute.

Using Rust doesn't give you free performance wins, especially not when working with async code where lifetimes actually get hard. Any time you're carrying around your own event loop / cpu pool while trying to avoid blocking requests, that's also another bombshell in itself. Similar challenges when using something like NIO/Netty, especially towards the beginning.

Add things like sinking a stream of lazy futures into a response and it can be very hard to understand what your actual performance looks like and where things will block, especially with parallel requests. The only way you could say it's a free lunch is if you're a Rust expert who has done it before, which doesn't apply if you're considering Rust vs JS/TS anyways.

Not to say nobody out there should be writing Rust, that would be silly. But someone upstream is seriously asking what advantages JS could have over Rust and difficulty is one of them. And it's not a small one.

[Dowwie]

My first attempts with anything in Rust are also challenging. Second attempts, though, are straightforward as long as I have an example to work from and haven't forgotten about it. It would take me a lot longer to build your router example in Node than it did you because I haven't worked with Node but once I know how, maybe it would take me a minute, too.

What did you finally come up with for your router impl in Rust?

[kaoD]

I'm fluent in both Rust and JS. IMHO first attempts are much faster in JS than in Rust. Rust is much easier to maintain in the long term, and for large scale codebases it excels once the groundwork has been laid.

[eropple]

JavaScript isn’t the only way to write Node.

I know Rust alright, and I like it. I’d rather write TypeScript for most web applications and I write good and solid TypeScript a lot faster than I do Rust. (Helps that I can easily write the same language and use many of the same libraries on my frontend, too.)

[hn_throwaway_99]

A common language across front and backend systems is a huge benefit. I find it extremely productive to have a backend in Typescript on NodeJS, and a frontend in ReactJS, talking over a GraphQL layer where I'm autogenerating Typescript types from the GraphQL typedefs. Means I can share many libraries and tooling across the front and back ends, but most importantly it means devs feel much more comfortable digging into code on the other side. If a front end dev has an issue with a backend API call, he can just pull down the code and instantly inspect it and submit a PR of necessary without feeling "out of his element".

[ttty]

How you generate the types from graphql. I noticed most of the generators create types with all optional keys. Do basically you need to check all the time...

[hn_throwaway_99]

If they're creating types with optional keys it's probably because that's how you're defining your types in GraphQL. E.g. with

type Foo { bar: String }

bar would be optional in the Typescript type because it's specified as optional in the GraphQL type. You would need to do the following to make it required:

type Foo { bar: String! }

[ttty]

I mean... All keys can be optimal in reality, but in real world you can't put all non optional because defeats the purpose of graphql.

[jakelazaroff]

Development speed is one. If the author were more familiar with JavaScript (e.g. knowing what const does) it might have gone faster. Using TypeScript should erase the development time delta due to static types.

If you're creating a frontend web app to go along with it there are others, such as reduced context–switching and using fewer tools.

Frankly, a sample size of one is incredibly weak evidence that it's faster to develop using one technology than another. If you glance through the author's Twitter/GitHub it's also clear that he works with Rust significantly more than he does with Node, which makes this particular sample even more suspect.

[dunnock]

Indeed I am working primarily on Rust now, though I used to write Node 2 years ago and this is one of pitfalls where I would like to rely on compiler. It was just one issue which could been easily detected. Some debugging time was spent aligning SQL query parameters and mapping selected fields to the output type - the problem is that when there is some misalignment node does not raise exception, rather just passing undefined value. That's what takes time, to realize that there is a problem and then find the issue. Agreed that in general expert in node probably won't hit such issues, though how many experts do we have. Type safety checks, including runtime checks, are actually making technology more adoptable. It does not seem that typescript can do that well though.

[hombre_fatal]

Another upside: you'll never be stumped implementing something in Javascript/TS. There is no lifetime management. And the entire ecosystem is async-everything. You aren't stuck in an async-ready subecosystem like you are in Rust, Python's Twisted, Ruby's Event Machine, etc.

[nazka]

Well it’s rust and actix so ya no big surprise. But take a look at es4x. It actually blows away Nodejs and many other compiled languages/web frameworks. And it’s in JS! They are in the most recent benchmark of TechEmpower.