Using parens to pass type arguments was one of the things that turned me off on Zig. For a language that prioritizes "no hidden control flow," it sure did a lot to make various syntax conventions _masquerade_ as control flow instead.
This isn't an interesting counterpoint. This is the de facto narrative regarding patent lawyers and patent trolls masquerading as firms that act as though they somehow contribute.
Very mid compared to Visual Studio in my experience. You don't even get a modules window, and there's a whole litany of core C++ debugging features missing.
You are comparing apples to oranges. Settlement times in traditional credit card transactions are not felt by the customer, and provide safeguards for fraud prevention and charge backs. Furthermore, transactions are easily reversible through a claims system. Guess what crypto doesn't have?
Alternative take, scheduling a rejection meeting without providing any indication about the meeting agenda creates an unrejectable obligation without any consideration for the candidate.
I'm very familiar with congestion trading and was in that industry at one point, but cmon, this is a bad crypto talking point. It's already quite apparent that bitcoin mines actually destabilize grids just as much while driving up electricity prices for local consumers far more than any positive net effect from an energy perspective.
"good design?" Imagine a world where you can reply to a comment and have the entire thread context, or a world where after posting a comment and hitting "back", the navigation stack didn't take you to the post form. From an accessibility and legibility standpoint, the text is honestly hard to read (insufficient contrast, long line, etc.). There are so many usability issues/quirks about HN that I'm not sure "good design" is an apt description. "Information dense" is honestly a low bar -- it's easy to achieve information density and pretend the end result is actually good.
I'm not sure why what I wrote necessitated a lesson on limits and asymptotes. My point was that given that N was the size of your tree, more often than not, big-O analysis would apply in this case since N is likely big compared to secondary fixed effects.
Do you understand the data structure being proposed in the original post, and are you claiming that scanning 100GB of data every time you want to perform a childof operation is acceptable? Please, use the proposed tree for your application since big o isn't the full story to you lol