why-el

What happens during downtime for maintenance?

I like types, but I like types even more when they are at the edge of two systems and both systems understand them. For instance, in the past we ran Rails APIs and a lot of mobile apps consumed them, and there was a lot of math involved. We put Google's protocol buffers between them. The data's type info is thus shared. I liked this pattern a lot, and it did reduce A LOT of bugs (for instance ints vs floats).

Another thing: people working with dynamic typing often forget that often times they are interacting with a system with extreme opinions on types, namely their relational database, which is often times literally the heart of the business. If your language of choice has typing, you can sync that type info (smart ORMs, codegen), and thus reduce friction. With that said, I develop in Ruby and my understanding of where there might be "type friction and potential for bugs" has improved a lot over the years, so I don't mind the lack of types until we get optional typing sorted out.

I am not sure if you are agreeing or disagreeing. If you agree, I'll take it. If your point is that we should try and fix it and not succumb to "Stockholm Syndrome", I say precisely that also, in the second part of my comment. We can both work to fix AND have folks get their money by studying. Often times what happens is someone young enough will read this and conclude there is no point to studying, and that is not good career wise on average.

I don't know, risky answer but I will give it nonetheless. This advice is given to many candidates, and I agree that Leet Code interviewing is bad and the industry needs to work on something better, but in the meantime, if you are starting out, think of it this way (and I have friends younger by 10 years or so and straight out of college and I say the same thing), a few months of studying gives you a huge salary. It's a win-win, and in the meantime, people will complain and hopefully the industry will fix it, but do not "Skip Leet Code" just because it's the cause du jour. That's just my opinion.

There is a lot of advice here, all good, but also I wonder if you yourself were given this feedback by someone else or this is your own somewhat subjective opinion. I am a non-native English speaker myself and 6-8 years ago I've mistaken my slower recall of words and linguistic structure for incoherence and lack of "logical flow", but this is not true at all. Your language will get better and so is your confidence, and a qualified interview should (must?) not confuse the two situations.

This is what my strategy is more or less, but for emails. If a startup sends me a "Welcome to X", I treat it as "Don't forget to unsubscribe from X".

If a Spotify PM is collecting feedback: If I go to a song's Radio to try and discover similar songs, do not play me songs I already "liked" (ones with the heart icon highlighted), it defeats the purpose of going to the radio.

I made the same half-serious joke about Gitlab since it came out: they do not understand visual contrast, and a github user coming to gitlab is instantly both overwhelmed by how much info is in their face and how blended everything is in the issue tracker (everything is white-backgrounded, no way to discern important info). Fix this and you will get people over.

This is the response I got:

> Sorry, that part of the email wasn't clear. We don't compare passwords between Heroku accounts, this was more of encouragement so customers will hopefully practice good password hygiene.

Ah I see, that I don't know (and I misread the original, quite correctly concerned post, my apologies). I am a customer and I will follow up with them about this. If I were to guess, they mean same accounts within the same organization, in case account setup has been automated.

multiple salts can be stored, no? and they can still figure out the same password. Google does the same, even going back multiple passwords in the past ("this password was used previously X years ago").

In your rebuttal, you used a concept that necessarily assumes time ("how fast or slow", i.e. speed) to argue against the existence of time?

Wonderful, thanks for sharing.

This connects nicely with Dan's article from yesterday [1], if only tangentially. I think a good habit is to instill a mindset whereby there is a single metric for cost, possibly associated with your main product, and keep track of that cost as it relates to your infrastructure spending. I've seen it before work well. For instance, if you sell computers, the cost could be, we spend $100 on infrastructure per computer sold, and engineers can then argue for spending more effectively.

[1] https://news.ycombinator.com/item?id=30936189

> Humans who learn to comprehend language must learn about the underlying statistical structure of language

This comes up a lot, but is the evidence really there for it? Granted, we (humans) have mental models for "this is most likely what this person means", but I don't think that says a lot about the "underlying statistical structure of language". It seems to me like by the time such statistical probing takes place, for instance trying to decipher what someone means, the language learning already took place. Or do you mean something else?

