Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Case Study: Npm uses Rust for its CPU-bound bottlenecks [pdf]

rust-lang.org

Post reply on HN
Print view View original

281–290 of 307 posts

Re: Case Study: Npm uses Rust for its CPU-bound bottlenecks [pdf]

#281

Post by pjmlp »

Impossible wrote: post #275
ndesaulniers wrote: post #268

Earlier quoted context omitted.

> I tried too much to use OOP, which doesn't make any sense and leads to convoluted code. Oh, well, you don't need Rust for that! :P

Yes the same is true with C++ or C# for example, which is were the move out away from OOP and towards DOD/ECS started.

Which is ironic, given that people tend to forget that it was C++ which made OOP mainstream, there wasn't any Java or C# back then, two fully OOP based languages.

The other part is that component oriented programming is actually a branch of OOP, from CS point of view, with books published on the subject at the beginning of the century.

"Component Software: Beyond Object-Oriented Programming"

https://www.amazon.com/Component-Software-Beyond-Object-Orie...

First edition uses Component Pascal, Java and C++, with the 2nd edition replacing Component Pascal for C#.

Re: Case Study: Npm uses Rust for its CPU-bound bottlenecks [pdf]

#282

Post by [deleted] »

twiss wrote: post #23
nothrabannosir wrote: post #10

This entire article is a pretty damning report on JavaScript in general, but this sentence takes the cake (emphasis mine): > The process of deploying the new Rust service was straight-forward, and soon they were able to forget about the Rust service because it caused so few operational issues. At npm, the usual experience of deploying a JavaScript service to production was that the service would need extensive monito…

They also state that writing the service in Node took them an hour, two days for Go, and a week for Rust. Even taking into account their unfamiliarity with the language, it's probably fair to say that when switching to Rust, you'll usually spend more time writing and less time debugging. Whether that trade-off is worth it depends on the project.

[deleted]

Re: Case Study: Npm uses Rust for its CPU-bound bottlenecks [pdf]

#283

Post by [deleted] »

pjc50 wrote: post #220
twiss wrote: post #23

Earlier quoted context omitted.

They also state that writing the service in Node took them an hour, two days for Go, and a week for Rust. Even taking into account their unfamiliarity with the language, it's probably fair to say that when switching to Rust, you'll usually spend more time writing and less time debugging. Whether that trade-off is worth it depends on the project.

> writing the service in Node took them an hour I'm really skeptical of this unless it's just a wrapper for a thing that happens to already exist. It would be interesting to have comparative LOC numbers. > At npm, the usual experience of deploying a JavaScript service to production was that the service would need extensive monitoring for errors and excessive resource usage necessitating debugging and restarts So, the…

[deleted]

Re: Case Study: Npm uses Rust for its CPU-bound bottlenecks [pdf]

#284

Post by majewsky »

z3t4 wrote: post #183
fpgaminer wrote: post #160

Earlier quoted context omitted.

I wrote and deployed a production service written in pre-1.0 Rust. In over three years of being deployed I never once had to touch that code. The infrastructure around it evolved several times, we even moved cloud providers in that time, but that particular service didn't need any changes or maintenance. It just kept chugging along. Perhaps Rust's name is apropos: your code will be so reliable that you won't need to…

Never touched code is seldom a sign of quality. But there's the old saying; if it ain't broken, don't fix it.

When code is never touched, it's usually because its business requirements don't change.

Re: Case Study: Npm uses Rust for its CPU-bound bottlenecks [pdf]

#285

Post by Rotareti »

ISO-morphism wrote: post #165
atoav wrote: post #50

Earlier quoted context omitted.

Rust's package managment (cargo) is the best thing I have ever seen of it's kind. The very basic thing you can do is: cargo new funkyproject Which creates a new barebones rust project called "funkyproject". Every dependency specified in it's Cargo.toml will be automatically downloaded at build (if there is a new version). When a build is sucessful the versions of said dependency will be saved into a Cargo.lock file.…

