711 karma · joined July 9, 2012
Seems that retries are good when the error is rare, and bad when the error is common. Typically outages have you transitioning from "everything is fine" to "nothing works", so being able detect that transition early is helpful
The only way I can get it to reset is to clear my cookies, so its likely that.
Still worth being careful, but it can be useful when you have a set of common fields that everything of a certain group will have (such as a response object with basic status, debug info, etc. and then additional data based on the particular struct). I don't know why they let you embed multiple layers and multiple objects though. I've never gotten value out of anything but a "here's a single set of common fields struct embedding".
Characters in Chinese can be combined to make more words, and you need around 9k words in English to read a novel and 2k characters in Chinese to read a novel.
Interesting, lets look at fnmatch: https://pubs.opengroup.org/onlinepubs/9699919799/functions/f...
Well, fnmatch really does two things, it parses the pattern and then applies that to a string, so really, there should be a "ptnparse" library that handles the pattern matching that fnmatch has a dependency.
Though, thinking it through, the "ptnparse" library is responsible for patterns matching single characters and multiple characters. We should split that up into "singleptn" and "multiptn" libraries that ptnparse can take as dependencies.
Oh, and those flags that fnmatch takes makes fnmatch work in several different ways, let's decompose those into three libraries so that we only have to pull in the matcher we care about: pthmatch, nscmatch, and prdmatch. Then we can compose those libraries based on what we want in fnmatch.
This is perfect, now if we don't care about part of the fnmatch functionality, we don't have to include it!
/s
This decomposition is how we wind up with the notorious leftpad situation. Knowing when to stop decomposing is important. fnmatch is a single function that does less than most syscalls. We can probably bundle that with a few more string functions without actually costing us a ton. Glob matching at a string level probably belongs with all the other string manipulation functions in the average "strings" library.
Importantly, my suggestion that fnmatch belongs in a "strings" library does align with your suggestion that fnmatch shouldn't be locked into a "glob" library that also includes the filesystem traversal components.
The thing that’s changed is how much the transactional nature favors the lazy students, not the smartphones specifically.
The reason the argument is so bad that “it’s the smartphones” is because that implies an easy solution that is external to the academic system, when the root cause is internal to the system.
Const support in languages never makes all modifications to data accessed through the variable locked out, just the top level, which makes it much more difficult to ensure that the assumptions about immutability hold without constantly doing deep copies or having to double and triple check that your Const definitions are correct.
Const often leads to a false sense of security.
That’s the most likely bet they are making, similar to Apple/Android or Safari/Chrome. Spending a minor fraction of your revenue to avoid anti-trust probably makes sense for them.
There are some incredible programmers in both big tech and game dev, but big tech has vastly more developers with less pressure to have top-tier talent.
Median developer at both probably represents the same skill because of normal distributions.
However, he’s stated many times that he will release his language compiler and modules openly when they are ready and that he believes he’ll have to open-source it at some point if he wants broad adoption.
JSON is already strictly worse than XML though as it doesn’t support comments and multi-line strings in a sane way.
It feels very much like the "read" in the "read-after-write consistency" is usually forgotten, hand-waved away with "eventual consistency", or is actually just a single node handling the coordination somewhere, leading us to not having nearly as scalable a system as we are promised by the database.
This strategy cannot work long term unless there is growth happening elsewhere in the company to make up for the excess money burned on contractors and reduced number of employees. But it can definitely work short term if the growth numbers for the quarter are going to look bad, and it has the benefit of giving management someone else to blame when the project work doesn’t get done.
If your company starts replacing employees with contractors, that’s a bad sign.
The second one is even more important though: Time. How many of my systems are guaranteed to stop after 15 minutes or less? Web Servers wouldn't like that, anything stateful doesn't like that. Even compute-heavy tasks where you might like elastic scaling fall down if they take longer than 15 minutes sometimes, and then you've paid for those 15 minutes at a steep premium and have to restart the task.
Serverless only makes sense if I can do it for minor markup compared to owning a server and if I can set time limits that make sense. Neither of these are true in the current landscape.
One group sees the other as a person with a reel-mower proclaiming they don’t need a tractor mower, while they can mow much less grass a day.
Both groups are right, and both are wrong. Depending on what you’re doing, it can make sense to use heavyweight tools, lightweight tools, little tooling, or lots of tooling. If you’re hired into a big codebase written over the course of ten years, skipping tools that will help you make sense off it is probably not the right choice. If you’re building a system from scratch, then those same tools might inoculate you to the dangers of having a poorly organized codebase. If you need to debug a server remotely, bring productive in vim and basic command line tools could be invaluable. But if your debugging stuff, you could have saved yourself hours by turning on a debug port and stepping through the code in a debugger.
The arguments everyone is having look to be about whether it’s worth it to learn how to use tools. The answer is yes, but everyone has their identity caught up in their pet workflows.
Most doctors, nurses, EMTs, etc. would work for free if they could magically have them and their families taken care of, as evidenced by how much they go well above and beyond the requirements of their job, working heroic hours, buying stuff out of pocket when the system fails them, etc.
Not all health care professionals, but 90% of the ones I’ve met.