Git is over 20 years old at this point. If somebody is in their 60s now, they were in their 40s when it came out. This is not about age. They must have slept on it for a long time.
Nobody expects an engineer to be a git expert, but if a senior software engineer has heard of git only yesterday or don't have a vague concept of how DVCSs like hg or git work (DAG of commits), then something has gone very wrong.
Maybe there are use cases where SVN is superior (I can't come up with any but they may exist), and maybe engineers in that industry really are so specialized that they never get around to working on anything else!
But maybe it's because nobody else is willing to hire them.
I love this! The docs are really good and I am looking forward to playing with this.
I think I disagree a little bit about the value of type and lifetime annotations, I think if I used this, I would put a lot of [sig ..] into my code.
I think having a similar syntax for lifetimes would be valuable so I as a developer can make sure that some value is not 'static (or has the lifetime of some other object that lives as long as my program). Basically I want to ensure that my values are actually dropped at some point.
One thing the docs could be more explicit about is where this runs. I saw that it has a Wasm backend, but can I also compile this to native code? Do the effects require some runtime (and I don't mean something like the JRE, more like what Go has)? Maybe I missed this, though.
What I think you are saying is that computing the hash needs to process the entire string, and the length of that string roughly corresponds to log n, therefore it's O(log n). Not sure I am entirely convinced by that reasoning, but let's roll with it for now.
Because if you apply it to binary search, you need to compare the strings at every step, and by that logic, each of these operations is O(log n), which means your binary search is now O(log^2 n).
I guess the crux is that we are still comparing apples to oranges (or multiplication operations to comparison operations), and at the end what probably makes hashing faster is that we are not branching.
Still I don't think it makes sense to think of both hash tables and binary search as O(log n).
We definitely would need centuries for this, because Moore's law has been dead for a while, while the number of possible programs grows exponentially in it's length.
But I hope we have more efficient ways to do this in a century.
No, the 340 were per month, the 40 hours are per week. I usually do back-of-the-envelope calculations with 4.3 weeks per month, which would leave them below 2 EUR/h.
Edit: But you are of course right about inflation! According to this website[1] it would bump them to 3.2 EUR/h.
I am confused. I get E2EE chat with a TEE, but the TEEs I know of (admittedly not an expert) are not powerful enough to do the actual inference, at least not any useful one. The blog posts published so far just glance over that.
I have the UAP-AC-LR and if you only need basic AP functionality you can even configure it from the phone (no cloud). 99% sure no cloud stuff is needed when self-hosting the controller. May have changed since then, though.
> This isn't a hypothetical, it is how the law is actually used.
You make it sound like it happens all the time and everyone is used to it. I know of once case (Pimmel-Andy), and that led to a shitstorm, including part of the police operation being declared unlawful after the fact.