I get why we prefer final in languages with a need for thread safety, but I have never understood why people prefer const in typescript. I have seen people bend over backwards to avoid a `let` even if it results in higher complexity code. It just doesn’t seem to solve a problem I’ve ever actually encountered in typescript code.
The only reason to use let is to indicate to the reader that you're going to be reassigning the variable to a new value at some point within the current scope.
If you aren't going to be doing that, using const lets the reader know the assignment won't change to refer to a new value.
Yes, I've heard this reason before, but how does that help? The only benefit of that particular arrangement as far as I can tell is that it's possible to enforce via linter. It doesn't signal intent, it merely states a fact that could be observed by reading the source code. What is the point of that? What problem does it solve? Are people running into hard to debug issues because a variable got reassigned? I don't remember that ever causing an issue before the advent of const. People go to great lengths to avoid writing `let` just because the linters have been telling them to use `const` so they consider `let` a code smell now. Is this really better?
It tells you up front what you would otherwise have to go line by line to find out.
There's a similar argument to be made for using forEach/ map / reduce / filter instead of a for loop. Each of those iterative methods has slightly different semantic intent. The only thing the for loop adds to the mix, and therefore the only reason to use them, is the availability of continue / break.
Hell, the same argument could be made for while loops vs for loops. What does a for loop really add that you couldn't get with a while loop?
As for your last point, I don't know of any linter that complains about the use of let when you reassign it. The ones I've used only complain if you use let when const would have worked identically in your code.
The fact that people write bad code is not down to let/const or linters. People always have and always will write crap and not understand why.
> it merely states a fact that could be observed by reading the source code
In 4 characters it clarifies something that could take 300 lines, 10 nested ifs, loops, etc; and, that trust disappears the moment someone, later down in the code *does* change the value.
Clarified intent, nearness-to-declaration, and linted protection are real benefits.
Assuming assert existed, it would almost certainly be judging its value for being falsy, while the ?? operator judges its LHS for being nullish, which is a narrower category. For strings, this affects whether the empty string is acceptable or not.
Fair, this is a good example of when != is actually the right choice (instead of !==). However, on web browsers, this will log an assertion failure to the console, but it will not throw an exception. It's also not suitable for the original context, where the non-null value was extracted into a variable.
The bigger problem is mutability. Any pointers into the bit-packed enum storage become invalid as soon as you change its type. To solve this you can either prohibit pointers into bit-packed enum storage, which is very limiting, or introduce immutability into the language. Immutability is particularly difficult to add to go, where default zero-values emerge in unexpected places (such as the spare capacity of slices and the default state of named return values)
Memory barriers don't force a flush of all CPU cache. They will enforce the ordering of memory operations issued before and after the barrier instruction, preserving the contents of the CPU's various caches.
OS updates on iPhones frequently list new emoji in the release notes. It would be interesting to see what the most mundane reason for an iOS update is.
Thanks for writing this. It takes a deep understanding to explain such complicated concepts in an accessible way. Reading it brought back fond memories of hacking on jailbreak projects deep into the night.
Go's internal linker is much faster than the system linker thanks to some go-specific optimizations. Go must fall back to the system linker whenever CGO is used.
It's not robust at all. Programs can and will exit before the userspace daemon is able to read from /proc. Malicious programs can even attribute their network activity to any program on the system they are able to exec by execing that program immediately afterwards or concurrently from another thread. One can properly track program paths/arguments by setting kprobes on the exec functions within the kernel and copying the data to a ring buffer read in userspace or by reading out of the task struct using bpf_probe_read_kernel.
> Programs can and will exit before the userspace daemon is able to read from /proc
that's depend on the use case, and we are mainly tracking server which are not terminated during our runtime. of course if we are tracking "not servers" (like curl) it can happen, and for that you can find other fallbacks.
regardless, we cannot assume we will be existing before all other server and client have started running, so we are trying to do "best effort", that's why counting on hooking the `exec` syscalls is not robust either.
If best effort is good enough and your use case doesn't require robustness, reading out of host /proc certainly works. Tracking execs with hooks in the kernel's internal exec mechanism with a separate indexing step at startup is worth the extra effort for use cases that do require accurate data, such as security observability.
This is what ETags are for. Upon a user's first visit the server should return an ETag uniquely representing the current version of the page. The browser will cache both the page and the tag. Upon subsequent page visits the browser will send an If-None-Match header containing the tag for the version of the page it has cached. The server should compare the incoming tag with the tag for the current version and return a "304 Not Modified" response if the tags match or a full response with the newer tag in the ETag header if they don't.
a drawback of relying on ETag is that if a page is visited frequently, then the cache validation "If-None-Match" request still being sent and takes bw+latency+computation+etc and I suspect that if the connection is broken or status 503/504 is responded, then neither the cached page is shown.
my understanding is that he whant to refresh the page only if it's known to be changed and always use the cached version otherwise.
