> A simple example where 1 + 1 + 1 = 1 is ℤ₂, the group of integers modulo 2 under addition.
That’s a good example of an algebra where 1 + 1 + 1 = 1, but the article is specifically about systems where in addition to that condition, this second condition is also true: 1 + 1 != 0 (not equal!). ℤ₂ is not an example of that.
> because `tokio::time::sleep()` keeps track of when the future was created, (ie when `sleep()` was called) instead of when the future is first `.await`ed
I’m not a Rust programmer but I strongly suspect this updated explanation is erroneous. It’s probably more like this: start time is recorded when the task execution is started. However, the task immediately yields control back to the async loop. Then the async loop starts another task, and so on. It’s just that the async loop only returns the control to sleeping task no earlier than the moment 1s passes after the task execution was initialy started. I’d be surprised if it had anything to do with when sleep() was called.
On the other hand, I maintain that this is an incidental rather than essential reason for the program finishing quickly. In that benchmark code, we can replace "sleep" with our custom sleep function which does not record start time before execution:
In `wrapped_sleep` function body, where does the `sleep()` come from? It's still tokio::time::sleep, right? If so, the start time is recorded before the first `.await`.
Regardless, the program you provided _does_ actually run the futures concurrently, because of the `join_all()`. My point above was that in the original blog post, the appendix has a version without `join_all()`, which has no concurrency.
There’s one problem with this model. Let’s say I’m running a pre-revenue startup and I want to use the self-hosted version of CockroachDB. The license allows me to do it for free until I get to $10M annual revenue. Well, that’s great and all but I’d like to know how much I’ll pay once I do reach those numbers. However, the pricing for self-hosted offering is a secret, it’s “pricing upon request” – I have no way to estimate these expenses and thus no way to estimate if CockroachDB is a reasonable choice for my startup in the long term.
Even if the price wasn't secret, maybe when you hit $10M revenue 3 years later, they'll have raised the price 300%. Maybe they've changed the license again and now its priced per-seat or per-cpu-core or per-employee-tooth. Maybe they've decided to focus on larger enterprises only, and they no longer want your business.
This is true but you’ll have these risks with any paid service/dependency that has non-zero migration cost. Startups still use such products all the time, assuming that a huge price spike is not that likely or that there’s going to be some viable alternative with a migration path. I’d say it’s quite different when you can’t even guess what your starting point is going to be once you hit those $10M.
But I do agree with the general argument that lock-in as this for your core technologies (a database certainly counts) should be avoided.
With a database I'd say it's especially risky and lockin is extra strong. Compared to, say, OpenAI where you're just using it to generate text and its behaviour is already unpredictable anyway
IIRC cockroachdb support about every Postgres client.
It “speaks” Postgres.
Not a ton of vendor lock in, since you could always migrate to another Postgres hosting service (although you’d lose some of cockroaches regional features)
Even if CockroachDB uses Postgres wire protocol, it doesn’t mean you can easily migrate all workloads supported by CockroachDB to Postgres. The scaling properties are different.
Further, simply emailing and asking for a quote results in them asking about your whole business model and infrastructure; likely so they can extract as much as possible from you. This was the point we stopped communicating with them and chose a different vendor.
Yes, and this is probably a common issue with these “pricing on request” schemes. Unpleasant, yes, but this unpleasantness can still be worth it if you’re running a big business and you need the database with the properties that CockroachDB has. But for an early stage startup, there’s nothing to even talk about. I doubt they are going to give you a quote for some hypothetical future where your annual revenue beats $10M.
Maybe they actually just don’t care about attracting startups, the whole “free license for small players” thing is just so that developers can check it out, not for actual use.
I might find this app useful. However, for some reason it heats up my iPhone SE (2nd gen) and everything grinds to a halt after a few seconds of using it.
I got a subscription and the problem is gone. There are still other issues though, for example, the instant reminder feature doesn’t seem to work, the partner doesn’t get a notification.
On an unrelated note, do you accept feature suggestions? Task deletion would be nice to have.
Would you expand on the Python issue? I find recent Python additions either useful or non-intrusive, I wonder which ones you think are born out of FOMO.
The `match` statement is the most obvious - its motivation [0] is "pattern matching syntax is found in many languages" and "[it will] enable Python users to write cleaner, more readable code for [`if isinstance`]". But `if isinstance` is bad Python! [1]
`match` also breaks fundamental Python principles [2] and interacts badly with the language's lack of block scope:
>>> a, b = 1, 2
>>> match a:
... case b: pass
...
>>> a, b
(1, 1)
Not to mention that it also required large changes to the CPython implementation, including an entirely new parser(!) - which means other implementations may never support it [3]. Clearly `match` doesn't fill a gap in a coherent design for Python. It seems to have been added due to a combination of FOMO and/or resume-driven development.
Another example is async-await - while the concept is fine (although I think stackful coroutines are a better fit for a high-level language), the syntax is just copy-pasted from other languages [4]. There seems to have been little thought as to why C# etc chose that syntax (to allow `async` and `await` to be contextual keywords), nor how `async def` contradicts existing Python syntax for generators.
Here's Guido himself expressing FOMO about what would happen if Python stopped continually accumulating new features (specifically including the `match` statement):
> Essentially the language would stop evolving. I worry that that would make Python become the next legacy language rather than the language that everyone wants to use.
You are invoking an argument that's called "group selection" [1], it's the idea that genes propagate based on whether they benefit the species as a whole. This argument has been heavily criticized and it is not used much in the mainstream evolutionary science. Perhaps group selection has some effect in some niche, limited circumstances but it doesn't seem to be a significant driving force of evolution.
You don't need to invoke group selection to explain dying though. Dying might be an evolutionary advantage, not to you, but to the genes that make you. Which is not the same as the species, at all [2]. Organisms die not to make space for others but because building the mechanisms to keep young indefinitely is not worth the price compared to spending these resources on reproduction mechanisms. Or because the right combination of genes that allow you to have free lunch just wasn't reached yet. If there was a magic mutation that prevents mammals from ageing without any other effects, I'm pretty sure that gene would spread. Quite possibly to the detriment of the species.
(Beware, not an evolutionary biologist, just somewhat interested in the topic.)
What texts by Jorge Luis Borges are you thinking of? Wikipedia quotes him calling himself a conservative, and none of the short stories I’ve read strike me as revolutionary. Perhaps something from his youth?
I guess I don’t really know why I put Borges in that list like that. His poetry to me, is highly idealistic and Utopian. It was all about a better way for the world to work, if only some key change could be made. He was smarter than actual communists, in that the argument for dramatic change was emotional and poetic and full of sadness and hope. The most compelling reasons for revolution.
I just read his Wikipedia and it’s quite nice that like me, he drifted so far back into the mainstream from his more idealistic youth.
This Django example is more of a "[one or zero] to [one or zero]" relationship, that's likely what the grandparent post means. I doubt any of the mainstream relational databases have a way to enforce exact one-to-one correspondence between two tables. You could use triggers that execute at the end of transactions or something like that - but that's not part of the relational model.
Mainly because you end up with something that's untidy. Your elegant table that contains all data identifiable by a single PK is now spread across two tables and relies on a (often forgotten) constraint in addition to a FK.
I'd rather follow the rules of normalisation wherever possible.
I still fail to see how your single table approach is more normalized. Consider for example an e-commerce order that may have either (1) exactly one shipping address or (2) no shipping address (for things like digital, downloadable products). You’re saying that you’d rather store the address data on the order table using a bunch of nullable fields? That bloats the order table and introduces a ton of possible consistency problems. A much more normalized model, IMO, would be to separate the address fields into their own table and use the unique FK approach to ensure that no order has more than one related address. Precisely which rules of normalization is that breaking? And how would they be resolved by putting everything into a single table?
That’s a good example of an algebra where 1 + 1 + 1 = 1, but the article is specifically about systems where in addition to that condition, this second condition is also true: 1 + 1 != 0 (not equal!). ℤ₂ is not an example of that.