Hacker Newsnew | past | comments | ask | show | jobs | submit | mrkeen's commentslogin

It would certainly be a boon if Cassandra did better ACID than everyone's favourite SQL DBs (which are unknowingly running on read_committed).

It's a good sign that they've got bank account balance updates in the example code in the Accord github (sibling comment), as that's what I reach for if I suspect my DB is only pretending to be ACID.


Damn.

Hopefully they'll have to start cutting the product with actual cocoa to hit their margins.


Just tried installing the server variant on a dell precision.

The installer let me connect to my WiFi, but then spun indefinitely trying to get an ipv4 address.

If I skip connecting to WiFi, and just let the installer do its thing, I get no network on the fresh install either (all the tutorials say to use nmcli, which I don't have).


I might have experienced the same. It spun and spun after connecting to the WiFi on an Intel NUC 13.

> There is nothing in the bible that would support replacing human thought with machines.

Based on that, which of the following best applies?

a) Non-overlapping magisteria (NOMA)

b) Render therefore to Caesar the things that are Caesar's, and to God the things that are God's.

c) a & b


AIs who misbehave will be discreetly relocated to other parishes.

The author was fed up with not having data structures already provided, and needing to roll his own

Then it's actually the immature zig ecosystem that rubbed the author the wrong way, not zig the language itself. Not that the ecosystem isn't important, but IMO a language only truly fails you when it doesn't offer the composability and performance characteristics necessary for your solution.

Not really understanding what this would be though, zig has all the basic stuff you would expect in its stdlib (hashmap, queues, lists etc) just like Rust

This is from last year, the stdlib was much more bare back then.

Negative.

The only part of SOLID that is perhaps OO-only is Liskov Substitution.

L is still a good idea, but without object-inheritance, there's less chance of shooting yourself in the foot.


I go by a philosophy that Liskov Substitution is reeeally about referential transparency. I don't care about parent/child classes, I care about interfaces and implementations, and structural subtyping. Fix that, and it's great.

> Sadly, this comparator is still wrong for any sorting API that expects a general three-way comparison, because it does not handle equality as a separate case.

Let's scroll up a little bit and read from the section you're finding fault with:

  the most straightforward type of order that you think of is linear order i.e. one in which every object has its place depending on every other object
Rather than the usual "harrumph! This writer knows NOTHING of mathematics and has no business writing about it," maybe a simple counter-example would do, i.e. present an ordering "in which every object has its place depending on every other object" and "leaves no room for ambiguity in terms of which element comes before which" but also satisfies your requirement of allowing 'equal' ordering.

Your reply only works if the article were consistently talking about a strict order. However, it is not. It explicitly introduces linear order using reflexivity and antisymmetry, in other words, a non-strict `<=`-style relation, in which equality IS a real case.

If the author wanted to describe a 'no ties' scenario where every object has its own unique place, they should have defined a strict total order.

They may know everything about mathematics for all I care. I am critiquing what I am reading, not the author's knowledge.

Edit: for anyone wanting a basic example, ["aa", "aa", "ab"] under the usual lexicographic <=. All elements are comparable, so "every object has its place depending on every other object." It also "leaves no room for ambiguity in terms of which element comes before which": aa = aa < ab. Linear order means everything is comparable, not that there are no ties. By claiming "no ties are permitted" while defining the order as a reflexive, antisymmetric relation, the author is mixing a strict-order intuition into a non-strict-order definition.


  Definition: An order is a set of elements, together with a binary relation between the elements of the set, which obeys certain laws.

  the relationship between elements in an order is commonly denoted as ≤ in formulas, but it can also be represented with an arrow from first object to the second.
All of the binary relations between the elements of your example are:

"aa" ≤ "aa"

"ab" ≤ "ab"

"aa" ≤ "ab"

> By claiming "no ties are permitted" while defining the order as a reflexive, antisymmetric relation, the author is mixing a strict-order intuition into a non-strict-order definition.

There aren't any ties to permit or reject.

  we can formulate it the opposite way too and say that each object should not have the relationship to itself, in which case we would have a relation than resembles bigger than, as opposed to bigger or equal to and a slightly different type of order, sometimes called a strict order.

I just put the API at the centre, everything else hangs off it:

* The server implementation is type-checked against the API

* The OpenAPI spec is generated from the API.

* The client is generated/checked against the API

Any test-suite that operates using the client or server will then by definition be up-to-date with everything else.


It really isn't a long enough section to get lost in.

The 'not accurate' diagram says that orange-less-than-yellow implies yellow-not-less-than-orange. Hard to find fault with.

> NO. Antisymmetry doesn't exclude `x = y`. Ties are permitted in the equality case. Antisymmetry for a non-strict order says that if both directions hold, the two elements must in fact be the same element. The author is describing strict comparison or total comparability intuition, not antisymmetry.

I like the article's "imprecise prose" better:

  You have x ≤ y and y ≤ x only if x = y

My comment is not long enough either to get lost in.

The prose "It also means that no ties are permitted - either I am better than my grandmother at soccer or she is better at it than me" is inaccurate for describing antisymmetry. In the same short section, you first state the correct condition:

You have x ≤ y and y ≤ x only if x = y

from which it doesn't follow that "It also means that no ties are permitted". The "no ties" idea belongs to a stronger notion such as a strict total order, not to antisymmetry.


The prose is correct.

You (presumably) aren't your grandmother, so we have x=/=y. Therefore by the biimplication, (x ≤ y and y ≤ x) is false i.e. either x ≤ y (I am better than my grandmother) or y ≤ x (my grandmother is better than me). The "neither" case is excluded by the law of totality.


> The "neither" case is excluded by the law of totality.

We literally said the same thing. It doesn't follow from antisymmetry.

My point is precisely that:

(x <= y /\ y <= x) -> x = y

does not entail

x <= y \/ y <= x

The second statement is totality/comparability, not antisymmetry.


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: