2,827 karma · joined October 6, 2014
Electric cars still use roads, which still need to be maintained. There's no "extrapolation of logic" required, because the tax on the most fuel efficient cars already dwarfs that which would be paid by electric cars.
This is not in any way a mis-application of the word "pattern". There is no exhaustive list of all design patterns. A design pattern is any pattern that is used throughout a codebase in order to leverage an existing concept rather than invent a new one each time. The pattern need not exist outside the codebase.
> Consistency increases legibility, but only to a certain point.
It's the opposite: inconsistency decreases legibility, and there is no limit. More inconsistency is always worse, but it may be traded off in small amounts for other benefits.
Take your example of experimenting with new solutions: in this case you are introducing inconsistency in exchange for learning whether the new solution is an improvement. However, once you have learned that, the inconsistency is simply debt. A decision should be made to either apply the solution everywhere, or roll back to the original solution. This is precisely the point the author is making by saying "consider refactoring the entire codebase to use this new pattern".
This refactoring or removal doesn't need to happen overnight, but it needs to happen before too many more experiments are committed to. Instead what often happens is that this debt is simply never paid, and the codebase fills with a history of failed experiments, and the entire thing becomes an unworkable mess.
AIUI, Microsoft actually has good tooling for validating drivers before they are deployed, but it requires that you actually run the validation...
So it's not necessarily government regulation per se, but a combination of things:
1. It's much safer (in terms of personal liability) for the decision makers at large companies to follow "standard industry practices" (however ridiculous they are). For example, no-one will get fired outside of Crowd Strike for this incident precisely because everyone was affected. "How could we have foreseen this when noone else did?"
2. The Cyber Security Insurance provider may not cover this kind of incident given there was no breach and so as far as they are concerned installing something like Crowd Strike is always profitable.
3. The insurance provider has no way to effectively evaluate the security posture of the enterprise they are insuring, so rely on basic indicators such as this checkbox, which completely eliminates any nuance and leads to worse outcomes (but not to the insurance provider!)
4. "Bad checkboxes" propagate down the supply chain the same way that "good checkboxes" do (eg. there are generally sections on these due diligence questionnaires about modern slavery regulation, and that's something you really want to propagate down the supply chain!)
Overall I would say the main cause of this issue is simply "big organisation problems". At a certain scale it seems to become impossible for everyone within the organization to commicate effectively and to make correct, nuanced decisions. This leads to the people at the top seeing these huge (and potentially real) risks to the business because of their lack of information. The person ultimately in charge of security can't scale to understand every piece of software, and so ends up having to make organisation-wide decisions with next to no information. The entire thing is a house of cards that noone can let fall down because it's simply too big to fail.
Making these large organisations work effectively is a very hard problem, but I think any solution must involve mechanisms to allow parts of the business to fail withing taking everything down. Allowing more decisions to be taken locally, but also the responsibilities and repercussions of those decisions to be felt locally.
The strategy I use is to keep transactions as small as possible, and have retry functionality built into the transaction abstraction, so the buesiness logic doesn't really need to worry about it. I also explicitly use read-only transactions where possible.
Correction: people should not be able to escape responsibility by saying this.
The problem is that right now people do escape responsibility for saying this because the EU is not properly enforcing these new laws.
Introducing a law and then not enforcing it has consequences, and those consequences should have been foreseen. Either the law is unenforceable due to practical constraints, in which case it's a bad law, or the EU is failing to enforce it due to inability.
Hopefully the EU starts putting more focus on enforcing its existing laws rather than creating new ones.
This is particularly misleading for two reasons:
1) There are a lot of `-sys` crates which link to C libraries, so the "unsafe" code in these crates comes from the binding to C rather than some limitation of Rust. Often there are 100% safe Rust alternatives to these C libraries as well.
2) Of the remaining crates which use "unsafe", the unsafe code is often contained to a tiny percentage of the code, so if we're looking at the overall amount of unsafe code, you're going from 100%, to a fraction of a percent.
The similar case occurs when you have: - 1+ threads holding a shared lock (Readers) - 1+ threads waiting to acquire an exclusive lock (Pending Writers) - 1+ threads trying to acquire the shared lock (Pending Readers) - 1+ Reader is waiting on a Pending Reader
In this case the Pending Readers will be unable to acquire the shared lock even though it is still in "read mode" because in a fair RW lock Pending Writers are prioritised above Pending Readers so as not to starve the writer side of the lock.
Memory being "reachable" is a property used by garbage collectors to determine what can be safely freed, but reachable memory can still be a memory leak. (Which is why languages with GC can still suffer from memory leaks...)
Reusing code does not make something "fundamentally right approach". An implementation that actually does what the problem asks is a "fundamentally right approach". If you can reuse existing code in that implementation then that's a bonus.
The problem is very clearly specified, so if you choose to implement something else hoping that it's "close enough" then that's on you...
> I know that I would be deeply surprised if I found a database doing it, and not in a good way.
SQL engines do way more surprising optimizations than this. SQL is a "4th gen" language after all, meaning it's absolutely within the spirit that the database engine does whatever it wants to get the result.
When you write `SELECT DISCTINCT a, b` you are asking for every unique pair (a, b) in the result. Specifically, the same value of `a` could appear multiple times in the result paired with different values of `b`.
The only way to implement that "generally" is to visit all of the rows in the result-set, and skip over duplicates using a hash table of "already seen" pairs, or by sorting the result. The problem is that this intermediate result-set is much bigger than we really want.
As a human, we look at this and think "Oh, but `a` is the primary key (in this case CustomerID) and `b` is a column in the same table (CustomerName) so we only need to be distinct over `a`, which means the query optimizer should be able to "push down" the DISTINCT clause into the scan of the joined tables". The problem is that the query optimizer has not been endowed with this kind of knowledge about the specific relationship between `a` and `b`, and so cannot do this optimization. In principle, a query optimizer could implement this kind of optimization though.
At this level you really start getting into the nitty gritty of what optimizations a particular database has implemented though: the solution presented in the article may be the best way to write this for SQL Server, but this "correlated subquery" form could be catastrophically slow in other database engines...
I imagine you could define utility that way, but presumably the mugger could increase the cost (two fingers? an arm?) until the argument works. Also, if you do definite a utility function like that (say, "there is more utility in this £10 being mine rather than yours than the utility of your arm") then that's a pretty questionable morality.
On Windows, many things exist in user-space that are managed by the OS. This is in contrast to linux where the Linux kernel is its own thing with its own stable API.
Fibers are an OS-level concept that exists in user-space.
JavaScript and HTML for obvious reasons. PHP because if you didn't have your own server, you couldn't run anything else (while there were free hosting providers that would host your PHP scripts).
Nowadays there are tons more options.
What exactly is the point of these support teams when they can't fix the most basic failure mode (a single bad input...)
You definitely can: https://doc.rust-lang.org/std/panic/fn.catch_unwind.html
That's not to say you shouldn't invest in abstract research with no obvious goal at all, but probably you should consider it a much higher risk investment and not fund all your research that way...
There's also the fact that money now is more valuable that money later even if you adjust for inflation (one of the reason countries run a deficit) so the expected return should be much higher than $1 to be worth investing in.
Next, there's the fact that investment is finite, so the expected return has to be higher than the expected return you would get elsewhere.
Finally there's the fact that as you invest more, the effects of all three of those factors increase, so it has diminishing returns.
That said, many of these things are solvable without a full switch to a threaded model (eg. by having pooling built-in and session-state-aware).
I don't mean to down-play how impressive models like GPT-4 are - they are very impressive and have great utility.
The problem is we are talking about PR, and when you throw around words like "artificial intelligence" it misleads everyone who is not intimately familiar with the limitations of such models.
> Personally I believe it's possible to have intelligence without sentience/self-awareness
The general public doesn't make that distinction when you throw around terms like artificial intelligence. They hear artificial intelligence and imagine "thinking machines".
No doubt people will say this is just moving the goalposts - that whatever these models achieve it will never be "AI", but that's demonstrably false. The concept of AI has existed in film and other media in the same form since forever, and it's pretty clear if you put those representations side by side with what we actually have today, that we are not even close yet.
For some reason "advances in machine learning" just isn't hip enough to get funding, so "AI" gets thrown around instead.
Generics in Go don't add anything beyond what generics already do in other languages, so the challenge with bringing generics to Go is "how do we adapt the language to support a feature that already exists in other languages and is generally well understood". Bringing generics to a language that wasn't designed with them in mind has often resulted in a sub-optimal implementation (eg. Java vs C#).
On the other hand, "safe custom allocators" are not a feature that any language (to my knowledge) has solved. It's not as though this was an oversight in Rust's initial design: using a custom allocator in an unsafe context has always been possible in Rust, and it's too early to say whether bringing this feature into the language later will result in a similarly sub-optimal design: in order to be sub-optimal there would have to exist some better solution out there, and there currently doesn't.
If Rust was content to have use of custom allocators be unsafe it would be trivial to add them (since you could just add new variants of allocating methods that take an allocator as a parameter).