I had a play with rust at the start of the year while I was evaluating if it would be good for the api backend for my new website. I was using rocket as a framework. The language itself seemed quite ready for use and the book was very helpful but I found all the libraries I needed were half finished and didn't have the features I needed or if they did they had docs that assume you will read the source code and work most of it out yourself. I spent ages trying to work out how to set up postgres with it and got stuck on stuff about connection pools and multithreading.
I ended up just using rails in api mode which is a shame because it chews up the limited memory on my server.
Most of these issues would go away if I was a rust pro and I could just write my own libraries and read the source but it really didn't feel like rust was helping me become productive fast like ruby did.
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.
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.
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”).
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.
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.
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?
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.
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.
Maybe. I also tried Haskell and Yesod but had the same issues. It seems the size of the userbase for a language/framework massively impacts how fast I can do things. With haskell I was posting multiple questions on stack overflow every day but with ruby I find almost everything I need already answered.
I ended up just using rails in api mode which is a shame because it chews up the limited memory on my server.
Most of these issues would go away if I was a rust pro and I could just write my own libraries and read the source but it really didn't feel like rust was helping me become productive fast like ruby did.