Thanks for making this point! I'm chiming in just to add that the Jupyter Book project that builds MyST tooling is now using a new TypeScript stack instead of Sphinx, for any interested newcomers!
But yes, ^this. We are building around a shareable AST precisely because structure really matters.
The problem of "where did I see that" is something I suspect most people have encountered before. How that's actually done, though, is the devil. The vision -- semantic search of human experience -- is cool. The implementation -- always recording cameras piping every minute of your life to TotallyTrustworthyPeople's servers -- not so.
I love this angle, and would take it further. I'm starting to think about AI in the same way that we think about food ethics.
Some people are vegan, some people eat meat. Usually, these two parties get on best when they can at least understand each-other's perspectives and demonstrate an understanding of the kinds of concerns the other might have.
When talking to people about AI, I feel much more comfortable when people acknowledge the concerns, even if they're still using AI in their day-to-day.
MyST Markdown (the MD flavour, not the same-named Document Engine) was inspired by ReST. It was created to address the main pain-point of ReST for incoming users (it's not Markdown!).
As a project, the tooling to parse MyST Markdown was built on top of Sphinx, which primarily expects ReST as input. Now, I would not be surprised if most _new_ Sphinx users are using MyST Markdown (but I have no data there!)
Subsequently, the Jupyter Book project that built those tools has pivoted to building a new document engine that's better focused on the use-cases of our audience and leaning into modern tooling.
The PyPI ecosystem can not, for the foreseeable future, replicate the scope of the conda ecosystem. From microarch builds to library deduplication, conda is a more general purpose solution. That doesn't mean that one "wins out" (and, for reference I predominantly use Python's PyPI), but they're not the same tools.
I don't disagree with the general vibe here, but a few points:
- It's hard to compare Omicron vs delta because of the number of confounding variables - population heterogeneity, vaccine + infection induced immunity, etc.
- Severe strains with latency periods are invulnerable to symptom recognition. I don't think the asymptomatic period for the COVID variants varied as much in the lower bound as it did the upper bound. The point being -- behavioural changes are much more likely to be general caution (i.e. limiting contacts, spacing social events in time, etc.) than responsive (I feel unwell).
I want to be careful about what I write given the context of what's going on, and the personal ramifications that can have.
Suffice to say, it's worth considering whether the cost of a decision can be interpreted solely as how much money there is vs the wider ecosystem level consequences of said decision.
> I think that current timelines, while not particularly awe-inspiring, are quite realistic (Germany: no more coal for electricity within 2038).
I am not an expert on this, at all... but I'm not sure that's the case. c.f. Wikipedia:
> In March 2024, Federal Audit Office published a report in which it assessed the policy as not meeting goals on a number of points: the planned 80% share of renewable energy requires dispatchable sources but the assumed 10 GW in fossil gas generation is neither sufficient nor on schedule; extension of electric grid is behind the schedule by 6,000 km (3,700 mi) and 7 years; security of the supply chain is not sufficiently assessed; system costs to ensure 24/7 generation are underestimated and based on "best-case" scenarios; capacity installed in renewables is behind the schedule by 30%, whereas demand is expected to grow by 30% as result of electrification of heating and transport
As for
> ROI for those plants is completely abysmal already and continuously getting worse, because they are completely unable to compete with solar/wind energy prices whenever those are available.
That's because the pricing model is arbitrary. If we need nuclear, we can make it economically viable through reforming the way we purchase electricity. But,
> construction alone currently easily takes a decade
is the real problem. Unless SMRs actually materialise _and_ have fast build times, it's just not happening (and realistically, I think _that_ ship has already sailed).
I'm not really making a point here much beyond "it's one thing to say nuclear is no longer viable given our lack of investment" and another to say "it was a good thing to drop nuclear N years ago". You're not saying that for the record. By dropping nuclear, we have to deal with a bigger shortfall and that means gas peakers, etc.
It's a fair point to distinguish that baseload is just one mechanism to reduce the amount of surplus renewable capacity required to cover demand. However, what is the alternative in the face of a grid that's designed for centralised large power producers, and an environmental policy that disincentivises us from using gas?
Yes, in a hypothetical world we can just scale up storage and decentralise production, but what are the timelines and costs on that? Because my understanding is that realistically something like nuclear is the best way of making that problem tractable over the timelines that e.g. a nuclear plant can operate.
I am not an expert by _any_ means, but to provide _some_ intuition — self-attention is ultimately just a parameterised token mixer (see https://medium.com/optalysys/attention-fourier-transforms-a-...) i.e. each vector in the output depends upon the corresponding input vector transformed by some function of all the other input vectors.
Have you used the contemporary tooling in this space? `mamba` (and ~therefore, `pixi`) is fast, and you can turn off the base environment. The UX is nicer,too!
If you use conda, and can use conda for what you need to do, use conda w/ conda-forge. It has a much better story for libraries with binary dependencies, whereas PyPI (which `uv` uses) is basically full of static libraries that someone else compiled and promises to work.
Note, I use PyPI for most of my day-to-day work, so I say this with love!