jemfinch

I regularly spawn several thousands of threads in the C++ servers I write, and they perform well. At least 40% of FAANG companies just reduce the size of their per-thread stacks. "Thread per-connection" works just fine, and when you need to go faster, thread pools work even better without coloring all your functions.

There is an extremely small set of domains where simple threading doesn't suffice, and async/await is too high a price to pay across the entire software ecosystem just to slightly optimize those domains.

> OS threads are expensive: an operating system thread typically reserves a megabyte of stack space and takes roughly a millisecond to create.

It's typically less than a hundred kilobytes and (on the systems I've benchmarked using std::thread) it takes 60usec (wall time in userspace) to create and destroy a thread.

Threads have gotten so fast that paying the async function coloring price makes very little sense for most software.

Is this the return of Advogato?

My biggest problem with less(1) is that the regex engine is unreasonably slow. When processing large files, I frequently need to search with grep (or more recently, rip-grep) with large -A/-B buffers, and then pipe that through less, because the regex engine in less won't find what I want on any reasonable time scale.

This sounds remarkably similar to the (western) Catholic theological concept of "mental reservation" (https://en.wikipedia.org/wiki/Mental_reservation).

It is most definitely not an overstatement. I have over 425 hours in Hollow Knight. I stopped playing Silksong in 8 because it felt like unfun masochism.

This contradicts the most common view of Christians throughout history, especially since the simplest reading of Romans 1 expresses exactly the opposite view: "Ever since the creation of the world his invisible nature, namely, his eternal power and deity, has been clearly perceived in the things that have been made. So they are without excuse."

> Many times I've asked that I'm told "he was 100% human and also 100% God."

Does this surprise you? The council of Nicea where this was defined as the orthodox claim happened in A.D. 325.

> I'm sure different sects believe differently on that, but plenty do accept that. When I ask "how is it possible to be 100% human and 100% God?" you'll sometimes get answers like, "well it's like water in different for

The _vast majority_ hold that, because the vast majority affirm Nicea. The only major denominations not holding to the orthodoxy here are (in descending order of size) Latter Day Saints (Mormons), Oneness Pentecostals, Jehovah's Witnesses, Unitarians, and Christadelphians. They represent approximately 1.6-2.4% of the Christian population.

> you'll sometimes get answers like, "well it's like water in different forms, ice, liquid, and vapor" but that doesn't answer the question

The real (orthodox) answer depends on a metaphysics of substance that most Christians, even those who hold the orthodox view, are ill-prepared to elaborate on.

grte is probably "google runtime environment", I would imagine.

My experience has been the opposite. The number of customer service representatives I speak with that simply can't comprehend the NATO phonetic alphabet never ceases to surprise me, somehow. More than half the time I'm nearly finished with my last name ("foxtrot india november charlie hotel...") when my interlocutor just says "whoa whoa whoa, what?" and I have to fall back to the annoyingly slow and frustrating "eff as in foxtrot..." form while effortfully disguising my palpable disappointment. It's just one more way for humanity to disappoint me.

"Synoptic" is simply the adjectival form of "synopsis": Matthew, Mark, and Luke all strive to give a synopsis of Jesus' life, organized primarily around a chronological retelling of his approximately three-year ministry. Matthew and Luke include details of his birth and genealogy.

John, on the other hand, is organized around theological and moral themes, rather than the totality of Jesus' ministry and teachings. That's why it's not considered a synoptic gospel.

What don't they like about it?

But how much would you bet?

It's impossible for your fact and the fact you're replying to both be true. Water is denser than butter, and the nearest star to the sun is about 4.3ly away; if your fact were true, the universe would be a black hole.

A cubic lightyear is about 8.468e+50 liters, and butter weighs 911 g/L, giving the mass of a cubic lightyear of butter to be 7.714348e+50, whose Schwarzchild radius is about 121,103,293 lightyears, about 100x smaller than the radius of the known universe.

I've written a lot of high performance/scale C++ code using a lot of data structures over the years, and ordered iteration has been very rarely needed; unordered data structures still rule the day in performance the vast majority of the time, and their lower constant factors very frequently outperform more specialized data structures. They're absolutely worth benchmarking against if the goal is actual uptake in the actual world.

In my experience, practically every single time I've used absl::btree_map, I've ended up reverting for performance reasons to either a flat hash map or, in some relatively rare cases, a sorted vector map (despite its O(n) insert/erase) because the constant factors are _so doggone low_. The experience remains: btree_map (or SkipLists, or whatever) has (in my experience) essentially never, in over a half million lines of C++, actually remained in the code.

Also, I presume (based on the implementation details, not based on actual use) that roaring bitmaps have some reasonable iteration API that would make them relevant even to the ordered comparison.

The important thing here is that if anyone wants to contend that someone should use their new data structure because it's better or faster or more optimal for some particular use case, it's important for them to demonstrate that they've thoroughly investigated the data structure space around their proposal. Comparison against std::map and std::unordered_map simply doesn't demonstrate the kind of comprehensive knowledge that I would expect from someone who claims that I should use their optimized integer map in my own code.

This really doesn't seem to be comparing to comparable data structures. For int map specializations like this, the optimized alternatives are things like Judy (which is looking quite aged these days) or roaring bitmaps, not to mention that any C++ developer using "ordinary" maps will be using absl's SwissTable (flat_hash_map) or folly's F14 (F14FastMap) or perhaps absl::btree_map if order is important. Comparisons to std::map and std::unordered_map are simply too naive to make the case for this data structure.

Why do you call it a "national security asset"?

> Now we can make an assumption that the int it's a finite number say u32, this means we can construct a binary tree with a depth of 32 with access time of O(32) therefore O(1) time and space.

Heck, let's go even further. All the computers I've used have a fixed amount of memory, addressable by a u64, so I guess all my algorithms are constant time now.

I guess we've solved the interview, folks.

For what it's worth, the only state in the United States which agrees with your philosophy is Texas. Every other state requires an imminent threat of death or grave bodily harm to justify the use of lethal force. (And honestly, Texas only holds that position because of its huge size and ranching background, where cattle rustling stood a major risk to the state's economy.)

