[ilovecaching]

Ruby is also a dynamically type, interpreted language with a GIL, that's much older than Rust. You're sacrificing a lot in terms of speed and correctness up front to get something that's easier to jump into.

Rust crates should have documentation though. Rust has great tooling around writing docs in comments and generating the documentation from those. Rust is also statically typed, which makes it easier to reason about what a function does without the docs. In fact, lifetimes give you even more information about the relationship between inputs and outputs than a normal statically typed language.

[user111233]

I have never felt a typed language slows me down. In a dynamic language you still have to mentally understand what the type of a function is. You can't just throw any data in to it and have it work.

[dxhdr]

> In a dynamic language you still have to mentally understand what the type of a function is. You can't just throw any data in to it and have it work.

JavaScript would like a word with you.

[MaulingMonkey]

If you could just throw any data into JavaScript functions and have it work, we wouldn't need TypeScript.

[ilovecaching]

The poster is poking fun of the fact that you can partially apply or over apply a JavaScript function and it will still run.

[ovao]

One often doesn’t need TypeScript. TS solves some classes of problems that would otherwise become crippling in projects of certain sizes and of certain levels of complexity, but, by design, JavaScript tends to happily let you throw any data into functions and have it work (by some definition of “work”).

[user111233]

If you define work as not throwing an error. You can't just put anything in to a function and have it return a useful result. Thats why typed language programs like haskell programs often define datatypes that are just an Int because user_id is not the same kind of data as product_id even if they are just an int.

[TylerE]

Are you?

Every app I've ever written that talks to postgres spends way more time...waiting on postgres than doing anything else.

It's like the joke about getting a faster processor so you're 99% idle instead of 95% idle.

[sanderjd]

I always found it easier to improve the time waiting for postgres by tuning critical queries than to track down runaway memory usage and tune garbage collection. I also felt like I spent a lot of my wall clock time during active development waiting for apps to start up and run tests or whatever. There are best practices which speak to most of this, but they were hard won.

[bb88]

But that doesn't come for free with Rust. You still have optimize the DB. And then does it really matter which language you use, since the DB is still going consume most of the time generating a web page anyway, right?

[sanderjd]

My point was that I found the database to be the easier bottleneck to optimize. The other bottlenecks I mentioned, which I found more difficult to optimize - memory usage, GC, and startup time - are things for which Rust has a good story.

[iopq]

You should really be memcaching the database aggressively. I got it to the point that PHP was taking more time than the database for most pages because most pages DON'T need to be updated that frequently.