They even directly conclude at the end of the article that improvements in algorithm are more important than the choice of language:
> Algorithmic complexity improvements dominate language-level optimisations. Going from O(N²) to O(N) in the streaming case had a larger practical impact than switching from WASM to TypeScript.
Yet they still have chosen to put the “Rust rewrite” part in the title. I almost think it's a click bait.
The system could be set up to automatically refund, if your PR wasn't checked for over $AVERAGE_TIME_TO_FIRST_REVIEW$ days. The variable is specific to the project, and even can be recalculated regularly and be parameterized with PR size.
I love how the landing page is straight to the point and has zero marketing BS. It achieves the opposite of AI-written text, while still being polished.
> The contribution of this work lies in its move from critique to measurement. It proposes concrete methods: recursive summarization chains, metaphor stress-tests, resonance surveys, and noise-infused retrieval experiments. These allow researchers to track how meaning erodes over time. By integrating these methods, it outlines a pathway toward fidelity-centered benchmarks that complement existing accuracy metrics.
To me, starting to solve the problem by meticulously measuring it, is a sign of a good solution.
There's another great meta-game similar to this. You can play it alone or with friends. It doesn't require any cards or dices, although can be played with them too.
The rules are simple. You join some group, that is playing a game, rules of which you don't know. Yet, you say to everyone, that you know the rules.
Now, your goal is to play as long as possible, before they figure out, that you actually don't know the rules.
Bonus points, if you convince others that it's THEY, who don't know the rules.
> Most Haskell tutorials on the web seem to take a language-reference-manual
approach to teaching. They show you the syntax of the language, a few language
constructs, and then have you construct a few simple functions at the interactive
prompt. The “hard stuff” of how to write a functioning, useful program is left
to the end, or sometimes omitted entirely.
I feel like this is such an issue with lots of languages. Learning your second, third, and so on language is in some sense harder, because “Getting started” tutorials spend too much time on simple concepts, and the hard part of “How do I write X (or what do I do instead)” is usually missing.
It recently occurred to me, that you can find exercises for almost any popular language, and I feel like it is the solution to the problem.
> This tutorial takes a different tack. You’ll start off with command-line arguments and parsing, and progress to writing a fully-functional Scheme interpreter
that implements a good-sized subset of R5RS Scheme. Along the way, you’ll
learn Haskell’s I/O, mutable state, dynamic typing, error handling, and parsing
features. By the time you finish, you should be fairly fluent in both Haskell and
Scheme.
There's not enough tutorials like that in the world
I know nothing about Git development, but it surprised me that most of the changes are kind of internal and affect the end user only on security or performance level.
For some reason, I was thinking there would be more new shiny features. But maybe for the tool that is as mature and wide-used as Git, that's not how it works.