my two cents for C++:
-Anything where you revert back to C-style memory-management and wonder why the code is so complex/segfaulty
const fs = require("fs");
const filename = process.argv[2];
const fileContents = fs.readFileSync(filename, "utf8");
const output = munge(fileContents);
process.stdout.write(output);
// This API is still experimental
const fs = require("fs").promises;
// This will become unnecessary when top-level await is supported
run().catch((err) => console.error(err));
async function run() {
const filename = process.argv[2];
const fileContents = await fs.readFile(filename, "utf8");
const output = munge(fileContents);
process.stdout.write(output);
}
And yeah, async/await helps, but is unambiguously ergonomically worse than:
import csv
incsv = csv.reader(open('file1.csv'))
outcsv = csv.writer(open('file2.csv', 'w'))
for row in incsv:
outcsv.writerow([row[0], row[1] + ' blah'])
I'm not saying it's not possible to do it in JS, just that it's not a task that plays to JS's ergonomic strengths, just like it's possible to write a linked list in Rust but kind of sucks.
const fs = require("fs");
const csv = require("some-csv-package");
const incsv = csv.reader(fs.createReadStream("file1.csv"));
const outcsv = csv.writer(fs.createWriteStream("file2.csv"));
for await (row of incsv) {
await outcsv.writeRow([ row[0], `${row[1]} blah` ]);
}
As for me, none of the scripting I do with Node involves files that exceed Node's 1GB memory limit, so I take the cheap and easy way out and just readFile(). Which I suppose proves your point, although, again, I would argue it's an ecosystem problem, not a ergonomic problem.
Since I'm trying to target not hypothetically bad things, but things I've specifically seen numerous people try, I don't have an answer because I'm not involved enough in that community.
Ten years ago I would have said "anything involving a massive, browser-freezing computation", where "why did this O(n^3) code freeze the browser?" being very common, but I'm not sure if that's current. I'd suspect a newbie armed with a fresh tutorial is more likely to overuse promises nowadays rather than underuse them (i.e., very similar to the Go example I gave; yes, if you're doing a huge computation you may want to break it up but you do not want to literally yield a promise for every integer addition). But those with experience in the community may be able to speak to that.
Twenty years ago it would have been trying to do too much purely in the client side. That's definitely out of date.
(Single Page Apps kinda have an interesting history. They're difficult, and by modern standards, impossible in 1999, and today merely one established option in an array of options, but I wouldn't say it was any one browser advance that changed it... it was a long series of incremental advances. I remember trying to take some relatively intelligent for the time client code for IE4, which at least in theory had a dynamic HTML engine much like today's browsers (albeit one that crashed very, very, very frequently) and make it work in Netscape 4's "layers". Yeowch.)