Yes, it sucks

But GPT-4 would have the same problems, since it uses the same image model

  try {
    // Parallel execution of independent operations
    const [config, userData] = await Promise.all([
      readFile('config.json', 'utf8'),
      fetch('/api/user').then(r => r.json())
    ]);
    ...
  } catch (error) {
    // Structured error logging with context
    ...
  }

This might seem fine at a glance, but a big grip I have with node/js async/promise helper functions is that you can't differ which promise returned/threw an exception.

In this example, if you wanted to handle the `config.json` file not existing, you would need to somehow know what kind of error the `readFile` function can throw, and somehow manage to inspect it in the 'error' variable.

This gets even worse when trying to use something like `Promise.race` to handle promises as they are completed, like:

  const result = Promise.race([op1, op2, op3]);

You need to somehow embed the information about what each promise represents inside the promise result, which usually is done through a wrapper that injects the promise value inside its own response... which is really ugly.

You are probably looking for `Promise.allSettled`[1]. Which, to be fair, becomes quite convulated with destructuring (note that the try-catch is not necessary anymore, since allSettled doesn't "throw"):

  // Parallel execution of independent operations
  const [
    { value: config, reason: configError },
    { value: userData, reason: userDataError },
  ] = await Promise.allSettled([
    readFile('config.json', 'utf8'),
    fetch('/api/user').then(r => r.json())
  ]);

  if (configError) {
    // Error with config
  }

  if (userDataError) {
    // Error with userData
  }

When dealing with multiple parallel tasks that I care about their errors individually, I prefer to start the promises first and then await for their results after all of them are started, that way I can use try catch or be more explicit about resources:

  // Parallel execution of independent operations
  const configPromise = readFile('config.json', 'utf8')
  const userDataPromise = fetch('/api/user').then(r => r.json())

  let config;
  try {
    config = await configPromise
  } catch (err) {
    // Error with config
  }

  let userData;
  try {
    userData = await userDataPromise
  } catch (err) {
    // Error with userData
  }

Edit: added examples for dealing with errors with allSettled

[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

IMO when you do control-flow in catch blocks, you're fighting against the language. You lose Typescripts type-safety, and the whole "if e instanceof ... else throw e"-dance creates too much boilerplate.

If the config file not existing is a handleable case, then write a "loadConfig" function that returns undefined.

YAML sucking is no excuse to keep using XML. JSON, JSON5 and TOML are all great alternatives for projects.

On multiple occasions, I've wanted a standard format that allows large multi-line text blocks to be unquoted. JSON, JSON5, and TOML don't do that. You know what does? YAML and XML. I'm not really a fan of either of them, but where's the better option that still gives me large unquoted text blocks?

I hate toml more than most people, but in fairness it does have two kinds of multiline strings: https://toml.io/en/v1.0.0#string

XML is also game for blocks of text with clumsy <xsl:value-of select='$thing' /> scattered through it for an ad hoc string substitution in those unquoted text blocks. Lua has a nice large blocks of literal text notation too.

Doubtful. JSON has javascript semantics all over it. TOML I've had to look up and seems vaguely fine as such things go, but doesn't have schemas.

XML grows on you. XSL transforms are _probably_ not a good idea but they also kind of grow on you. It turns into html rather easily as well.

I don't see anything preventing the definition of TOML schemas — in TOML, even. There just doesn't appear to be demand for it.

YAML is better than all of those things imo. It is easier for me to read and write and works better with more complex configs when you have mixtures of other types of formats in a single file (e.g. xml, json, bash, etc., which is sometimes useful in Kubernetes).

Your example does not classify as 'undefined behavior'. Something is 'undefined behavior' if it is specified in the language spec, and in such case yes, the language is capable of doing anything including violating memory safety.

This doesn't mean the rest of the 87% enjoy it. Honestly, I'd rather the next survey included a question "are you satisfied with the current error handling approach"

I'm as satisfied with the error handling approach as I am for the email address handling approach, the time of day handling approach, the temperature handling approach, etc.

But that doesn't imply that I am satisfied. I do believe there is a lot of room for improvement. Frankly, I think what we have is quite bad. Framing it as something about errors misses the forest for the trees, though.

How would I respond to your query without misleading the reader?

If you don't care about field access just always write fields with uppercase. Any APIs you're using only expose uppercased variables as well, so it'll stay consistent.

The public/private stuff is mostly useful for publishing modules with sound APIs.

It was not forgotten. Maybe/Either and 'do-notation' are literally what Rust does with Option/Result and '?', and that is mentioned a lot.

That said as mentioned in a lot of places, changing errors to be sum types is not the approach they're looking for, since it would create a split between APIs across the ecosystem.

Where there’s a will there’s a way. Swift is almost universally compatible with objective-c and they are two entirely different languages no less. If an objective-c function has a trailing *error parameter, you can, in swift, call that function using try notation and catch and handle errors idiomatically. All it takes is for one pattern to be consistently expressible by another. Why can’t Result/Either types be api-compatible with functions that return tuples?

As I mentioned, it's the same method Rust uses, and there are multiple reasons on the papers linked on why that is not desired.

I didn't say desired. It would work. Do it and if nobody uses it then so be it. Don’t balk and say “well we could but the elite minds in charge have high quibbles with how it would affect the feel of the language in this one absurd edge case, so we won’t”. Just special case the stupid pattern.

Indeed, I can testify that `?` was very much designed with the do-notation in mind.

Zig 'error types' are a sum type, while Go ones are just values.

And even then this is just the same as the '?' operator Rust uses, which is mentioned in the post.

I think you meant video decompression? Compression should theoretically be a lot more efficient, since the algorithm is a lot simpler and you can probably do a lot of SIMD to calculate the filters themselves.

In compression, "efficiency" usually means "compression level".

If by "efficiency" you mean "speed", then yes, I think OP's approach can be much, much faster than usual video compression approaches -- but this is true of all compression algorithms that don't compress very well. The fastest such algorithm -- leaving the input unchanged -- is infinitely fast, but achieves no compression at all.

As mentioned, OP is not expecting people to use the compression algo on production stuff. You can think of it as an experiment to see how well bloom filters would apply to video compression.

Are the results impressive? Probably not, but it's still an interesting idea.