this is fine when you're a junior learning but it's asking to get shit dumped on you later on. I think it's a good idea to pick a lane later on in your career and settle into it.

Ok

Testcontainers is great. It's got seamless junit integration and really Just Works. I've never once had to even think about any of the docker aspects of it. There's really not much to it.

I am the Walrus.

Isn't this pretty much what JSON streaming does?

Yep, it’s a subset of JSON streaming (using Wikipedia’s definition [0], it’s the second major heading on that page). I like it because it preserves existing Unix tools like grep, but the other methods of streaming JSON have their own advantages.

[0]: https://en.m.wikipedia.org/wiki/JSON_streaming

I've been doing it for almost a year, am I missing something?

I, too, want to mention that this has already been working.

Any app that works with "real" Xwayland (or already is Wayland native), will work on WSL2. WSL2's Xwayland uses Mesa/DRI's WDDM backend, so its translating DRI IL into DX12 IL, and passing it off to the GPU driver inside of NT kernel space.

There are a few exceptions, such as I think Firefox has a bug where its misinterpreting the DX12 Mesa target and attempting to use a feature that isn't advertised (they're working on a fix); Chrome (thus all the Chromiums and Electrons) work, GTK, Qt, the Java toolkits, etc, all work.

It was a genuine question. Good to know that this is possible! It was my understanding that it was not the case.

There were issues with enterprise vpn and firewalls last time I tried, but on a home desktop gui apps basically just work.

I had no idea this had a name. Sure wish I'd have known this while I was in school.

I personally almost always use loops (in Java) unless I know the dataset being dealt with is small, unless I'm writing stuff in Scala where maps and flatMaps are first class, but diving into Scala is its own can of worms.

They're hyperbolic and don't actually give you any useful information on why they're "harmful" or what's wrong with the subject being discussed.

That they are hyperbolic, maybe. I disagree with the rest, I believe there are tons of information on both examples about why they are harmful.

(edit, typo)

Not in the titles. "X is harmful" could instead be "X is unsafe", "X is often slow", "X has non-obvious corner cases", "X led us to maintenance hell", ...

"Harmful" is less information and kind of suggests an overall judgement for all cases vs "things to consider" (which was e.g. also a criticism of the original letter, that it lead to rules like "never use goto" which forced people to do bad workarounds instead of discussion on where to use it and where not)

The problem with titles like that is that they don't convey the same thing. "considered harmful" has entered the lexicon at this point, so you know what you're going to get when you see it, which is someone attempting to make a reasoned case about why some behavior that people do and consider okay is actually worse than people may suspect.

In that way, it's much more informative and less likely to have people arguing pedantic points about the title being "correct" than "is harmful" or "is often slow" or "has non-obvious corner cases" or "can create maintenance problems", which might all be items together in a "is considered harmful" article.

In other words, it's come full circle. There was the first, then there was the numerous copycats, then the backlash, and now we're all the way around to the point there it's a fairly succinct way to describe exactly the type of article people use it on and most people know what it means and what to expect when they see it.

All that's left is for people to realize it's not going anywhere and actually has some beneficial use and that there's no point in complaining about it anymore, but that might be asking too much.

Fair enough. Yet it might be difficult to summarize the tradeoffs succinctly enough for a title.

"Harmful" conveys enough information to raise awareness of a topic which might not be usually considered. Both examples show this pattern: schema-less is often considered a good thing, when it is not (in Stonebraker's and my opinion); also subtransactions are usually considered a good thing, while the OP shows they can have notable negative effects (of diverse nature) in the database.

They should start calling them "problematic"

If you're using Postgres, you can use recursive queries using common table expressions. Disqus implemented this sort of thing 10 years ago: https://pastebin.com/Fe2twMRr (I can't find the original talk for some reason)

Here's the meat of the solution:

  CREATE TABLE comments (
        id SERIAL PRIMARY KEY,
        message VARCHAR,
        author VARCHAR,
        parent_id INTEGER REFERENCES comments(id)
  );
  INSERT INTO comments (message, author, parent_id)
  VALUES ('This thread is really cool!', 'David', NULL), 
  ('Ya David, we love it!', 'Jason', 1), ('I agree David!', 'Daniel', 1), 
  ('gift Jason', 'Anton', 2),
  ('Very interesting post!', 'thedz', NULL), 
  ('You sir, are wrong', 'Chris', 5), 
  ('Agreed', 'G', 5), ('Fo sho, Yall', 'Mac', 5);

What we’ve done now, is setup a basic comment model. We’ve included the message, the author, and the parent comment (which is optional). Now let’s learn how to use a recursive query to easily re-order this date, showing us a fully threaded view, sorted in ascending order by id.

  WITH RECURSIVE cte (id, message, author, path, parent_id, depth)  AS (
  SELECT  id,
          message,
          author,
          array[id] AS path,
          parent_id,
          1 AS depth
  FROM    comments
  WHERE   parent_id IS NULL

  UNION ALL
 
  SELECT  comments.id,
          comments.message,
          comments.author,
          cte.path || comments.id,
          comments.parent_id,
          cte.depth + 1 AS depth
  FROM    comments
          JOIN cte ON comments.parent_id = cte.id
  )
  SELECT id, message, author, path, depth FROM cte
  ORDER BY path;