Note: I am not an expert in this field. I studied some papers back in college addressing these topics and the evidence back then (out of the generative grammar school) was fairly convincing in refuting this statistical learning assertion. I wonder what papers or research you had in mind here.

> Multiple concurrent index creations on a single table will not return from either CREATE INDEX CONCURRENTLY ... statement until the slowest one completes.

I am not sure this is true anymore, or at least, it was improved in v14 to only apply when "the indexes involved are partial or have columns that are not simple column references." [1]

Another thing worth noting here is that the exclusive locks taken on system catalogues during a DDL change also replicate to your replicas (necessarily, ha!) and they will have the same behavior described, i.e., they will line up behind queries. So for instance if you run long ETL queries against a replica, the DDL lock will line up behind it and no other queries can run until the ETL query is done and the DDL lock goes through.

[1] https://www.postgresql.org/docs/14/sql-createindex.html

Strong reaction. In general we shouldn't discourage exploration and moving the needle forward. I actually agree with you that the language is somewhat stronger and the onus is on them to live up to it, but at the same time there is a lot of competition in this space (newer DBs) so nothing wrong with setting the bar high enough. :) They are specific with their use case (APIs), so that's excellent, as the core itself will not relinquish all the learnings of the "last century". ;)

Postgres's dominance is well deserved, of course. My only concerns with it, both are actively worked on, are bloat management (significant for update heavy workloads and programmers used to the MySQL model of rollback segments) and the scaling of concurrency (going over 500 connections). Bloat was taken over by Cybertec[1] after stalling for a bit and is funded (yay), while concurrency was also enhanced out of Microsoft [2]. All in all, an excellent future for our beloved Postgres.

[1] https://github.com/cybertec-postgresql/zheap [2] https://techcommunity.microsoft.com/t5/azure-database-for-po...

I call these macro-services. They work nicely, but only if you want long enough, in my experience.

I give them a card I grab from privacy.com that has a set amount, when I want to cancel, I set the card's amount to zero. They fail to charge it after a few attempts. The end.

The gem does not solve these issues, merely tells you about them (and even then it can't catch all of them, only the ones that Rails defines).

Ah, fair reading, thanks. As Postgres supports that level of isolation as well, I was thrown off a bit. but your phrasing makes sense.

I don't know if anybody from CockroachDB is reading this but their article[1] on serializable transactions is somewhat questionable, as it compares CockroachDB's Serializable to Postgres's Read Committed, which seems to imply CockroachDB is better. Of course, Postgres has serializable as well. The only novelty in the article is that Cockroach DB runs Serializable by default, so I am not sure what that comparison was doing.

[1] https://www.cockroachlabs.com/docs/stable/demo-serializable....

I think this is the crux of the issue. People like Chomsky argue the same way, that is, sure a statistical model can mimic a phenomenon to an increasingly likely degree, but the question he concerns himself with is "how and why it [language] works that way", not that I can somehow approach it. His example scenario of a filming bees and statistically re-engineer their dance is poignant: sure you get impressive results, but you will never understand why they dance!

Once this is clear, the discussion becomes healthier: linguists continue to try and understand fundamentals; ML NLP continues to try to get impressive, possibly lucrative results. Logical research can borrow from ML results, or re-use them, and so forth, but I agree with Chomsky that it can't be a shot in the dark always, because once you deploy it and pass it some tough decisions to make, well, what then?

I was pleased to see at least one idea, the recursive structures found in his theories, which is increasingly being accepted by people like Hinton, so that's great.

This is demonstrated rather famously in the Sokal affair: https://en.wikipedia.org/wiki/Sokal_affair.

I think the only correct quote here is "Now they don't have two problems."

Well that's what privacy.com (where this blog post is written) does, unless you checked it out and it's not what you want? I use them daily.

I wonder if the new wonders coming out from linux (io_uring...) would have made this a better design, but that work in the kernel is still in active development.

The same OS limits would apply to new instances, unless they knew the root cause and forced new instances to be configured with larger descriptor limits, which is....well, hindsight is 20/20, no?

Yes, reminds me of a European court that ruled[1] Subway bread is not really bread because it contains too much sugar.

[1]https://www.npr.org/2020/10/03/919831116/irish-court-rules-s...