dtheodor

An interviewer asking me about git rebase is the huge red flag

Thank you Machiavelli

Looks like .NET was represented in FOSDEM once, in 2019.

https://devblogs.microsoft.com/dotnet/net-and-typescript-at-...

Reminds me of Microsoft's KQL https://learn.microsoft.com/en-us/azure/data-explorer/kusto/...

If you are interested, I highly recommend the youtube channel Kings and Generals. It has very good history content on the last centuries of the Roman Empire and the rise of the Ottomans, among others.

Rise of the ottomans: https://www.youtube.com/watch?v=Xfb9fIMzuRw&list=PLaBYW76inb...

Fourth crusade and the restoration of the roman empire: https://www.youtube.com/watch?v=3Vp_IENiSnA&list=PLaBYW76inb...

Insufficient data for a meaningful answer.

He is not cherry picking, he picked the largest immigrant group, twice as large as the next one

Right, if you consider the internal state, it is hardly similar. You talked about black box and QA though. Black box by definition holds the internal state as irrelevant, and QA mostly treats the software it tests as a black box, or in other words the tests are "superficial" as you call it.

Your run of the mill computer program also "operates in enormous parameter spaces that are impossible to meaningfully test for all possible adversarial inputs and degraded outputs".

> Game of Thrones completely disregards the real world, and because this is on purpose, I think criticisms from "realism" are unwarranted

This is not true, any work of fiction needs to be believable within the bounds it sets for its world. Those bounds are extended to include dragons and magic, but no more. The rest of it should be as close to the real world as possible. There's a term for this, https://en.wikipedia.org/wiki/Verisimilitude_(fiction)

Would you say that a database is a "black box full of binary garbage, chewing gum and rubber bands that tightly couples everything in Windows.and it's like spaghetti and can't possibly be unwound"?

I don't think you would, that's not the conventional wisdom. Databases are considered to be the epitomy of clean, reliable, and efficient representations of data. It is text files that lack these capabilities and are considered a non-standard mess when it comes to data.

The registry is just a database. It may have not seen the best usage it could have from windows and applications, does that make it a bad architectural decision? Would we think different on the registry if it was just SQLite (or would we in this case think differently of SQLite)? Personally I firmly believe that the registry approach is a great architectural decision, for all the reasons outlined here: https://sqlite.org/appfileformat.html

I share the sentiment, but not for Roblox. Hashicorp, with a recent IPO, 200 mil operating revenue, and supposedly a good engineering reputation has one of its flagship products critically depend on a "toy project".

You are basing the statement "fear of wolves is completely irrational" on your experience as an outdoorsperson and 25 years of yellowstone. This is not a good basis. Wolves had lived in huge populations and had been in conflict with humans for thousands of years, with human casualties. Humans were very much afraid of wolves, and rightly so. Physically weak and isolated humans such as children and elderly are prime targets of wolf attacks.

https://en.wikipedia.org/wiki/Beast_of_G%C3%A9vaudan

https://en.wikipedia.org/wiki/List_of_wolf_attacks

He bribed people for sure. Microsoft products had completely overtaken the public sector IT of several countries back in the 90s/00s. To get into the public sector of several third-world and not so third-world countries, bribing is more or less mandatory, business as usual. We've seen scandals like these dozens of times with all kinds of big companies. Bribing to get big public infrastructure projects from companies like Siemens, bribing to get pharma machinery into public hospitals. No such scandal was ever published for Microsoft that I know of, but this is how things work.

Curious how Rust's ownership interplays with this memory management approach. Does it actually get in the way of implementing this?

There's a whole discipline around converting diagrams to code, called Model Driven Engineering. The idea is that you capture business entities and rules in various well defined diagrams, which then can be converted to code through code generation tools, i.e. can be turned into programs.

This was mainly promoted and developed by the creators of UML and has strong ties to it. That was UML's vision after all, a visual diagram language that unambiguously captures the essense of a program.

The Eclipse Modeling Framework is a framework that implements this approach.

I think MDE was up and coming around the end of the 2000s. As far as I know it didn't really go anywhere.

It's in-memory materialization, which will spill to disk if it doesn't fit in memory.

Search for "Materialize node" in https://www.postgresql.org/docs/12/using-explain.html

It's very true today. The problem discussed here is performance on complex queries (e.g. subqueries), and the query planner plays a huge role in that. The Postgres query planner has various issues. Here are two recent posts talking about planner issues:

https://medium.com/@rbranson/10-things-i-hate-about-postgres...

https://www.cybertec-postgresql.com/en/things-could-be-impro...

Also JIT compilation, while very nice and a step in the right direction, is very barebones at the moment, hardly achieving its potential. Here's a long todo list of what and how to make efficient use of JIT in postgres, by the main author of the feature. https://twitter.com/AndresFreundTec/status/10025899696161996... Postgres release 12 did not add any JIT related improvements, and as far as I know no work has been done on it on 13 either.

This website is unchanged from 1993 (the web archive first crawled it in 1997), yet it looks great in my 4K screen. I wouldn't be able to tell if it was written yesterday or 20 years ago. Completely unlike the experience you are getting from something like this http://web.archive.org/web/19961112181513/http://www.nytimes...

Since becoming open source and the system's architecture is in the open, I wonder how this criticism of FoundationDB from a VoltDB architect https://www.voltdb.com/blog/2015/04/01/foundationdbs-lesson-... fairs against the knowledge that has now become available. (To summarize, the author argues that building an SQL layer on top of an ordered key-value store is suboptimal)

I really don't see Rust as a good example of a language getting its syntax right. It reads like Perl. You know what's good syntax? The one that reads like pseudocode (Python is the closest to that).

NoSQL is all about missing useful features (such as integrity, transactions, query flexibility), that you unfortunately have to drop if you want to be able to scale in certain ways. Thus, NoSQL dbs are practically worthless until you get to a point where your SQL database won't work any more. At this point, you need to evaluate exactly what is it that your SQL db cannot handle, and switch to a different product accordingly. For example, you would switch to Aerospike if you need to scale writes.

Why EventQL over other distributed columnar-storage based databases like Redshift, Vertica, Citus, or Hadoop-based ones like Impala and Presto. What does EventQL do better?

We often see criticism against unit testing that is based on facts such as tests are badly written, unmaintainable, incomprehensive, and they drag development down.

Which may very well be true! But I am amazed at the conclusion: That because tests are badly written, writing tests is a bad thing. No! Any code can be badly written, it doesn't mean that writing code is a bad thing. Tests, like any other piece of code, also need to be designed and implemented well. And this is something you need to learn and get experience with.

As to whether well-written unit tests are worth it, I cannot imagine how someone could efficiently maintain a codebase of any size without unit tests. Every little code change is a candidate to break the whole system without them, especially in dynamic languages.

Sorry, I don't see the point of this library. What exactly does it provide? It looks like a very thin wrapper (150 lines of code) over psycopg2 that does exactly the same thing, just with a slightly different API.