I think Poetry [1] is the most promising in the python build/dependency space. I've used pipenv and left dissatisfied. [1] https://github.com/sdispater/poetry

I gave poetry a try and liked it a lot as well, but I really miss the virtualenv handling from pipenv. How do you handle virtualenvs with poetry?

Re: Case Study: Npm uses Rust for its CPU-bound bottlenecks [pdf]

#286

Post by majewsky »

scns wrote: post #218
ambicapter wrote: post #161

Earlier quoted context omitted.

Do you have any advice for PHP best practices? I'm starting a job that will probably have me using PHP...

https://phptherightway.com/ http://www.phpthewrongway.com/ https://paragonie.com/blog/2017/12/2018-guide-building-secur... Edit: formatting

I find it funny that the "right way" link has HTTPS whereas the "wrong way" link doesn't.

Re: Case Study: Npm uses Rust for its CPU-bound bottlenecks [pdf]

#287

Post by Corrado »

arhyth wrote: post #258

can someone please give this outsider-noob an eli5 explanation why golang do not adopt a same policy/attitude/implementation towards package management?

Go is being developed by Google and as such is designed to meet their needs. Google's view of package management is to bring every package in-house and manage it themselves. So, if a Go program needs package "A" then Google will directly import that package into their workflow.

This is actually one of the reasons that I don't think Go is a very good language for most people/organizations. It was conceived with a specific set of guidelines that Google needed; easy to learn, performant, etc. Go is also designed to be used by teams of thousands, so it's much easier to adopt misc packages into the fold and maintain them than it is to manage links to outside requirements.

Re: Case Study: Npm uses Rust for its CPU-bound bottlenecks [pdf]

#288

Post by imtringued »

cryptica wrote: post #238

The idea that some programming languages can solve scalability issues is a myth. A language cannot solve scalability issues; all they can do is push the needle a tiny little bit further in terms of performance but this is completely meaningless. Scalability is an architectural concern which cannot be ignored by system developers. This is because scalability is not about speed or performance, it's all about figuring o…

I don't understand the criticism of thread pools. Their only purpose is to avoid the expensive creation of threads. They don't do anything by themselves.

Re: Case Study: Npm uses Rust for its CPU-bound bottlenecks [pdf]

#289

Post by z3t4 »

majewsky wrote: post #284
z3t4 wrote: post #183

Earlier quoted context omitted.

Never touched code is seldom a sign of quality. But there's the old saying; if it ain't broken, don't fix it.

When code is never touched, it's usually because its business requirements don't change.

Or everyone is too afraid to touch it.

Re: Case Study: Npm uses Rust for its CPU-bound bottlenecks [pdf]

#290

Post by lllr_finger »

bluejekyll wrote: post #136
lllr_finger wrote: post #118

Earlier quoted context omitted.

Do you mean static typing?

The distinction in the vernacular between statically typed and strongly typed languages is so narrow at this point that pointing it out is a bit pedantic. I would say Rust is both a strongly typed language and a statically typed language. The static type checking happens at compile time, and in general the types in use are strict and strongly typed at runtime. But, even Rust allows you to cast types from one to anoth…

It wasn't intended as a drive-by pedantic swipe - I was genuinely curious whether OP meant strong or static. Conversations about type systems and application correctness are exactly the place where precise definitions are welcomed, but I understand that the distinction between strong and static is often conflated. It can be relevant if we're discussing static typing for example, as then something like TypeScript becomes useful.

There's a great writeup by one of the C# people (I want to say it was Erik Meijer, but I'm having a hard time finding it atm) about the distinctions we're discussing here, their relevance to correctness, and the impact on ergonomics. My takeaway from it was that occasionally you will encounter problems that are easier to solve with some freedom and that's why strong/static languages like C#/Rust include pragmatic escape hatches like the dynamic object and the Any trait (respectively).

Post reply on HN