I read the discussion above and my conclusion is that the most important thing about programming is the algorithms.
I 100% agree with you.
And today, programmers forget about algorithms. They just use the language.
In a recent discussion here, we got a good proof of it:
https://forum.lazarus.freepascal.org/index.php/topic,61035.msg461281.html#msg461281 The use case of this test program is to load two big CSVs into memory, then serve over HTTP some JSON generated by route identifiers, joining both CSVs.
The "modern" / "school" approach, as implemented in the reference project in Go/Rust/C#/... is using two lists for the CSVs data, then two maps/dictionaries between route ID and lists indexes.
This is fine, but for the "mORMot" version in FPC, I used another approach, with two diverse algorithms:
- I ensured the lists were sorted in memory, then made a O(log(n)) binary lookup in it;
- All stored strings were "interned", i.e. the same text was sharing a single string instance, and FPC reference counting did its magic.
There is no low-level tricks like generating the JSON by hand or using complex data structures (they still are high-level)
As a result:
- It uses much less memory - 10 times less memory;
- Performance is as fast as Go, and its very tuned/optimized compiler and RTL.

Main idea was to let the algorithms match the input data and the expected resultset.
As programmers do when programming games. Not as coders do when pissing out business or governmental software.

The source code is still pretty readable, thanks to using mORMot efficient TDynArray to map the dynamic array storage, and its CSV and JSON abilities.
I guess source is still understandable for out-of-school programmers - much more readable than Rust for instance. To by fair, I used typed pointers in TScheduler.BuildTripResponse but it is not so hard getting their purpose, and FPC compiles this function into very efficient assembly. I could have used regular dynamic array access with indexes, it would have been slightly slower, but not really easier to follow, nor safer (if we compile with no range checking).
https://github.com/synopse/mORMot2/tree/master/ex/lang-cmpHere are the numbers for memory:
Upon finished loading the CSV, mORMot only eats 80MB, heck so little. Sounds a bit magical. But during load test, it fluctuates between 250-350MB, upon which it returns to 80MB at the end.
The Go version eats 925MB upon finished loading the CSV. During load test, it tops at 1.5GB, returning to 925MB afterwards.
And to be fair, a regular/business/governmental coder would have used a database for this. Not silly memory structures. And asked for money on HW.

It is not only about Pascal, it is about algorithms and libraries, but this sample was initially to compare them. Not only as unrealistic micro-benchmarks, or "computer language benchmark games", but as data processing abilities on a real usecase.
And... pascal is still in the race for sure! Not only for "old" people like me - I just got 50 years old.

The more we spread such kind of information, the less people would make jokes about pascal programmers.