> I prefer to talk them through the problem together, like we were actual teammates working on a problem together.

If a colleague came to me to discuss a question this basic, I'd want them PIPed out. This is miles from the complexity of problems that require collaboration. It's a shell pipeline that I'd write with sort/uniq in less than five minutes. I just did it to make sure my estimate wasn't wrong:

    sort <(sort -u <(cut -d' ' -f1,2 /tmp/day1)  <(cut -d' ' -f1,2 /tmp/day2) | cut -d' ' -f1 | uniq -d) <(sort <(cut -d' ' -f1 /tmp/day1 | sort | uniq) <(cut -d' ' -f1 /tmp/day2 | sort | uniq) | uniq -d) | uniq -d

Maintainable? No. Done iteratively in less than five minutes? Yes.

If your perspective is that it's unrealistic to ask anyone to come up with an answer to this question on the spot, you should take a long, hard look at yourself and the quality of your colleagues.

It's probably a violation of the First Sale Doctrine, which is well established in US law.

"Taking full control of your I/O and buffer management is great if (a) your developers are all smart and experienced enough to be kernel programmers" is already an appeal to authority in itself.

We shouldn't apply a higher bar to the counterargument than we applied to the argument in the first place.

You're issuing a correction for your original post, then? Haskell can circumvent the type system with unsafeCoerce and cast anything into anything else, therefore it (by your definition) is weakly typed. Same thing with Ocaml and Obj.magic. Practically every strongly typed language has a mechanism for circumventing the type system:

  C: (type) casts
  C++: reinterpret_cast and friends
  Haskell: unsafeCoerce
  Ocaml: Obj.magic
  Golang: unsafe.Pointer
  Rust: std::mem::transmute
  SML: MLton doesn't provide one, but SML/NJ provides
       Unsafe.cast.  So I guess MLton's flavor of SML
       is strongly typed, but SML/NJ's is weakly typed.

Any definition of "weakly typed" which excludes Haskell and Ocaml is farcical, inaccurate, and doesn't benefit any software engineer, especially the professional ones.

Calling C/C++ "weakly typed" is just functional/academic language snobbery. They have some automatic type conversions (more than some languages, less than others) and they have casts that allow programmers to circumvent the type system (but so does Ocaml with its Obj.magic, and Haskell with its unsafeCoerce).

The strong/weak distinction isn't particularly valuable in the first place, but it becomes especially useless if you try to shoehorn C/C++ into the "weak" category.

Directed graphs can be cyclic.

Please stop repeating this falsehood. "My sister had already had a couple of police visits about the previous incidents."

The point isn't a point at all, since their sister had already notified the police and given them a chance to do something. Read the article: "My sister had already had a couple of police visits about the previous incidents."

It was buried, so you might have missed it: "My sister had already had a couple of police visits about the previous incidents." They didn't skip the police at all: the police simply weren't doing anything until they had more information.

He wasn't investigated by the FBI. The FBI was investigating a hypothetical Japanese spy; since he wasn't a Japanese spy, any follow-up that led to him was merely incidental.

If the FBI investigates a spy seen driving a silver Honda Civic with license plate ABC-1234, and looks into an unrelated civilian who drives a silver Honda Civic with license plate ADC-1234 in case their witness misremembered the license place, that doesn't mean the unrelated civilian was "investigated by the FBI".

I once really enjoyed a shareware game on my MacBook pro named "Galcon". I enjoyed this game so much I was considering buying the complete version, but it was a bit pricey and I really wanted to know whether the unlocked content would be worth the $20 for an unlock key.

I realized the game was written in Python and dug into the .app directory. It was mostly binary data, but there was one python script with two lines, essentially "import game" and "game.start()". I inserted a pdb checkpoint between those two lines and started the game, dropping into a terminal with the game module loaded. I started peering around with "dir" and ended up finding the function which validated purchase keys, so I replaced it with "return true" and I was able to see the unlockable content.

Unsatisfied with just that, next I used the "dis" module to disassemble the key validation function, decompiled it by hand into python code, and inverted it to make a function which could generate arbitrary keys.

Then I revealed all this to the author and he never got back to me.