So… Rust?

Blocking hexbear is a sensible choice, good for them.

Not sure if serious or not, but yeah I use interactive rebases every day, many times a day (it’s nice for keeping a clean, logical history of atomic changes).

It’s very simple to recover if you accidentally do something you don’t intend (git rebase --abort if the rebase is still active, git reflog to find the commit before the rebase if it’s finished).

Never understood why this is such a trope. There’s very little you can’t recover in git (basically, only changes you never committed in the first place).

Yes, he is a dumbass, but frankly this is exactly what’s needed. More and more of his base having reality hit them in the face, complaining loudly, and fracturing his support.

Slack is way, way, way better in almost every conceivable way.

Unless you’re writing Scala or something (which is probably the one exception to the rule), if you are using a language that supports OOP, you’re not really doing functional programming. Functional-esque features that have made their way into imperative languages like map are only a tiny fraction of the functional toolbox.

There’s a bunch of features you want in a language to do functional programming, and imperative languages don’t really have them, like purity by default (and consequently, an orientation towards values rather than references) ergonomic function composition, algebraic data types, pattern matching, support for treating everything as first class expressions/values, etc.

Perhaps this is presumptious (and I apologize in advance if so), but I’d wager you haven’t truly programmed in the functional paradigm. What imperative programmers tend to think of functional programming is very surface-level and not really reflective of what it actually is. It’s an entirely different beast from imperative programming. It requires a shift of your mindset and how you think about programs as a whole.

Source: Senior software engineer writing Haskell full time for the last 4 years. Will avoid OOP until my dying breath.

It basically does. It pretends to court functional programming while actually being really antithetical to it in basically every way. Guido Van Rossum has vocally expressed his dislike for functional programming (though I’d argue he actually doesn’t really know much about it).

Its query planner is also much, much more powerful. Like it’s not even close.

There’s hardly any good reason to use MySQL today. Postgres is easier and nicer to work with, with a strong community backing it.

SQLite is completely different from both and has entirely different usecases.

Postgres, hands down. It’s far better than MySQL in every way.

Every day pretty much with Unix tools. Vim, awk, sed, etc.

That’s what the If-Match header is for. It prevents this problem.

That being said, I generally think PUTs are preferable to PATCHes for simplicity.

It’s about making APIs more flexible, permissive, and harder to misuse by clients. It’s a user-centric approach to API design. It’s not done to make it easier on backend. If anything, it can take extra effort by backend developers.

But you’d clearly prefer vitriol to civil discourse and have no interest in actually learning anything, so I think my time would be better spent elsewhere.

As I already said, it’s very simple with JSON Patch:

[
  { *op": "replace", "path": "/Name™, "value": "otherName"}
]

Good practice in API design is to permissively accept either undefined or null to represent optionality with same semantics (except when using JSON Merge Patch, but JSON Patch linked above should be preferred anyway).

The semantics of the API contract is distinct from its implementation details (lazy loading).

Treating null and undefined as distinct is never a requirement for general-purpose API design. That is, there is always an alternative design that doesn’t rely on that misfeature.

As for patches, while it might be true that JSON Merge Patch assigns different semantics to null and undefined values, JSON Merge Patch is a worse version of JSON Patch, which doesn’t have that problem, because like I originally described, the semantics are explicit in the data structure itself. This is a transformation that you can always apply.

Zalando explicitly forbids it in their RESTful API Guidelines, and I would say their argument is a very good one.

Basically, if you want to provide more fine-grained semantics, use dedicated types for that purpose, rather than hoping every API consumer is going to faithfully adhere to the subtle distinctions you’ve created.

Only if using JSON merge patch, and that’s the only time it’s acceptable. But JSON patch should be preferred over JSON merge patch anyway.

Servers should accept both null and undefined for normal request bodies, and clients should treat both as the same in responses. API designers should not give each bespoke semantics.

Used in English translations of the Bible, so if you grew up Christian you probably have heard it before.

Confused what you mean. OpenAPI has nothing to do with JS.

Omaha is a lot less left-leaning in my experience. It’s very purple. Lincoln is solidly blue.

I just recently purchased a house in Lincoln. Just quickly looking on Zillow for Omaha and home prices look to be very similar to what I was seeing here in Lincoln. Property taxes in Omaha are also a fair bit higher than Lincoln.

There’s other stuff too, like lower crime rate in Lincoln, better/more parks, LPS being generally a lot better than OPS, etc.

I guess it ultimately depends on what you’re after. If you want something more big city, then Omaha obviously has Lincoln beat. But for a more relaxed pace of life and for raising a family, Lincoln is where it’s at.