|
I did a lot of stuff with Django and Flask. On current project I was free to choose a platform, so I went with Rocket. The framework itself is similar to Flask in productivity and amount of boilerplate, though it's even better. It converts all input data to proper types for you using type signatures of handlers. So I don't need to convert strings into ints, or into json and then check if it conforms to a schema. If handler is called, input is parsed and converted. Rust itself is more verbose than python. Typical data manipulation, like put something in dict, extract/count uniques, "transpose" a datastructure, load data from file, usually takes 1.5x-3x as much chars. For this price you get strict compile-time type checks that take lots and lots of mental load off code refactoring, C++ level performance, and real multithreading, including easy data parallelism with libs like rayon. Rust also has enums (aka algebraic types or tagged unions) that can help to represent problem space better and make fewer logic mistakes later. It would be all unicorns and rainbows for me if a more concise database interface was awailable. Currently the go-to ORM is Diesel, and it's very verbose comparing to, say, python's sqlalchemy. Current solution is to move database access from views into methods of a model. About iteration: code requires recompilation. Changes to non-compiled templates do not. I use Maud templates and they make html look suprisingly clean, they compile and are fast, but well, you need to recompile them every time. Currently debug build takes ~10s, though parsing and typecheking are done in the first several seconds. Diesel doesn't support async yet, AFAIK. But async is usually used to save on context switches and stack space, allowing to support tens of thousands of live connections. You won't ever have tens of thousands of connections to database like Postgres. 100 connections is quite generous. 500 connections may be possible on the fattest DB boxes. Postgres is not async itself, it allocates a 4MB scratch buffer for each client from the start, IIRC. The only good reason to use async for communication with postgres may be if all of your other code is async and you don't want to deal with sync/async impedance mismatch. Though you'll likely want have connection pool anyway. About IDEs I can't say much, I use emacs with LSP, it works most of the time. |