Live data from Hacker News

ExpressJS vs. Actix-Web: performance and running cost comparison

medium.com

11–20 of 58 posts

Re: ExpressJS vs. Actix-Web: performance and running cost comparison

#11

I understand that using Actix really highlights the speed advantage of Rust... but I think it's irresponsible to encourage rewrites in Rust using a framework that's dead because the developer decided to quit instead of fix security issues[0]. The last thing we need is a bunch of new Rust devs rewriting their perfectly fine Node code using an insecure framework. Rust is really fast, especially compared to Node. This i…

Express.js active development seems to stop. The last commit on v5 branch was from October 2018. We are still waiting for http2 (2 years) or better support for promises (3 years).

  https://github.com/expressjs/express/tree/5.0
  https://github.com/expressjs/express/pull/4196
  https://github.com/expressjs/express/issues/2761
If someone is doing a new project in node I would recommend:

  https://github.com/fastify/fastify
  https://github.com/hapijs/hapi
In the above benchmark, fastify would probably narrow the gap.

  https://www.fastify.io/benchmarks/

Re: ExpressJS vs. Actix-Web: performance and running cost comparison

#12

Actix is really great, easily the best web framework for Rust. Too bad a small band of vocal Rust safety talibans drove away the creator ( https://news.ycombinator.com/user?id=fafhrd91 ). This is why we can't have nice things. :(

“Safety talibans” is flamebait which will only distract from the topic

Re: ExpressJS vs. Actix-Web: performance and running cost comparison

#13
post #5

Earlier quoted context omitted.

It's the only web framework in Rust that has thus far reached maintenance mode because it became feature complete, was heavily vetted by many teams, and is architecturally mature. It's not just really fast but has all of the bells and whistles. Further, people are actively contributing to the project. Replacing remaining sound yet unsafe blocks with fully safe rust, without taxing performance, is the remaining, ongoi…

> Your claims about being dead are wildly exaggerated and misleading. I’d say they’re outdated. The project after the original author was frustrated with some in the community, found a way to allow the project to continue, which is overall good, but still a very disappointing episode.

Yes, indeed, but calling it dead and accusing the OP of acting irresponsible requires attention.

What happened to Nikolay could happen to anyone who stands up for one's craftsmanship and refuses to change out of principle. You, or anyone, can wind up being targeted.

Re: ExpressJS vs. Actix-Web: performance and running cost comparison

#15
Can someone ELI5 the node code sample?

> full = full == "true";

Umm.. Why?

> if (!!limit

Not not limit? Is this due to some corner case conversion for JS to make 100% sure this gets into a boolean..?

I'm sure both samples have its reasoning, I'm just not aware. Any help please?

Re: ExpressJS vs. Actix-Web: performance and running cost comparison

#16
post #13

Earlier quoted context omitted.

> Your claims about being dead are wildly exaggerated and misleading. I’d say they’re outdated. The project after the original author was frustrated with some in the community, found a way to allow the project to continue, which is overall good, but still a very disappointing episode.

Yes, indeed, but calling it dead and accusing the OP of acting irresponsible requires attention. What happened to Nikolay could happen to anyone who stands up for one's craftsmanship and refuses to change out of principle. You, or anyone, can wind up being targeted.

I agree. I wanted to make sure it was clear why people might have the misunderstanding that the project development isn’t continuing. I think it’s worth directly correcting that perspective.

Re: ExpressJS vs. Actix-Web: performance and running cost comparison

#17

Can someone ELI5 the node code sample? > full = full == "true"; Umm.. Why? > if (!!limit Not not limit? Is this due to some corner case conversion for JS to make 100% sure this gets into a boolean..? I'm sure both samples have its reasoning, I'm just not aware. Any help please?

[deleted]

Re: ExpressJS vs. Actix-Web: performance and running cost comparison

#18

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.

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?

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.

Re: ExpressJS vs. Actix-Web: performance and running cost comparison

#19

Can someone ELI5 the node code sample? > full = full == "true"; Umm.. Why? > if (!!limit Not not limit? Is this due to some corner case conversion for JS to make 100% sure this gets into a boolean..? I'm sure both samples have its reasoning, I'm just not aware. Any help please?

They are both ways to convert values to booleans. The top line would convert a string to a boolean. !! is a standard JS idiom to convert any value to its boolean equivalent, which can be somewhat complex due to the notions of "truthy" and "falsey" in JS.

Re: ExpressJS vs. Actix-Web: performance and running cost comparison

#20

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.

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?

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.

Post reply on HN