Rocket v0.4: Typed URIs, Database Support, Revamped Queries

That's just my opinion, of course.

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.

Those three things are very appealing, whether it's web or anything else.

It's also the brave new world that lies behind us. Doom, one of the most influential computer games due to technical innovation, was created by a team of 3 programmers (and 8 non-programmers).

Small teams of brilliant people can produce phenonemal results. Unfortunately in big companies a manager is not only measured by his results, but also by his budget and the number of people under him. The division of 100 people simply looks more impressive than the room of 10. So you end up hiring lots of (at best) mediocre programmers, pay them as little as possible, and use big architectures and processes designed to cope with idiots (Enterprise architectures and Enterprise processes, as we call them).

Clayton Christen wrote about this in 1997 with "The Innovator's Dilemma". He believed it was still repeatable in large organizations via 'intrapreneurship', which I'm not convinced is entirely true... considering the enterprises continued obsession with middle management and hierarchy, and top-down R&D.