It's very minimal-boilerplate. It's done an exceptional job of eliminating procedural, tedious work, and it's done it in a way that doesn't even require macros! "Template Haskell" is Haskell's macro system and it's rarely used anymore.
These days, people mostly use things like GHC.Generics (generic programming for stuff like serialization that typically ends up being free performance-wise), newtypes and DerivingVia, the powerful and very generalized type system, and so on.
If you've ever run into a problem and thought "this seems tedious and repetitive", the probability that you could straightforwardly fix that is probably higher in Haskell than in any other language except maybe a Lisp.
> Why hasn't there been a minimal-boilerplate language and framework and programming environment?
Haskell mostly solves boilerplate in a typed way and Lisp mostly solves it in an untyped way (I know, I know, roughly speaking).
To put it bluntly, there's an intellectual difficulty barrier associated with understanding problems well enough to systematize away boilerplate and use these languages effectively.
The difficulty gap between writing a ton of boilerplate in Java and completely eliminating that boilerplate in Haskell is roughly analogous to the difficulty gap between bolting on the wheels at a car factory and programming a robot to bolt on the wheels for you. (The GHC compiler devs might be the robot manufacturers in this analogy.) The latter is obviously harder, and despite the labor savings, sometimes the economics of hiring a guy to sit there bolting on wheels still works out.
I can construct even more compelling arguments for the uselessness or active harmfulness of most tech jobs.
The only "actually useful" tech jobs if we're going to consistently apply a bar that excludes finance would be stuff like aerospace R&D or ERM systems. Which, to be clear, I would love if society incentivized more strongly. But finance is hardly the worst offender here.
I used to work there, so with the appropriate deference to that Upton Sinclair quote about paychecks:
Market makers like JS vastly increase market liquidity across all sectors, which is required for modern high-efficiency economies to work. McDonalds prices are possible because there's enough liquidity in corn futures.
More abstractly, high market liquidity corresponds to higher-confidence information about the future, which hedge funds generate (and distribute for a low fee via markets), allowing for more impressive planning ahead.
Also, you know how when you buy stocks it doesn't cost you anything and you often get better-than-public-book execution prices? That didn't happen prior to modern electronic market makers. Multiply that efficiency gain by umpteen trades every day.
In general, "being in the business of making money" inherently requires you to do something useful to get paid, to the extent you're not just abusing a principle agent problem or something. The most credible argument for hedge funds making money without doing something useful is that they're doing cantillon effect harvesting or something. I think that's pretty small overall.
Presumably a caching server would be 10GbE, 40GbE, or 100GbE
56Gbit/sec of pre-generated data is definitely something that you can handle from 1 or 2 decent servers, assuming each request doesn't generate a huge number of random disk reads or something
> I don't see how super duper auto complete will lead to AGI
Autocomplete is the training algorithm, not what the model "actually does". Autocomplete was chosen because it has an obvious training procedure and it generalizes well to non-autocomplete stuff.
These days, people mostly use things like GHC.Generics (generic programming for stuff like serialization that typically ends up being free performance-wise), newtypes and DerivingVia, the powerful and very generalized type system, and so on.
If you've ever run into a problem and thought "this seems tedious and repetitive", the probability that you could straightforwardly fix that is probably higher in Haskell than in any other language except maybe a Lisp.